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.

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?

Getting higher velocity! Take 2

I posted yesterday that these things listed below would lead, or at least could lead to higher velocity (higher productivity) in your new product development teams....

* Better retrospective meetings
* Better impediment lists
* Better business cases to management
* More effective action (get approval and implement one 'fix' until you get results)
* Better use of velocity numbers

More many of you, I suppose this seems like just saying "work harder", with no real clarity on what to change from what you are doing now.

So let me add a few comments.

• Retrospective Meetings

Too often I hear that a team is no longer doing them every Sprint. Or that they are bored doing the same ole pluses and deltas.  Again.

First: what is the goal of the meeting?  The key goal is to identify and attack one good-sized impediment.

Frankly, if we have a public impediment list, identifying the top impediment should not usually take that long (more on this later).

Good-sized?  Well, not too big ("world hunger") and not to small (one biscuit for Mary).  Something that will, when fixed, give a meaningful jolt to team velocity.

Attack? This is usually one of two things: (a) a business case to one or two managers, to convince them to approve the fix, or (b) a design of the fix and a plan to implement the fix.  AND, it means attacking in an aggressive way both of those (getting approval and then implementing the fix) until the velocity improvement is realized.

I discussed Retrospective meetings earlier.  You may want to look at that post.

I also recommend the two classic books on Retrospectives: Agile Retrospectives by Derby and Larsen and Project Retrospectives by Kerth.

• Better Impediment List

The first thing here is a public list.  So everyone can add to the list and argue about the prioritization.  All the time I see no public impediment list.

Let me be clear.  Until the team is perfect in everything is does, there are always the top 20 things to fix (make better).  PS. I have never seen anything close to a perfect team. Some very very good teams, yes, but nothing close to a perfect team.

The second thing is getting everyone creative about identifying the most useful things to change.  Far too often the best ideas are not identified because people can't imagine them being changed.  So, they never make the list.

There are many ways to get more creative.  I will suggest two for now.

1. Help them give themselves a challenge. Something like this: "What would we have to change around here, assuming anything could be changed, to enable the team to go from a velocity of 20 to 40 in 6 months?  Assuming we only worked a normal work week and that we had more fun." 
2. Get an important manager or two to talk to them and say something like this: "I am willing to consider changing anything around here, assuming you make a good business case and assuming the velocity improvement or other benefit usually turns out to be real. Anything.  I can't guarantee I can approve everything, but I am willing to consider it. If you guys are not trying to break the rules, you're not trying hard enough."

Those two might start them being more creative.

• Better Business Case

I find teams do not know how to make a good business case to a manager.  Sometimes a manager will see their point (that a change must be made) but usually it is the manager actively reaching out to help, rather than the team convincing the manager in the manager's own language.

I recommend that the team must learn how to make a business case.  For eveyone's sake.  (Yes, I know they only want to do the 'real work' of building the product, but they still must learn the basics of making a business case to improve things.)

They can use any method. I like the A3 format and approach, but that's not the only one.  And it might not fit every case. They must address the benefits and the costs.  And usually estimate (project) these in money terms.  The managers typically want a 6:1 ratio.  Because they know you are lying.  They know the benefits will be less and the costs will be higher.  After you develop a good track record, then they will likely accept 3:1.

If you know the velocity of the team, if you can estimate the expected change in the velocity, if you can estimate the cost of the team and if you can estimate the expected money return in NPV (net present value) over the forecast period of the product (say, 3-5 years), then you can estimate the money impact of a small change in velocity (say, a 10% change).

Yes, these estimates may make us feel uncomfortable.  More on this later.

The A3 format I use is: Problem, Solution, Benefits, Costs, Action Items, Measurements.
All of these must be addressed briefly on an 11x17 piece of paper.

This last section (measurements) is important.  This tells the manager that you will prove later that the 'fix' was successful.  If nothing else, this shows him or her that you are willing to be measured.  It tells them 'this person really believes in this change'.  Which is a good indicator for its success.

In a recent year, Toyota did 1 million A3's.  I think this means 1 million were implemented. That's one per person per month.  So you see some firms find this a productive approach.  (Yes, I wish Toyota had not made the mistake of going for an anti-lean goal of being the largest auto manufacturer.)

Let me stop there for today.

Getting higher velocity!

Higher velocity per se is not the end-all and be-all.  But it sure does help.

Having trouble getting to hyper-productivity?

Try these things.  Together.

* Better retrospective meetings
* Better impediment lists
* Better business cases to management
* More effective action (get approval and implement one 'fix' until you get results)
* Better use of velocity numbers

That's the basics.  I could have put them in a different order, easily.
Maybe I need to explain each one?

My experience is that for lots of teams, each part is weak, and there is no sense of how they all hang together, and support each other.

How does QA fit in?

Liz! asked a question.  She and her team are starting agile and she can't get much info on where QA fits into to Agile.

First, I want to reiterate Jeff Sutherland's concern, that he biggest problem is that too many teams are not getting to working product (working software) within a Sprint (a 1 to 4 week consistent timebox).

In my view, the absolute minimum Definition of Done for a typical software "story" or PBI (product backlog item) is:
* requirement defined
* coded
* unit tested
* functionally tested (aka acceptance tested)
* all identified bugs fixed
* reviewed by the Product Owner, and all 'problems' fixed

This is the minimum definition, assuming one starts with significant impediments.  The ideal definition includes live, in production, being actively used by the customers with normal volume.

Now, let's add a key principle: The bad news does not get better with age.  In other words, it is much cheaper to slow down and test and fix now (even though it does have some cost) than to not test in the Sprint and discover the bad news later (where the price is much higher).

So, our answer is that good professional testers must be in the Scrum team.  Ideally that means 100% allocated to one team.  At a minimum, 50% allocated to one Scrum team.

Where does QA fit in?  Well, usually the testers are aka QA people.  Sometimes QA means truly "quality assurance" per se, in which case the QA people look at the Scrum team (and the process elsewhere as well) to see if sufficient quality is being baked in in the best possible way.

Liz, we are also asking that coders help testers, and vice versa.  And each side no longer looks at the other side as an enemy.  Still, the testers are always trying to "break it."  So, they maintain that attitude.  And each coder views any break identified now as a 'win' for the team, not as a loss for his ego.

Also, usually in large firms that is a 'landing strip'.  By which we mean some final testing where the code of say 3 teams comes together into one stream.  And is 'finally' tested.

A common pattern is that a 'test scrum team' does the final testing, and sends bugs back to the 'development' teams.  Obviously, QA people populate most of the test scrum team.   -- This is a common pattern when you have lots of impediments; and not a bad pattern in that situation.

So, Liz!, have I answered your question?
(There are other situations and complexities that might be addressed, but I wanted to hit just the highlights.)

Release Planning - Business Value Points

One thing different about what I recommend for Release Planning and what others recommend is Business Value points.

What do we mean?

First, is it useful to distinguish the Business Value (BV) of items in the Product Backlog?  YES!

Why?  Well, Pareto says that you can re-apply the Pareto rule (the 80-20 rule) at every level of the population.  That means the rule of the "vital few" also applies to things "in the small".  We have to focus on the gold, the platinum, the diamonds, and ignore the silver, the copper, the dirt.

Also, it is very helpful to put numbers on the items.  Numbers are clarifying.  "Oh, 5 times more important? Well, in that case... Before I thought it was just a little bit more important."  It is useful to explain why something is important, but also useful to make it specific with a number.

A number does not magically make BV less complex.  There are myriad things going on, and changing with BV.  There is the MMFS (minimum marketable feature set), there are inter-relationships.  There is quality and beauty, etc, etc, etc.  If we find things have changed enough, we can easily change the BV points (BVP) number.

Now, the most valuable thing about using BVP is not that we end up with numbers on each item.  The most valuable thing is the discussion amongst the team and the business stakeholders.

OK, how do we do it?

First, discuss the 2-5 main drivers of BV.  My hypothesis is that each project or product could talk about these drivers in a different way.  So, get the business stakeholders and the full Scrum team together, and discuss and agree on the main drivers.

Then, pick your 5 best experts on Business Value (really from 4 to 7). Ideally people who will see different parts of BV (I am picturing 6 blind men and an elephant just now).  Typically these people are the Product Owner, and 4 business stakeholders (including maybe a real user or end user!).

Then pick the single item with the most Business Value.  Make sure it is not what I call a super-epic (the epic that almost describes the whole project).  It needs to be a reasonably small epic.

Call that "the highest number".  Say, a 130 on my scale above.  Or if you are using regular planning poker cards, a 90 or 100.

Then get the Fibonacci cards out.  Ideally real Fibonacci cards (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144). 

Then take User Story cards randomly, and compare them.  Then the rules are just like Planning Poker, except that you are voting "how much smaller is this new story compared to the reference story?"  If the reference story is 90, and the average for the new story is 30, that means it is 1/3 as important as the reference story.

We strongly recommend averaging once the "experts" get to within 3 consecutive Fibonacci cards of each other (a degree of consensus).  Averaging leads to a better resulting number.

The implementors listen to the experts discussing and voting on BV.  They learn.  If they have questions, they ask.  (Part of the purpose is to move the tacit knowledge of business value, of why we are doing this work, into their heads and hearts.)  But the implementors cannot sidetrack the conversation.

After the team of experts has voted on all the user stories (PBIs), then the team looks over the whole set.  Are any of them looking stupid now?  If so, re-vote.

BVP can be re-estimated later, whenever we think we are smarter (or identify that we were stupid).  They should happen fairly often.  Understanding BV is really hard!

Latest Reading List - Books

We have a list of recommended books at LeanAgileTraining.com, here.

In addition, we can recommend the following:

A Sense of Urgency by John Kotter

Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising.

Toyota Production System by Taiichi Ohno.

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)by Frederick Brooks.

Fit for Developing Software: Framework for Integrated Tests (Robert C. Martin Series)by Mugridge and Cunningham.

Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley Signature Series)by Duvall, Matyas, and Glover.

Agile Retrospectives: Making Good Teams Greatby Esther Derby and Diana Larsen.

Lean Software Development: An Agile Toolkit (Agile Software Development Series)by Mary & Tom Poppendieck.

Project Retrospectives: A Handbook for Team Reviewsby Norman Kerth.

Test Driven Development: By Example (Addison-Wesley Signature Series)by Kent Beck.

The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials)by Katzenbach & Smith.

Working Effectively with Legacy Code (Robert C. Martin Series)by Michael Feathers.

The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovationby Nonaka and Takeuchi.

Good to Great: Why Some Companies Make the Leap... and Others Don'tby Jim Collins.

Software by Numbers: Low-Risk, High-Return Developmentby Mark Denne and Jane Cleland-Huang.

Agile Estimating and Planning (Robert C. Martin Series)by Mike Cohn.

User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series)by Mike Cohn.

Implementing Lean Software Development: From Concept to Cash (Addison-Wesley Signature Series)by Mary & Tom Poppendieck.

The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni.

Comment: I have given links to Amazon, which has some benefits. I am slightly concerned that it may appear too commercial. There is certainly no obligation to buy from Amazon.

Suggestion: Some of these books are technical (in one area or another) and some are more about people. Mix and match. Consider what you need to learn. Consider what you are most ready to learn. And don't think too much in the sky. See how much you have really learned by putting your ideas into action.