Thursday, September 29, 2011

Creativity

A friend was reading Daniel Pink's book called Drive. And so I started reading it.

I had this series of thoughts.

First, I have for a long time thought that the key thing about our jobs is creativity.  Takeuchi and Nonaka call it knowledge creation, but to me it remains essentially the same thing.  And it covers many domains: business, technical, people, customer, marketing, etc, etc.  We must be, as a team at least, creative in all these different domains. Innovative, inventive, combining things in a new and interesting way, just coming up with something that seems weird at first, seeing something new that is elegant.

I find that there are, in overly simple terms, two types of people I run into.
People who are ok with creativity and chaos, and people who are not.

The people in that second group do not create much in the exercises we do in the Scrum classes.  They tend to want to 'edit' or restrict work too soon. They tend to both give and take restrictions on the 'scope' far too soon. They tend to ask me to restrict or define the exercise, as though they were afraid of chaos.

And Daniel Pink's book makes me think that they (those in the second group) have not realized how their own internal thoughts and feelings inhibit their creativity. They want to be too orderly, too soon.  They want to edit themselves before they have gotten a useful body of ideas out on the table to play with. They fear that play is not real work.  They worry much too soon about 'are we on target'. They fear the subconscious, and want everything to be arrived at logically.

In other words, they have told themselves a bunch of lies about their own motivation (to focus on the subject of Daniel Pink's book).  They are not inherently less creative, at least according to this (my) hypothesis.  They just have 'rewarded' themselves so wrongly that less creativity comes out.

Now, it may be that some teams are just less creative. Period.

But before deciding that, let's give them dance lessons.  Let's have them play.  Let's ask them to break their own mental boundaries in some meaningful way.  And see what they can really do once the blinders come off.

If you run into a team that basically is in the second category, I would work with them to identify their ideas and concerns about creativity.  My hope is that by talking it through, they can start to allow themselves more chaos and creativity.  And also more fun!

In closing, let me repeat here what Jeff Sutherland has often said: If they are not having more fun, then they are not playing Scrum the right way.

I think he means this in two ways;
- only by having fun will their best come out
- fun, serious fun, is a value for human beings in and of itself.  It does not need to be justified in any other way.

Note: I do not think Jeff would condone 'trivial fun'.  My example of that might be: eating a whole bowl of candy on Halloween.  Fun in a certain use of the word, but not good for you.  I mean, and I think he means, fun that gives deeper satisfactions than that.

Note: The picture or mindmap above comes from this page:
http://www.sorrythatusernameistaken.com/2010/03/04/creativity/

Defining Business Value // #2 Customer Smile

Imagine that you make a new camera, and after all that work -- does it make the customer smile?

Imagine that it is not Scarlett Johansson. Just a girl or young woman. Or maybe any customer who buys your new camera. You don't make any profit on that camera, just she smiles.

How do we evaluate the Business Value of that smile?

"Would it have been worth it, after all,
Would it have been worth while"?  (TS Eliot)

When I got my MBA at a school just off Wall Street, they said (or some of them said) that the firm was there to maximize shareholder returns.  Not that that was bad, since firms in the end are owned by widows and orphans...it is they who mainly use all the value there.

But the message was: money.  Measure it in money.

My ancestors are (or were) practical crazy New Englanders. (Well, crazy in the sense that they left the comforts and known-ness of England to live in strange unknown land where half of them died the first year.)  They were practical.  I cannot say money is bad. It is only a means, and a very practical means.

I found out also, at that same school, that Peter Drucker (arguably the best management guru still) said that the purpose of the firm was to provide customer satisfaction.  (That, for example, making money for the shareholders was a constraint, not a key purpose.)  Frankly, as I get older, I tend to agree.

And one finds that firms never can charge for each specific increment of customer satisfaction.  Charge, they must, at different times, but never exactly bit-by-bit for each increment of satisfaction.  Can Starbuck's charge by the sip?  No, I think not.

And then one ponders, Maslow-like, the satisfactions for the producer and the wise consumer, of various products or services.  Truly "satisfaction" is an inadequate word for a trip to Paris. When you buy a copy of The Count of Monte Cristo (Dumas), is it exactly satisfaction one seeks?  Or adventure? Or to be at-one with others?  Does one know?  And how to measure it?

The metaphor of Maslow's hierarchy of needs might be useful here.

Now, people will pay for these things. But how much to charge, and how much real "business value" they receive....these are hard things to understand.  Well, indeed, a human being is a hard thing to understand.  And hopefully you are in business to serve not one, but many human beings.  Quite complex.

My main point today is that people must re-gain an appreciation for the difficulties of the work of understanding business value.  To me, it is very very important, and also very hard to understand. So, we should start with the assumption that we need a lot, a whole lot, and mean gobs, of feedback.  To help confirm to ourselves that we have not totally mis-understood.

But God!, as a producer, when she (well, she, especially if you're a man... your wife, your daughter, your girlfriend, your mother, someone you care for) when she smiles. When she is happy with what you have produced.  It is a wonderful day.  When you don't get the puzzled look of "well, he tried hard, but it's not what I want, and how will I tell him?"  No, not that. But the smile of "I really like it!"  It is very satisfying as a producer, is it not?  (And the women readers who are producers know what I mean too. Although there are different difficulties.)

So, Scrum is trying to enable all these moments of truth to happen.  To feed your head and warm your heart.

Wednesday, September 28, 2011

Nokia Test: Know your velocity (7)

Another installment in explaining the Nokia Test aka The ScrumButt Test.

Background: There are far too many teams doing "Scrum, but...[eg, we don't have a ScrumMaster]".  This is not "full-out" Scrum, and almost always means that the team is not getting impressive results.

My original blog post is here.  And I have other blog posts on this subject.  Just use the search function above. And see this blog post from Jeff Sutherland.  He also has others.

***

So, the seventh line of the Nokia Test says: "The team generates burndown charts and knows their velocity."

What is a burndown chart? Let's start with its purpose.  The purpose of a Sprint burndown chart is to enable the whole team to see, on a daily basis, how much more work the team has to do to fulfill their commitment to deliver 8 stories in a 2-week Sprint (or x PBIs in a y-week Sprint, if you prefer).  Well, the purpose is more than just to see.  The purpose is to enable them all to have the summary information that might galvanize action. "OMG, we gotta do something, because right now it looks like we won't get it all done!"

The idea behind this is just like Hans Christian Anderson said.  Anybody can call out that the emperor has no clothes, ie, that we're in trouble and must act.  Now.  And anyone can volunteer some ideas on how to fix it (whatever the key problem or problems might be).  Scrum does not presume to define how the team will decide what to do (eg, should there be conflicting solutions proposed).  Rather, Scrum assumes that there are myriad possible team "configurations", so the team must self-organize to decide how to decide.  And the team members probably have already done this, at least mostly, by the time this crisis has arrived.

So, the Sprint burndown chart (or any similar device) tells the team how much effort is remaining today to complete all the stories originally promised. So that the purposes described earlier can be pursued.  For beginning teams, effort remaining is usually expressed in ideal hours.  And it is effort remaining re-estimated with any new knowledge we have now.

A release burndown chart has a similar purpose.  Again, anyone in the team can contribute. But the final decisions are typically more with the product owner.

So, the release burndown chart shows how many story points of work are remaining to get done all the stories 'promised' for the next release. 

This Nokia item also focuses on the known velocity.  The team knows their own velocity, and rather than get too proud or too humble, they immediately start the process of improving it.

Again, why is it useful to know the team's velocity?  A few of the reasons...

  • the velocity can be used to plan with. ("It will take 10 more sprints at 20 story points to complete those 200 story points in the product backlog.")
  • to justify spending time working on improvements ("Why did you spend so much time going to retrospectives?" "Well, we increased our velocity that way by 70%.")
  • to push back on the magical thinking managers ("Well, just because you stamped your foot we can't double our trend velocity number.  Want to help us remove some impediments?  Maybe then we can improve significantly.")
  • to make the business case ("If we increase velocity by 10%, that means about $300K in net profit. We can definitely afford this change!")
  • to measure success ("So, not that we implemented that fix, how much was the improvement really?")

Do these ideas indicate some places where you can get more from this set of things we call Scrum?