Public Impediment List !!! - 2

There is a good Scrum trainer who thinks that a public impediment list is not important.  So, if he can mis-understand, then we all can.  See here is a yet better explanation.  I hope.

****

I find that the lack of a public impediment list is a prime indicator of a lack of focus on removing impediments.

This is essential in Scrum.  Why?

Well, first it is important to say that the public impediment list is not the main deal.  The list must be acted on.  But, like 12 lawyers at the bottom of the ocean, it is a good start.

The real deal is removing impediments, and making the lives of yourself, your team and your customers better.  And the impediment list is one way to do that.  Or, better to say: fixing impediments is one way to do that.  And the impediment list (public) helps you do it better.

Why have a list?  Well, we believe in doing one thing at a time, and getting relatively quicker results from that. Rather than working on many things and usually not making any tangible progress.

So, the list enables the team and the firm to order the work on the impediments.

How? Well, first an impediment is anything, anything slowing the team down. Or, if fixed, would speed the team up. (Speed meaning both higher quality and higher productivity.)  The team gets greater benefits sooner by working on the top priority impediment.

But we forgot to mention that the first one might be the one that gives us the greatest bang of the buck, meaning "business value" divided by effort. (Business value for impediments might, too simply, be thought of as the velocity increase for the team.)

So, we can always be working on the top item on the list.

And, by the way, every team has not reached anything close to optimal velocity, so there is always a top impediment.  In fact, always a list.

Why public? Well, so everyone can see and offer feedback on what are our team's biggest impediments.  Otherwise, Brian thinks he told George about Item X, but George forgot to put it on his personal list....so, it was forgotten. All these little human errors are less likely with a public list.

And we mean everyone.  People in the team and people outside the team.  And including the higher level Impediment Removal Team (IRT).  Anyway can make suggestions, and help us get better.  [I call it IRT.  Ken Schwaber and Mike Cohn and others have their own names for it.  I assume you are in a company with 4 or more Scrum teams, where an IRT starts to make sense.]

A public list reminds everyone that someone should be working on the top item, well, and that would be today!  "Has anyone started?" "Oh, yeah, I'm about to start that!"  Human nature again.

And a pubic list enables Mary... who was sure her Item B should be number one, but shows as number 10 now.... identify the problem. So, now she knows to go to George the ScrumMaster and make the case why her Item B should really be #1 on the list.  Otherwise, she might just guess that George "got it" after their hallway conversation (where he actually was thinking about the Christmas presents he needs to get).

****

The list is prioritized. If the priorities are not obvious, then the ScrumMaster breaks ties.

And the real juice is that the SM is making sure the top impediment is always getting worked.  And indeed someone is fixing one almost daily.

Again, there never comes a day when there is not a top impediment. (We never become perfect.)

Now, it may also be that the public impediment list reminds the SM (and everyone else around) why the heck we have an expensive person (the SM) over here *not* doing "real work." (By the way, I think the SM easily pays for himself by removing impediments. But you do the math. Of course, that assumes that the company culture does not stifle all the impediment removal efforts -- which has been known to happen.)

For you all into Lean, a public impediment list relates to Visual Management and to Kaizen.  Two big practices (or ideas) in the Lean community.

The exclamation marks in the title are there to suggest that way too often we find teams without a public impediment list.

Finally, let me recommend a public list of impediments already fixed.  How quickly we forget our successes.  Oh, yeah, that's why we have the stupid ScrumMaster around....

Your thoughts?

Why call it "BV Engineering?"

A man I greatly respect wrote to question why I call it "BV Engineering."  There are many engineering disciplines, he noted, but is there a degree in "business value engineering"?

I said I thought an MBA was the degree to get for this. Not another regular engineering degree.  But I agree with him that for some the name is mis-leading

But this begs the question. Why do I call it "BV Engineering?" Those of you who have taken one of my courses will of course know.

Those of you taking the BV Engineering workshop in Ottawa on Dec 8-9 will also learn (again) why.  And more.

But why?  Two reasons.

First, Scrum is a framework, and purposefully does not attempt to define the engineering practices that the team should use in building the product.   Scrum assumes that these engineering practices are not perfect.  And assumes that the imperfections will show up in the Impediments List.  And, when an impediment rises to the top, it will be fixed.

So, I want all the stuff around Business Value to be treated the same way. All the ideas, all the people, all the tools, all the process.  It needs to be continuously improved.  And items need to go on the Impediments List. And then get fixed!  So, I want BV Engineering to be amongst the engineering practices we are continuously improving.

Second, I have colleagues that have some wonderful ideas about Business Value.  Good, big concepts. Or other ideas.

And I want that to be wedded to rigor (or at least more rigor), discipline, and metrics.  Yes, metrics around BV are hard. And?  This is the only really important thing we do -- deliver business value -- so I think we should have some metrics.  And be continuously questioning how good the metrics are.  This is what they do in physics.  And so should we in business.

To me, 'engineering' implies rigor, discipline, and metrics.

So, apologies if the phrase otherwise does not work for you.

***
To see other posts about BV Engineering, just click on that label to the right.

Scrum & Kanban

Jim Coplein today posted a very interesting post on Jeff Sutherland's Scrum Log.  It's title is:  An Alternative to Kanban: One-Piece Continuous Flow.

In the piece Jim discusses the definitions and merits of Scrum and Kanban.

This is a subject about which I too have some feelings.  Not feeling as talkative as Jim, I will summarize them.  This will allow greater room for mis-interpretation, and therefore for greater learning. (smile)  


1. Let's get more results. I am getting to the point where I don't care if we use Scrum, XP, Kanban, scotch tape, or Granma Berthe's Bible. What we use or what we call it means less and less to me.  


Show me the smiling faces. Show me how it helped you or your team or your customers.  In real life. The results are what matter.  The gods who spoke to Jeff and Ken and the scrum community knew this well. 

I better add: I still think Scrum is the place to start, and I don't believe in Scrum-But. But this subject is another 10 blog posts.


2. Lean bias.  I look at Scrum and Kanban as parts of Lean.  And I like them all.


3. Scrum. I think it is an excellent start. About as much as one team can change in a short period of time. And, yes, while it is simple, it takes years to become a master.  


But Scrum is only a framework, and while the team should not subtract from Scrum, stuff must be added to Scrum.  Actually quite a lot of stuff, in my opinion.


Scrum's 'incompleteness' is not a defect but a virtue.


4. Kanban.  The cards in Lean were stolen from Piggly Wiggly (the grocery store).  Which pleases me, since I have been to some of their stores, I like them, and my kids have "I'm Big on the Pig" t-shirts from Piggly Wiggley.


Kanban is one of several tools in Lean.  Kanban may be classed with several Lean practices or tools under a group called "Visual Management." 


Kanban in Lean first refers to the sign-cards stolen from Piggly Wiggly.  And of course to all the 'usage' around that.  Kanban has many purposes in Lean manufacturing. Reduce and manage inventory. Set up a pull system. Enable flow. Enable single-piece flow.  Provide some indicator of stoppages in flow.


It is important to note that Lean uses many other things in addition to the Kanban cards to attain all the goals mentioned above.


5. "Kanban". This is becoming an alternative software development 'framework'. 


It has various definitions.  And there are of course now many implementations. Many of which would no doubt be called "Kanban-but..." by some of the "Kanban" people.


Many good and smart people like the idea, and so no doubt it does some good. 


In Lean manufacturing, the Kanban cards represent things of the same 'size'.  In "Kanban", the cards represent User Stories, but so far as I can tell, there is not a strong discipline yet to keep the User Stories of the same size.  To me, this is a meaningful problem. (Long discussion as to why.)


Related to the size problem, "Kanban" has no metrics.  Thus, it is hard to demonstrate this way that it is successful.  (Yes, it is true that measuring success is difficult in almost every case.)


So, how much benefit "Kanban" provides compared to and separate from Scrum is hard to say. Objectively.


5. Engagement with Business/Management.  It seems pretty clear to me that Kanban tends to be used when engagement with the business side and/or management is not wanted or not possible.


Clearly, to me at least, this lack of engagement is not a good thing.  However, if it is not possible (for now), then perhaps it....is not possible for now.


Still, we tend to believe that Scrum, with for example the Sprint Planning Meeting and the Sprint Review (demo), and with Release Planning and Release Plan Refactoring (technically not a part of the core of Scrum)...Scrum with these things tends to build trust between the Business side and the Technology side.  Admittedly, often they start in a state of mutual distrust. Sometimes severe.  But these practices, if done well, smooth out the distrust and build trust.


6. Our recommendation: Scrum first, then add Kanban.


Some will note that this is similar to ScrumBan.  

We think that Scrum is plenty to implement on Day 1. And the Scrum Board, which comes 'out of the box' with Scrum, is already a very basic Kanban board.


We recommend that later, after the have Scrum working decently, the team use the ideas from "Kanban" and Lean to modify the Scrum Board into a specific Kanban board that reflects their work.  To us, the focus should include:

• Minimize WIP (work in process)
• Do not over-stress the system (a basic principle that deserves 15 blog posts)
• Single-piece flow
• Aggressively identify and remove impediments (eg, stoppages in flow)

Kanban or "Kanban" should not be used to reduce contact with the Business or Management or the Customers.  Rather the opposite.

Kanban and flow should not become a fetish.  (Nor should Scrum purity be a fetish, for that matter.)  There are good reasons to "stop" and do a Sprint Planning Meeting and a Sprint Review (demo), for example.  And to do a Daily Scrum.


If developers (coders and testers) still evince a preference for "Kanban" after these issues are discussed and explained, management needs to consider carefully the root causes. Humans (developers and managers) are of course complex, and many things could be at play.  But our first guess is that management is not aware enough how important it is for the team to have more fun when playing Scrum.


Fun is actually quite key to more creativity.  Which, in our kind of work, is key to higher productivity.

Scrum teams and our Mammalian nature

My experience with people doing Scrum is that we tend to take the "man is rational and isolated" hypothesis to easily.  Often it is not a thoughtful choice, just the implicit assumption of the way we are thinking or the way we speak.

Isolated and individualistic are key words. If you believed in them, you would build cube farms for people to work in. For example.

Is there another hypothesis? Turns our there might be several, but one is that humans are fundamentally like all 'pack' mammals.  We work and have worked, over thousands of years, in small teams, and these teams support the members inside the team.  We have a limbic brain or limbic system that supports the huge emotional and 'social processing' needs of pack living.

Here is an article on the limbic system.
http://en.wikipedia.org/wiki/Limbic_system
(As you will start to see, the spiritual, physical and thought-memory processing aspects of the brain are quite complex, largely sub-conscious, and quite fascinating. And there is much for us still to learn, IMO.)

How does Scrum inter-operate with this? 

Well, first Scrum seems implicitly to recognize the pack or mammalian nature of people, and organizes individuals into teams.  (Our mammalian natures may be one of the reasons for this, but certainly not the only reason.)

Scrum implicitly seems to understand that the team starts to be a source of well-being and of motivation for the individual. While the team demands something of the individual, it also supports him (eg. "can I help you with that?").   The team provides this 'pack' sense of belonging.  That they say we all need. (And I think I believe 'them' on this.)

More than a sense of belonging, it gives us a sense of purpose.  We want the team (pack) to succeed.  And we want to contribute to the team's success.   To the degree that each person identifies with the team, this is a whole set of subconscious associations that each of us tends to make with the team.

Did the designers of Scrum do all of this on purpose?  Well, I have worked with Jeff Sutherland a lot, and I have never heard him put things this way. But he has suggested that there is more going on than can be explained.

And now to you....

Assuming that we as humans are largely pre-rational mammals with a need for a 'pack', in what specific ways would you use this information to make your Scrum team more successful?

Thanks.

More about distributed Scrum - one example

There are so many situations and variations on distributed Scrum.  So that there then becomes so much to say about it.

So, as one example, imagine you have customers in the US, and your business people are in the US, and the best Product Owner is one of these business people.  He is pretty good as a Product Owner.

Imagine that you are doing a major add-on to an existing system.  The add-on can be considered a separate product.  So, knowledge of the existing system is important.  And a quick release of the new product is also important (within 4 months).  Assume that your current implementers are collocated in one city in the US (and could be collocated in one team room).  And assume that you can get people who are 50% cheaper in cost-per-hour (and by resume just as good) within 3 time zones (eg, in Canada or Argentina).  And that the cultural and language issues per se are not an obvious roadblock. And assume for now we are talking about only one Scrum team (about 8 people in total).  This is not a huge project.

What should you do?

Well, first, I can say from experience having worked with a couple of situations like this, that this kind of distributed can work.  Successfully (although to be fair, we did not do a blind trial to compare to an alternative course that might have been more successful).  And your firm does not have to be 'the best' at doing distributed Scrum (although it would of course help).

But nor would I assume, from what I have said so far, that distributed is necessarily the best course. Collocated might still be.

Let's go back a step.  How do you decide?

One question is: how do you define success?

Is it ROI?  Is it lower cost?  Is it productivity per unit of cost?  Is it faster time to market?  Is it less wear-and-tear on management?   Is it reduced risk?  Is it more accuracy in hitting just what the customer wants?  (And there are many others.)

Note: I find that faster time to market is often more important than many people realize.  In this example, I said 4 months.  This allows some time, but not too much, for knowledge transfer from the home people to the near-shore people. So, to me, in this example, it is a key issue, but not determinative by itself.

So, first, in your context, define success.  At least what you think it would be. (It may turn out to be something different later.  Live and learn.)  Look to optimize that success.

Then, do your best to look honestly at your situation (there is always the fog of war, or the fog of business or life).  What things should you do to make it (collocated or distributed) work better?  What specific questions should you ask (of each alternative)?

A couple of suggestions that might be helpful, depending on the situation.

• visit the 'near-shore' team.  Pick specific people.
• assuming you could pick 8 home people, when making the distributed comparison, decide who the 'top 4' would be. How would these people work with the 4 near-shore people?

Note: I have a strong bias that a distributed team should consist of 4 in team room and 4 in another team room.  This minimizes the typical us-them problem, and makes that problem more manageable. The us-them problem (or overcoming it) seems to be the key to real success with distributed.  From my experience and from what I hear from others.

• of course you will look at skill sets. I have already implied that both sets of people have essentially equal skill sets, but of course this may not be true in your specific situation.  In any case, you must look at how the skill sets of the 8 specific people mesh. Sometimes the resumes of the near-shore people are exaggerated. OTOH, sometimes we are surprised to find that the near-shore people are immediately better than our home people on our own systems. (Shocking, but it can be true.) 
• is your 'home' team diverse enough in a useful, knowledge creation way?  Will the near-shore people make the 'home' guys think more creatively?
• will the near-shore folks understand our business and the customers intuitively? (Do they have that tacit knowledge?)  If not, how much would it take for them to get it (more)?  Would that be a good challenge for the 'home' guys, to pass on that knowledge?
• will the Product Owner be able to motivate the near-shore people as effectively as the home people?  And communicate with them well, so that they quickly get the tacit knowledge of what is needed?  And therefore can build it better?
• is the PO willing to travel to the near-shore location? 
• how would the PO get the business value and requirements specifics to the near-shore people?
• how would the PO give the near-shore people daily feedback?
• to the degree there is a time zone difference (and in this example, we assumed that is relatively small), how will this work out practically?  Will one or both sides compromise?  eg, on the timing of the daily stand-up?

I hope these questions did not seem strongly in favor of collocated nor strongly in favor of distributed. One should approach the question, I find, with an open mind that is willing to find either answer as being 'right for this situation, as best we can tell now.'

There are lots and lots of other detailed questions to ask. 

Notice that I did not ask questions (yet) about how all the technical supports for distributed would work (although these are important questions, sometimes hugely important).  And notice that I asked a lot about how the business information, and specially tacit knowledge around the customers, gets into the heads of the near-shore people.  (Not that we can't also have a problem with that with our home people too.)

I also want to emphasize the knowledge creation dimension of the team.  Sometimes the near-shore people can add to that tremendously.  Sometimes they can seriously harm the knowledge creation.  It depends on the specific people, to a large degree.  As best I can figure out.

Enough for now.  Hope those ideas stimulated your thinking on the subject.

And hope you see (again) that 'distributed' is a very very big subject.

3 Drivers of productivity with Scrum

One question is: "How important is Scrum anyway?  I mean, it is always the team that does the work, whether they use Scrum or not."

And this is true. But I do think most teams (if not all) that use Scrum give themselves a big advantage.  They are more likely to be more successful if they use Scrum.  And if they will fail, that failure is more likely to be identified sooner. Which is actually a win!

OK, so what are the 3 drivers of productivity in Scrum?

Well, I want to focus on some not-so-obvious things.  Not the explicit dance steps of Scrum, but other things.

1. Creativity.  The team can and should be more creative than before.  Well, we all can always be more creative.  And one thinks that the Scrum team enables more creativity.  In every meaningful dimension relevant to their specific situation.

2. Velocity.  By removing impediments, the team can increase their velocity, as measured by story points completed per Sprint.

3. "The vital few."  By selecting the very least amount of work (features) to do (that still make up a minimum marketable feature set), we can get it done more quickly, not bore them with features they care little about, and make the system more elegant and easier to maintain and grow.  This can lead to much much greater productivity.

It may be easier to talk of these three things as completely separate. But, just as it is amusing to speak of body and soul as separate entities, it is more fun to live them as joint and inseparable entities.

Better distributed Scrum

I was asked today for my main suggestions for getting better at distributed Scrum.

Advice 1. Make a fair comparison between distributed and collocated in your specific situation.
a. Cost per hour, usually lower.
b. Hours of "distributed" members, usually more.
c. Hours for "local" members, usually more.
d. Net effect on delivery time, usually delayed.
Then, calculate the net net effect.  Does it still make sense to be distributed?  Often yes, and also often no.

Our opinion is that the main focus for the team should be on creating new knowledge. So, the old idea that we always find the people with the best existing knowledge is flawed. Creating knowledge is best done collocated.

So, here are some more ideas.

First, I find that collocated Scrum is always better.  Xebia has an argument that the way they do distributed Scrum is even better than collocated Scrum.  Maybe, but I do not think their hypothesis has been given a fair test. (This is a big subject; not the main topic here.)

Second, there are many types of distributed Scrum.  Some examples.
a. Distributed in the same city.
b. Distributed in only two team rooms, each in a different city, the cities not more than 2 time zones apart.
c. Dispersed across a continent (eg, the US), no two people in the same building, across 3 time zones.
d. Distributed in only two team rooms, each in a different city, the cities about 6 time zones apart.
e. Distributed in only two team rooms, each in a different city, the cities about 10-12 time zones apart.

There are some similarities across these situations, but they each are pretty different.  And might require different key components to the solution.

We have not mentioned yet cultural, language, and accent issues.  We have not mentioned organizational issues (eg, different firms, departments or reporting lines). 

1. Communication will be harder in many ways.

We know in our business (new product development) successful communication is very hard. And that's when they are collocated. Any kind of distance makes this worse.  So, we do everything we can think of to make it better. 

2. The team needs to Form, Storm, Norm and then Perform.

This is harder when they are not collocated.
Often they can get stuck in "high frustration."

3. The team needs to share information.

This is related to communication, but different.  Here we are talking about things like sharing documents, sharing diagrams, sharing code, etc, etc.

Advice 2: get your team to compare your current situation to a collocated situation.  What is the worst thing about it, as you all compare?  Work on that one big impediment.

There is ALWAYS something more that needs to be improved.  And usually that something will be a weakness arising from being distributed.

Ok, now I get to a series of suggestions, not all of which will apply to your specific situation.

Suggestion 1. In the beginning, get the Team collocated as much as possible. Ideally for release planning and the several initial sprints.   Many reasons, but probably the main one is they get to really know each other.  Very important.

Suggestion 2. Get them together more often than you currently can imagine. If in the same city, one day per week (or more).  If in two continents, a week each month (or as often as you can get).

Suggestion 3. Minimize the dispersion.  Two team rooms, each with 4 people is best.  Try hard to get the 4 to collocate in a team room.

Suggestion 4. Have frequent visits. Have one person from Bangalore visit the US. Then wait a week, and have a person from the US visit Bangalore. Do this more than you can currently imagine.

Suggestion 5. Spend money on really good tooling. This means: Scrum tool, great video conferencing, fancy Polycomm phones, leaving the Polycomm on during the day for impromptu conversations, high bandwidth between locations, fancy tools to emulate white-boarding or common editing of documents, common storage areas (eg, wiki or Sharepoint) that work really well. Plenty of throughput on the servers, plenty of server space.

Some teams may be into virtual presence things. Try them. If they work for your team, use them.

Suggestion 6. One of the key issues is: do they all 'feel' as though they are one team?  Or is there an us/them feeling?  (We want the former, and it seems to be key, almost always.)  If not 'one team', make that issue visible, acknowledge it as a normal problem, and then work on it.  (See some of the other suggestions, but there are also other solutions.)

Suggestion 7.  Culture. I find that cultural issues and misunderstanding go down when people start to know each other personally. So, first, do that. (See Suggestion 1.) But, depending on the people, there can still be 'cultural issues'.  Even within the US, for example, but certainly between two countries or two languages or two cultures (eg, east Germans and west Germans).  Get everyone some cultural education, courses, etc. Acknowledge that it is a common problem. And take the time to deal with it.

Now some more specific issues...

Issue 1. Where should the PO be?  No strong opinion. Where the best PO is.  Near the customers and near the team. With one of the two 'pods' of 4 people (half the team).  It depends on many factors.

Issue 2. Where should the SM be?  Again, no strong opinion. Where the best SM is. With one of the two pods. Ideally visiting both (or all) sites with some frequency.  Again, it depends on many factors.

Issue 3. When should the Daily Standup be?  Usually in the morning of one team, typically the "later" team.  If necessary, both teams should compromise some on the timing.

Issue 4. Language, accent issues in the Daily Scrum. This is a fairly common problem. Often the "early" people (if they exist) can write their answers to the three questions and send that to the "late" team.  And the discussion is more about clarifying and fixing things, than about the answer per se.  Of course, the better solution is to fix the problem at its source: improve the Polycomm or equivalent or send them to a language course.

Many other issues and ideas, but those suggestions should keep you busy for awhile.

Note: We have not yet considered scaling with distributed teams. This can be done.  With some success.  It is hard, it is ugly, but it can still be successful. We can say that Scrum will enable you to see the ugliest thing today, which does help you fix it.

One reason for "Business Value Engineering" - 2nd pass

Let's say some smart people have given you some great ideas about "business value engineering."

Let's say those ideas include:

• More customer demos
• Having the implementors visit the customers as they "do work" or "live" (depending on your product)
• A better BV Model
• Don't talk to customers (they don't know they want an iPad)
• Taking BV metrics after each release
• Using the Pareto rule more to skinny down how many stories go in a release
• Better PMO governance, to assure that problem teams are helped sooner (so that deliveries happen faster)
• Improving the creativity of the Product Owners
• Better brainstorming by the Business Stakeholders (or whatever you call them...the people that 'assist' the Product Owner)
• Priority Poker (wide band delphi to estimate business value, using Fibonacci cards)
• Agile Specs
• Rely less on documentation and more on conversation to assure the Implementors understand the story
• Story Boards
• User Story Mapping
• More wireframes
• Focus on "bang for the buck"
• A story breakdown structure, to use to manage with senior Business Stakeholders
• Completing more projects "early", eg, when we see that the benefit-cost ratio of the project has deteriorated to below alternate projects (and other criteria are met).
• Light use cases
• Etc, etc, etc

Note: I personally like some of these ideas a lot.  On the other hand, some I tend to shy away from.

First thing to observe (and the above is a short list of all the ideas out there): Too many ideas to implement all at once.

Second: Some of these ideas are contradictory.

Third: "Many seem very good ideas for us, but how do I prioritize?"

Yesterday I explained how we can use "BV process mapping" to enable us to see enough to prioritize the improvements we want to make.  (This really includes more than mapping, but let's over-simplify and call it just "mapping.")

As a minor benefit, BV mapping enables you to hear talks, and identify which part of the BV engineering process the person is talking about. In other words, you can put others' ideas in a context that, hopefully, makes the ideas more useful or at least actionable.

One reason for "Business Value Engineering"

I said recently that "business value engineering" is the place we can improve the most.  By which I mean:
(a) identifying the small features that the customer will want the most (once they get them), and
(b) identifying the MMFS (minimum marketable feature set).

Perhaps we should also add to this:
(c) identifying a "business model" that is reasonably attractive to customers and successful for the firm.

By this we mean, all the pricing and servicing and delivery things we put around the product.  If these don't work, the "product" per se may be wonderful, but it will fail.

We need to at least briefly mention the time dimension. For most products, the customer explicitly or intuitively realizes that he is entering into a long-term relationship with you. (At least with all the new products that I deal with.)  So, you must also have something like a "product life cycle" approach that is reasonable.  If you want to succeed longer-term.

I think that improving velocity (as defined by story points) is important (as suggested by recent posts), and important in many ways.  But I think improving business value engineering is, virtually always, the path to more success quicker, for the team.

Almost always, the biggest impediment for a Scrum team is a weak Product Owner (who is responsible for business value engineering).  Usually the person per se is very strong (smart, articulate, etc), but largely untrained and ill-equipped to be a fairly good product owner. Much less an excellent one.

***
When I talk about business value engineering, I always want to talk about the full end-to-end "process".

I think many people have many wonderful ideas about how to improve things.

But, I find that...
(a) no one can implement all of these proposed improvements at one time (usually it would take years to fully implement them)
(b) some of the proposed improvements are contradictory, or at least don't work well together with certain other things
(c) for a given company in a given industry, given their own current "processes," Improvement A is often much more useful than Improvement B.  While, for another company, Improvement B is more important.

So, as with Lean Value Stream Mapping, one of the key reasons to do a business value engineering map (with hypotheses and assumptions) is to identify the priority of the improvements.

Prioritizing the improvements is very important.
I'd rather make a little progress each month than "lots and lots" of progress that is supposed to arrive in 3 years.

Scrum Team in Waterfall Land! What to do?

The real question sent to me was: What are some tips for integrating our SCRUM model with non-Scrum groups who will not be adopting the process?

One can go many places with this question, and there could be other questions within this questions.

For now, let me answer two questions.


1. In general the culture and the management systems (eg, metrics) is used to waterfall.  With a Scrum team(s), what should we do about this?


The finding is that this will remain a small-ish and firm and increasingly annoying impediment until you fix it.  


Fixing it entails, ultimately, changing the whole company culture in a pretty significant way. Which, for a large company, takes a long time.  Sometimes, you can select out a major group within the larger company, and just change that culture.


Doing this is hard work and takes time.  It must be balanced against fixing more immediate and pressing impediments now.


How to do it?  


Gather a small group of change agents. Regularly.  Identify the changes you want to put into effect...how you want to go about changing the culture, at least in some ways.


Fearless Change by Manns & Rising and A Sense of Urgency by Kotter are two places to get ideas about how to effect the change.


For metrics, I would initially get the Scrum teams exempted as pilot efforts.  Then I would suggest that the basic Scrum metrics (velocity, Sprint burndown, Release burndown, etc, etc) be used in place of the old metrics.  You will win some of these discussions and lose others. Typically, this means the team must do "extra" metrics, typically for no good reason except that "they are there."  Make clear the extra cost to the team in doing the extra metrics.  Over time, you will likely win more and more of these discussions as people become less afraid of the Scrum teams.


2. A Scrum team must work with other groups that are used to waterfall.  What should we do about this?


The main advice is: use common sense and do just barely enough to make it work.


In general, different people will react differently to an agile-scrum team.  So, your response will depend in part on how the other people react and perform.


In simple terms, there are two situations: 
(a) they provide deliverables to the Scrum team, which affects what we can deliver or complete.
(b) we provide deliverables to them (which affects them and our reputation).


First, prioritize the groups the Scrum team is working with.  Put the most 'work' in on the team that is most important (obvious as soon as I say it).


Second, are there any personal relationships we can leverage, such as, Team Member John is a friend of George (who is in Dept 1)?  

Often, John can visit George, and discuss agile-scrum a bit. (And maybe take the time to discuss Scrum over lunch with George's manager too.)  This reassures George.

Then John should ask George "I know this Scrum stuff sounds a bit weird and is certainly different than what you are used to, but can you help us out?"  And often George will do it, especially if we/John make things a bit easier for George. ("I'll scratch your back, if you scratch mine.")  It's all part of the unofficial 'pizza & beer network' that many of you know well.


Sometimes this is enough.


Third, let's imagine that George's boss hears that George is "being easy" on the Scrum team and orders him to "be tough, demand that those guys fill out all the usual waterfall forms each time! And abide strictly by the rules!".  And let's assume we know that this is a silly bureaucratic waste (mostly).


The next step is to have a high-level "Impediment Removal Team" (IRT) that hears about all the top impediments from all the Scrum teams.  Assuming this impediment (George's boss) is important and we are sure we are right to complain, then the Scrum team sends this impediment to the IRT.  A person from the IRT (a senior level person) goes to talk sense to George's boss. If done right, surprisingly George becomes more cooperative with our Scrum team in a few days.


Sometimes this is enough.


Sometimes the problem is not George's boss, but only that George has 15 things in the air, and we are not that important to him, so his performance for our team is not reliable.  In that case, we can set up a special board (in the team room or virtual team room) and John or someone else in the Scrum team can 'manage' George, eg, visit him often, send him ticklers, go to his boss, help George fix his own impediments, etc, etc. 


Sometimes George is so key to the Scrum team for a Sprint or two, that we have him come to the Daily Scrum every day to report on his progress.  Sometimes we have somewhat formal 'weekly' meetings with George.


The main thing is: we add to 'Scrum' just enough other stuff to make things work with George and Dept 1.  We try to ignore or minimize the stupid stuff as much as possible, and get as much value from Dept 1 with as little effort as possible.  Sometimes we just accept some degree of 'stupid stuff' from Dept 1 for a while....but only for a while.


Again, each department or group will be different. Some of things we do for Dept 1 might be overkill for Dept 2.  So, we adjust our response for each department and each "George".  Based on our team's need and who they are.  So, the way we work with Dept 3 will be different than how we worked with both Dept 1 and Dept 2.


Sometimes a 'serious' issue comes up.  Be ready to explain Scrum, explain how it is less risky than other approaches, and why it does not need to comply (completely) with the usual BS bureaucratic stuff that we have always been doing.  But learn to say this in a nice, non-confrontational way.  That sounds (and is) supportive of the main business drivers in your firm ("we have to have faster time to market", "we must reduce costs", or others).  But be reasonable.  Bend 'em but don't break 'em.  Remember that changing organizations takes time, and much of it is based on goodwill.  So, increase your capital of goodwill and spend it judiciously.  


Changing an organization takes time.  Keep plugging, but have reasonable expectations.  You don't have to win every battle in the first minute.  Be adaptive.

Getting Higher Velocity - Take 3

A recent conversation leads me to discuss some basic issues.

• Why do we care about velocity?

To be honest, higher velocity is less important than better focus on business value. Higher velocity going the wrong direction does not help at all, and usually hurts. We always need more clarity on: (a) what the customer will really want (when we deliver), and (b) how focus on only the 'vital few' things (eg, for the next release).  These two things are more important than higher velocity (in all real life situations that I see). (A nod to Ron Jeffries for forcing me to say this.)

But, if we assume that the Product Owner is taking us in the right direction (having us build high business value items) and on the MMFS (minimum marketable feature set), then higher velocity is better.

And, when we remove impediments, one of our key reasons for doing so is higher velocity.  Yes, we want more fun, we want more creativity (which does not always result in higher velocity per se), we want higher quality, we want less technical debt (which should come out as higher velocity eventually), etc.  Still, I assume the other things, and so higher velocity is the key thing.

• Higher velocity is just another way for managers to screw the team members

Well, I completely reject this way of thinking.

Not that it doesn't happen.  It does.  But no self-respecting manager should think this way.  About teams doing knowledge creation work. 

If as a manager you have an important project, and you think the only way to be more productive is to work harder (higher stress) and longer hours, then, based on over 20+ years of experience, I think you either have a bad team or you are a bad manager.

Higher velocity never means working harder (well, more than 40 hours per week). Often it means working fewer hours.

Velocity should never be used to drive the team into a death march.

The team should use velocity to protect themselves from what I call "the magical thinking managers", which just stamp their foot in demanding 'higher productivity'. Stamping of feet and slogans are useless. In overly-simple terms, we must remove impediments.

• For the A3, it is difficult to estimate the velocity impact of fixing an impediment

Yes, "to predict is difficult, particularly of the future".  This is true, and always will be true. Nonetheless, we must.

An predicting things related to human behavior is hard. Predicting things related to multiple variables is hard, but always required in business (or so I find). There are timing issues related to prediction (when will the benefits start to show).

My recommendation is to under-estimate the velocity impact to some degree. And to explain the issues of prediction to the manager. A decent manager understands these issues. A decent manager does not expect the team to be accurate in predicting each team. A decent manager expects the team, over a series of A3's, to achieve somewhat more results than they predict on average.

Remember that we only have to predict enough improvement to justify the cost of investing in the fix.  Again, I find that we can under-estimate the velocity improvement and still easily justify the cost of the fix.  Usually.

Remember that the main reason to spend time or money in fixing an impediment is the benefit, and the main benefit is improved velocity. At least to a manager.

• For some impediment fixes, the main benefit is not velocity improvement

Fine. True. Give velocity improvement its proper place. If it is third, then list it third.

However, it is my experience that velocity improvement is more important a factor than most team's think. Largely because most teams are not used to thinking about velocity.

• We can only make minor improvements in velocity

 This is baloney!  "We can't possibly go any faster, captain!" (In a Scottish accent.)  Baloney!

This is the major problem, I find.  This belief that we as a team are almost perfect.  It is, of course, usually expressed in the negative of "we can hardly go any faster."  Everyone recognizes the idiocy of saying "we are perfect", but to suggest we are close to reaching some upper threshold of productivity sounds reasonable.  I mean, we are all smart people around here, right? And we run a professional IT shop, right?  And we are a strong team, right?  And we have all the right tools to run Agile, right?

To be honest, there is so much improvement to be made, it is unbelievable!  To be honest, "it's not what you don't know, it's what you know that ain't so."  We are smart, but some of our smarts are unbelievably dumb!  And all the rest of those assumptions above (and others) leave even more room for improvement.

Now, it is true that the team is working hard already, probably already too many hours. And so "being more productive" feels like a request for more hours.  And a request for more hours is wrong! I won't try to explain here why it is wrong.  But it is wrong! Wrong!

But that does not lead, logically or any other way, to the notion of "we can hardly go any faster".

Usually we can easily go twice as fast in the next 6 months. If...  And the main "if" is (I think)....if we will open our minds to identifying some of the real impediments around here. But, to be honest, there are many "if's".

• If we go faster, we'll get into more technical debt

Wait a minute!  When I usually hear this, it tells me that the team has a weak definition of done (which maybe it does not follow for much, really). And it is, in effect, pretending to have a certain velocity, but is is really just lying to itself.

It is like saying "I ran a mile at sustainable pace", but in fact it was 8/10's of a mile and you are just about dead.

A real velocity should accumulate zero (well, almost zero) technical debt and should be achieved at a sustainable pace. And it should be based on a strong definition of done. That the team actually follows.

So, once you identify your real velocity (much lower), then doubling it will be relatively easy.

***
Enough for today.

Paying for Courses

As a reminder, we posted about Paying for Courses a while ago.

We wanted to remind people of the problems that can arise, especially with paying with a credit card via the internet.  If can be a problem, and it can seem insurmountable at the time. But actually it is usually very easy to fix.

If it happens to you or a friend, a bit of patience and a phone call or two will get things resolved. Almost always.

See: http://agileconsortium.blogspot.com/2010/01/paying-for-courses.html

Intermediate Certified Product Owner course Charlotte Dec 7-9

We have a intermediate Certified Scrum Product Owner course. In Charlotte, Dec 7-9.

Leader: Joe Little. Because he has an MBA, discusses BV Engineering, and has worked with Jeff Sutherland and the Poppendiecks and other great coaches, we think this course is very valuable.

Potential Product Owners, ScrumMasters, and managers should take this course. This will be an "intermediate" version.

Usually the simplest and biggest change in team performance is "improve the Product Owner".

Go here for further details.

Scrum is a major management discovery

Steve Denning wrote an article titled "Scrum is a major management discovery."

For those of us who have been doing Scrum for a while, saying that Scrum "is a major management discovery" is, well, obvious.  Or it is clear and unfulfilled.  Or it is something we have forgotten.  Or it is something we never thought about ("I thought Scrum was only for people like me, developers!").

In any case, I think it is important to say.  Both today and in the future.

Steve Denning is a good and smart man. A man on a mission, and I think a good mission.  Here is his article.

***
Why is Management important?

So, let's look at this hypothesis (a major management discovery) from a certain point of view.  What is important? Or where is the power?

If one believes that managers are responsible for the mess we are in or, in any case, only managers have the power to change things, then the fact that Scrum is a major management discovery is quite essential.

A contrary hypothesis is that, despite what some people may think, the real power is with each individual, and resides there in such degree as that person is persuasive and connected to the truth (some combination of those two).  In other words, any one of us can have great affect on our brethren if one speaks well and if one proposes actions that are connected to the truth.

Aside: What I have suggested is that the power 'vested' in managers is actually largely a facade of power with little substance, except that other people happen to believe it sometimes. Real power only comes from a person's leadership skills, eg, their ability to persuade and to speak the truth.  And anyone, with or without a manager's official title, might have and use these skills.  How many Arab springs, or 1989s, or American Revolutions will it take until people see that "we hold these truths to be self-evident, that all men..."??  [Be he right or wrong (in whatever dimension you wish to speak of) Hosni Mubarak thought he was pretty darn powerful only a few months ago.]  And that means we all are equal, ultimately, in power.  Even power. Yes, yes, I know it seems to many of you very impractical of me to say so.

Now this second hypothesis does not imply that we leave official 'managers' out.  It just means that anyone can pick up the torch.  Anyone can start the change, or take it to a new level.  You don't have to wait for the managers to be convinced!

***
Scrum changes everything

I agree with the view that as soon as one introduces Scrum into an organization, the people start to see the impediments and they start to realize that almost everything must be changed.  At least some, not completely, but at least some. (Yes, completely, in some areas.)

I agree, based on experience, with the view that Scrum can have a greater positive impact (on people, on the firm, on more customers) if the managers and 'everyone' in the organization 'get it'.  

But Scrum can still make a serious impact on some people's lives before 'managers' know about it.  Or agree with it.  Or do much about it.  We can definitely start Scrum before managers fully 'get it'.

It is perhaps now worth repeating that Scrum itself is not a silver bullet.  Scrum does many things (and one might say that the spirit of Scrum does yet many more things), but one of the chief of them is to set up an inspect and adapt system. This system shows where the biggest problems are.  But it is up to the people to take action on that new knowledge.  Scrum will not magically, by itself, fix things.  The people must do that. And often that means that the managers must (or should) approve the fixes (agree, give people's time, get money approved, whatever).

Also, the basic ideas of Scrum apply to many kinds of work, and in general apply at all levels of an organization.

***

Some additional key ideas

In his article, Steve mentions 10 salient ideas about Scrum.  I strongly recommend that you read his article and consider them.  Steve himself does not think his list is perfect or exhaustive, but it is useful to review and consider and put into action more.

To him, some of the ideas I will mention below were said or implied in what he already said. But I want to make them more explicit.  And perhaps I add one or two new things.

My idea is that these underlying principles of Scrum also apply to management work and to the work that managers do with teams.  So, managers, listen up:

1. How do we know if thinking (knowledge work) is good?  Scrum's idea is that we let 'em think for a while, but show me some 'working product' at the end of the Sprint!  (say, every 2 weeks) So the right people can decide if it is useful thinking.

2. "Six blind men and an elephant."  No one understands 'everything' anymore. To figure out anything, we need to get a small team together, have them fight about it and create knowledge together, and then we can make some progress that the customers would really care about.

3. "The bad news does not get better with age." Yes, some of the suggestions of Scrum and Agile are 'extra' overhead from a certain point of view.  But the benefits of that extra overhead are so great in discovering 'bad thinking' (simple example: bugs in the code) that it is obvious we must accept the 'overheads'.

4. We always start with seriously incomplete knowledge. Therefore we must enhance learning. We must accept small failures as the best way to learn fast. (Well, we must accept small failures in any case. But use them to learn fast also.)  And we must organize things in such a way as to take advantage of that learning as fast and as much as possible.


5. "People are remarkably good at doing what they want to do."  By and large, knowledge work is (or should be) very creative.  (Again, a lot of the creativity happens as a team of 6 or so.)  And the work, if you remove the de-motivators, is inherently interesting (well, to those who will do it well).  So, we must treat the workers more as humans with intrinsic motivation and much much less as things or cattle that must be prodded.  Daniel Pink's book "Drive" gets into how motivation works with people.  But the basic principles were noted by some wise coaches some thousands of years ago when they said: "Do unto others as you would have them do unto you."  Of course, we were all taught this by our mothers, but who knew this would actually help us and our firms make more money in business?  Who knew that customer delight is driven by workers having more fun!

Aside: My strong bias is with Peter Drucker (wikipedia him), when he said that the purpose of the firm is to satisfy customers. (And that shareholder returns were just a constraint.)

6. "You have to go slow to go fast."  Lean-agile-scrum have shown that there are many counter-intuitive principles that must be followed if a team is to achieve real success.  Well, the principles are counter-intuitive to us, who have been trained so long in the wrong ways of thinking about these things.  So, multitasking, stretch goals, giving teams multiple projects at the same time, being sure everyone is 100% occupied, large queues of work -- all these are almost always stupid ideas, even though they seem good from a certain point of view.  Who knew the customer was important?  Who knew that if you did not allow slack in the system, you just about assured that the customer would never see ANY feature any time soon?  One of our favorite counter-intuitive sayings is "you have to go slow to go fast".  Meaning, as indicated earlier: Yes, early and frequent testing is an 'extra' overhead, but the benefits in keeping the bad news from getting worse with age are so great that, it is obvious, we MUST go slow to go fast.

***
In closing

Steve mentions dynamic linking. From that phrase (which I am interpreting a different way than Steve did) I want to lastly emphasize that the values, principles, and practices of Scrum are themselves dynamically linked.

Scrum, if played well, is like a good ice hockey team.  Every player on a great team is inter-linked, and every pass or shot is inter-linked. So that a single pass can be both a great defensive move as well as set up an offensive break-away that leads to success (puck in net) seconds later.  So, similarly, all these things about Scrum are inter-linked.  Fluidly. And some of the linkage is a dynamic tension. Simple example: In general in agile we want less documentation but we want more and better communication.  Which might mean more documentation of just the right sort (I'll call this an agile specification), although overall there is less documentation.

We have so many more benefits to get out of Scrum.  For so many more people.

Freedom

For reasons unknown, I ran into a picture I took of a statue of Jefferson in Paris (it is along the Seine, near the Musee d'Orsay).

Then I saw something else which led me to this quote from Jefferson, mainly about the meaning of July 4th.  I think it has a wider meaning, and so I quote it here:

… May it be to the world, what I believe it will be, (to some parts sooner, to others later, but finally to all,) the Signal of arousing men to burst the chains, under which monkish ignorance and superstition had persuaded them to bind themselves, and to assume the blessings & security of self-government. That form which we have substituted, restores the free right to the unbounded exercise of reason and freedom of opinion. All eyes are opened, or opening, to the rights of man. The general spread of the light of science has already laid open to every view the palpable truth, that the mass of mankind has not been born with saddles on their backs, nor a favored few booted and spurred, ready to ride them legitimately, by the grace of god. These are grounds of hope for others. For ourselves, let the annual return of this day forever refresh our recollections of these rights, and an undiminished devotion to them.

Do we each for ourselves, and for those we manage, respect the opportunities and responsibilities of freedom?

Adam Smith described well how the invisible hand allows the economic participants to enjoy the economic benefits of freedom.  In, say, a country.  We are still learning how the same basic things happen in a group of 100 people.

I do not think waiting for others to tell us what to do, or to wait for them to change, or to wait for them to fix some things, I do not think these things will enhance our freedom. Or really do much for our lives.

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!