Release Planning: Business Value

Now we move on to Business Value in Release Planning.

For those who have not been reading before, this is a continuation of a series that starts here.

Per Yogi Berra: "You have to be very careful if you don't know where you're going, because you might not get there." 

If you are in the mood, this can be very funny.  Or just a chuckle.  But this is our problem. How do we identify what the customer really really wants.  Well, business value is part of that.

When we did the vision, we directly or indirectly probably talk ed about business value.

Now we want to talk about business value for each individual PBI (product backlog item) or user story.

Again, we want to have two actions within this.

People: Again, to do this work, I want the whole team of pigs (PO, SM, implementers) and the BSHs (business stakeholders).  Again, the BSHs are the best people we can get to attend Release Planning to represent the customers and the firm well.

Business Drivers:  It is my contention that the key thoughts and phrases we want to use about business value vary by the situation. The product, the customers, the people involved.  It may be that the high-level basics of business value for all for-profit firms could be distilled into 5 phrases. But I find for useful discussions in specific products, it helps to 'invent' the 3-7 top drivers each time.

Business drivers may include making money, risk, customer satisfaction and lots of other things. Or not.

So, they whole group gets together and discusses and agrees on the top 5 (about) business drivers that apply to the set of work (the product) as represented in the existing Product Backlog (its PBIs).  Sometimes this will lead to the identification of some new stories (or PBIs).

Priority Poker: Most of you are familiar with Planning Poker, which is where we use the planning poker cards to vote as a team on the relative story points of [new story] compared to the 1 SP on the [reference story].

Priority Poker is very similar to Planning Poker, except that it is about business value, not effort.  In fact, we assume there is no correlation between effort and value.

So, the similarities: use a team, vote, use Fibonacci cards, discuss assumptions, share knowledge and ideas, average the numbers after reaching some consensus, the number is comparative, relatively quick, somewhat imprecise for each individual card but fairly accurate over a set of cards, etc.

Some differences: a different team (the experts on business value), reference story is the TOP story (for business value) rather than the SMALLEST story (for effort), prefer the real Fibonacci sequence at the top end, done in the presence of the implementers, etc.

So, first the top experts (usually between 4 and 7 people) on business value huddle around the user stories (or PBIs) and determine which one has the most business value.  This one is arbitrarily given a value of 90 or 100 (it is minor which one you choose).


The Business Value experts are typically the PO, the BSHs and maybe one member of the Team who has a lot of experience with customers. Or for some other reason, knows BV pretty well.

OK, now we have the reference story for Business Value. Then the BV experts start to add relative BVP (business value points) to each user story (or PBI).

Here are the rules:
* pick a story randomly (we do not want to prejudice the panel by already putting stories in BV order).
* discuss the story
* identify drivers of BV for that story (but not how much the driver is affected)
* ask each person to pick a Fibonacci card, but don't reveal the vote to anyone
* once everyone has selected a card, 1-2-3, they all reveal the card
* the people with the two extreme cards discuss why each was high or low
* the team re-votes until within 3 consecutive Fibonacci cards of each other
* then the averages the numbers, to the nearest integer.

Example: The vote is 34, 55, 55, 89. The value for that story is 58.

Meaning: If the reference story is 100, and they vote 50, that means that they feel that the new story has 1/2 the business value of the reference story, considering all the different drivers of business value.

The others listening (the non-voters) may ask questions at the end of each "card."  The purpose for them being there is so they can pick up the tacit knowledge about business value, and which stories are more important (and why).

Final review: Once all the cards have been assigned BVP (business value points), the experts then gather around all the cards on the wall, and look for "the stupidest" numbers. Often in 50 cards, they will identify 3 or 4 that seem stupid now.  Maybe this 30 seems a lot bigger than the other 30's.  Maybe that 70 seems too high now.  The person identifying can ask the experts to re-vote.  In general, we would expect them to re-vote on a few. After all, now that they have discussed them all, they are probably smarter now about business value than when they started.

Timing: Priority Poker takes some time, but is worth it.  Understanding Business Value is very, well, valuable.  Of course, one person in your group may talk too much.  So, the facilitator must monitor that.

We find a time box of 1.5 to 3 hours is usually quite sufficient for 50 cards.  But again, if the discussion is deemed valuable by most of the participants, it is unlikely that 4 hours would be too long.

Comments:
We like them to think more and more that no two things have exactly the same business value.  Yes, for example, we may have to do 5 steps in a business process, but steps 2 and 5 are exciting.  The others are just chores that must happen. Steps 2 and 5, when we deliver them to the business and deliver them well, that's when the big smiles come out.  Or that's when the big money is made.

Often new stories are identified. Or a few existing stories are deemed so big, that they must be sliced and diced into smaller stories.  This is normal.

Sometimes an expert may feel he does not know how to vote on a specific story. He should take his best guess anyway. And learn from how the others vote.

Averaging: Apparently there are many who have been taught Planning Poker and told to force the team to consensus on one Fibonacci card. This is incorrect for Planning Poker.  The research shows that averaging is more accurate and faster. (If not too fast.)  And the same applies to Priority Poker.

Accuracy: Are all the cards perfectly accurately assigned BVP?  No!
Have we learned a lot more about our different ideas about business value and shared that throughout the group?  Yes!
Did the numbers help? Yes!
Can we change the BVPs later, once someone becomes 'sure' that one or more is wrong?  Of course, by team vote.
Will we change some? I absolutely expect it. We want you to get smarter and smarter about business value, in multiple ways. This should in part be reflected in changes to the BV points.

Epics: If an epic is worth 100 BVP, does that mean that when it is broken into 5 stories, then each of the 5 is worth 20 BVP?  No, we don't assume that. In fact, along with Pareto, we assume that there are more vital parts of the 100 story, as well as less vital parts.  In the simplest world, one of the smaller stories would be worth 80 BVP and the other 4 stories would total 20 BVP together (the 80-20 rules).  But life is not always that simple, either.

***

Results: One clear result is that we have a BVP number on every PBI (or user story).  This is remarkable.  And no one in the group thinks any of the numbers totally suck.

More importantly (IMHO), the whole team starts to share a bunch of ideas about how the BV is distributed amongst the features.  Every feature is not equal.  This is a great thing.

Typically new stories are identified. And typically the MMFS (minimum marketable feature set) is starting to emerge.

But the main thing, to me, is that the whole group starts to share relatively specific tacit knowledge about the relative business value of each story.  Specific down to the user story.  Not hand waving at the vision level.

This work changes motivation. And it changes the behavior. Of everyone.  The business guys start to respect that the geeks understand them a little. And the geeks now understand better why business-side work is so hard.

***
The real value of all this work is getting closer.  And will be revealed soon.  Just a few more steps....

The Team and introverts

I have several friends who are introverts.  And, as I get older, I recognize my own introvert side. And I appreciate it more, and accept it more. (The MBTI says I am an extrovert.)  It is to one introvert friend that I dedicate this post, a friend who has given me so many insights into people, and is the person I know who is most insightful about people.

One of the issues with Scrum is that the people in the "team" do not feel and act as a Team.
This lack of a sense of being a real Team is often key to why a Scrum implementation may be mediocre.

(And let me go further. One of the great values of Scrum is that allows people, if they want to, to have great working relationships, honest and productive ones, with a small group of people. In a very satisfying way. Srum won't make it happen, but Scrum tries to facilitate it happening. And it happens often. Better relationships with more fun. So, we are also in search of this.)

There are many root causes for this (for a lack of a sense of being in a real Team).

One of the root causes is that the team members may include both extroverts and introverts.   Now, as such, having both introverts and extroverts on a Team is not the real problem. But let me discuss....

A good discussion of these two types is here.

As I typically see it, extroversion is dominant in North American society, and perhaps yet more so in US society.  Business managers tend to be extroverts, for example.

Fairly often, in a Scrum team, both the Product Owner and the ScrumMaster are extroverts.  And fairly often, most of the other team members are introverts.  At work in software development, introversion tends to mean being quiet, slower to explain, less interruptive in conversational style, and not explaining or sharing many things that one is thinking or feeling.

So, just from what I have said, you can see that extroverts and introverts have a good chance to see the Team differently.  Of course, any two people can see the Team differently, but an extrovert and an introvert, being less likely to explicitly talk about it, are more likely to remain with differences after some time. Or more differences.

Now, contrary to what some people think, introverts do not always like to be alone.  But they tend to want to manage their 'together' time and their 'alone' time in a different way than an extrovert would.

Similarly, introverts tend to take longer to 'get to know' the other team members (if they didn't before). And tend to not 'open up' in the Team until they have 'gotten to know' them.

Also, some strong introverts are more likely never to have been on a good Team before. For example, they may not have been on a successful sports team.  This can of course happen with an extrovert too, but I think it is somewhat less likely.  If you do not have the tacit knowledge of a good Team, it is harder to assist in forming a good Team.

***

My conclusions from experience:
* Both extroverts and introverts can form good teams.  And can do so together.
* Introverts tend to form as a Team more slowly.  This delay is not a hugely significant factor, except that it must be respected.
* Extroverts tend not to understand the dynamics of team formation for introverts.
* Extroverts tend to not appreciate that their own talkative qualities are felt as intrusive and impolite by introverts. (Similarly, introverts may fail to appreciate how their behavior or quietness can be perceived by extroverts.)
* Some of the Scrum and agile ideas and practices can seem intrusive to introverts, especially if forced too much and not explained well. And if no accommodations are considered for introverts. 
* Addressing these issues may take some time and effort, but it is well worth it. When extroverts and introverts appreciate each others' qualities, it can lead to a much stronger Team very quickly.

***
Again, people who have been in a good Team can appreciate that there is something magical about it. Joyful, fun, fulfilling. In part, it is the satisfaction of doing good work together. However you describe it, it is a good thing. And we want everyone, of whatever type, to experience this part of life in a better way. We think it is possible for almost everyone.

Agile Principles and Values

Jeff Sutherland recently wrote, apropos the Agile Manifesto, a bunch of things about some key Agile values and principles.  Excellent stuff.

As some of you know, I think it is essential for people doing agile or scrum to know and be in sync with the values and principles. What I call "the music."  Otherwise, the dance steps of agile or scrum, without the music....they just always dance them ugly.  Well, anyone would, without the music.

See here for Jeff's thoughts.

And here is one quote:

• Commitment to work together happens only when people agree on common goals and then struggle to improve both personally and as a team.

 Enjoy.

Release Planning: Product Backlog

After we complete the Vision, we must develop the Product Backlog. (Please go to this post for an overview of what I think Release Planning includes.)

There are two parts to this.

First, we must define the Roles to use in the User Stories.
Second, we must write User Stories.  I call this second part a User Story Workshop.

Let's break this down.

Assumption:  We have a new team that is doing Agile-Scrum for the first time.

Who: We want the whole team of pigs (PO, SM, and implementers). And the BSHs (business stakeholders).  Usually you want the 3-5 best business stakeholders you can get.  They are never perfect, but at least they are the best you can get. The Product Owner is usually the main person driving which BSHs to bring in.

The Product Owner is leading the content. The ScrumMaster is leading the facilitation. 

What: We want about 5 to 7 roles. These are the roles to go in the User Stories.

And then we often want about six months of work for some good release planning.  (In some situations, we want more or less work.)

If we want about 6 months of work, lets do some math.  My rule of thumb is 8 stories per 2 week Sprint.  6 months work is 13 sprints.  13 x 8 = 104.  Now, those stories are all small enough for a Sprint. So, in Release Planning, we can be pretty happy with 50 stories (average about twice as big as a Sprint-sized story).  So, this gives us a rough idea of what we are shooting for.  Of course, we will learn a lot later, and can make many adjustments.

So, we only need about 50 stories that cover about 6 months worth of work.

How: Brainstorming to get 5-7 roles can be easy or can be hard.

We mostly want different user types (roles), end users of the system or product. But more generally, we want any role that would want some feature in the product.  Even if they don't (directly) use the product.

(Note: These are not the roles of the Scrum team members. A fairly common question.)

Some teams will come up with 30 roles. Some will come up with only 2. We want to either synthesize or break down until the number of roles gets in the 5-7 range. Something magic about that number. But not worth dying for.

Whatever they do, it will probably work the first time. But it will become better as they start to get practice with stories, and appreciate, tacitly, the characteristics of a good story.

OK.  Now, with the Roles, the whole team starts to write stories. We let them self-organize.  We give them 15 minute timeboxes.  At each 15 minute break, they "check in."  They inspect progress and see if they want to adjust anything. Usually they see that they want to write stories faster. 

Typical productivity for a team is to average about 1 story per minute.  So, in about 50 minutes.....50 stories.

When they feel finished, we recommend having the whole team gather around all the stories (imagine them on a wall).  They should look at them, and try to see what needs improving the most.  Maybe a few aren't worded well.  Maybe a few need the INVEST criteria a bit tighter.  Maybe two team members identify 3 missing stories.

What were the INVEST criteria?
* Independent (we try to maximize this, but we never can make all stories independent)
* Negotiable
* Valuable
* Estimable (clear enough that we feel effort can be estimated)
* Sized Appropriately
* Testable

It is sometimes useful to get more sophisticated.  I don't like to do that the first time.  They need to get one cycle of just doing the basics.  Probably several cycles.

We recommend that the PO answer questions and talk about the product that he envisions. But let the others identify the specific stories.  He gets them more engaged. They get more creative. They have better motivation.The PO can always add or modify later (if there work is imperfect).

Why?

Why do we have all the pigs and the business stakeholders?
Several reasons I will mention.

1. We want the whole group to share whatever tacit knowledge they have with the rest of the group.

It turns out that everyone has some knowledge or ideas to share. Or at least some good questions. Well, almost everyone (yes, there are a few exceptions sometimes on this one.)

2. We want the group to create knowledge together.  And share it together.

A bunch of things happen has they create knowledge. One is that they all start to form a similar mental picture (or pictures) of the product and the effort and things related to it (eg, the architecture).

3. We want the team to develop motivation together.

Finally, having been involved in the creation, the whole thing becomes their 'baby.'  This is far better motivation than we get from 'the mushroom treatment,' which is de facto the most common thing. (The mushroom treatment is where the team is kept in the dark and fed manure -- this is great for growing mushrooms, not so great for growing teams.)

Yes, it is somewhat expensive to have everyone involved.  But the payback during the project is very high.  Very high. And the time to market is better.

Time Box: As indicated, I like to have a series of 15 minute timeboxes, where the team checks in. Are we going too fast or too slow?  Anything we should change? Who is talking too much, who too little?

Usually the whole thing can be done is 60-90 minutes.  But really it is not a problem if it goes 120 minutes. Or even more. The main thing is, as SM, if one guy gets talking and worrying, and nothing is getting done, you can't let the team just spin.  Someone must fix it, and get them productive again.

Common Issues:  I like brainstorming rules. Meaning: Anyone can create anything, and for this timebox (say, 15 mintes), no critique is allowed. Then an editing or 'fixing' timebox, where the team reviews and improves the roles or stories.  Then another 'create anything' timebox. And so on.

I find creating one story and then criticizing each one is too slow, and inhibits the team too much. Especially beginning teams.

Another issue is having only one person write the stories. If a team really wants to do this, it is not terrible. But things usually go faster if everyone writes.

Not sharing. I think it is useful if, as a person writes a story, he shares it with the group (says the words of the story out loud). That way, no one writes the same story a second time.

Top Down/Bottom Up.  I find some people are top down thinkers and other are bottom up thinkers. It takes both kinds. Let them be who they are. Especially while they create.  Rather obviously, top down thinkers will tend to write epics that need to be broken down (even at this point we can often see some epics are just too big).  And bottom up guys will write stories that sometimes are too small.  And we sooner or later need to combine stories.

User Story format. I like it and encourage it. They especially tend to forget the "so that" clause. So I encourage them to include it. But, if they just can't think of the feature in a user story format, I say: ok, just write something as a PBI (product backlog item). Maybe later we will convert that into user story format.  Be easy on the beginners. They are just learning to ride the bike.

Results.  Usually the team ends up with 40-60 stories that represent 5-7 months worth of work. Ballpark.  (It is just a gut feel at this point.)  Which is a great start for the Release Planning.

These user stories (or PBIs) are just the right middle level of 'features' for everyone to have a clear enough picture of what the product will be. It embodies the vision. It makes things concrete for people, without getting mired in details. Wonderful.  And they can do this the first time.

Is it perfect? No. Could it ever be perfect? No. Is it a reasonable time to spend to get a level of 'quality' (in all aspects) that it very useful?  Yes!

Can we write more stories, if we discover them, later in Release Planning? Yes! And it always happens! And will we add more stories as we are doing the Sprint? Yes, always.

Public Impediment List - Again

I wrote the following post to a Scrum group. Perhaps you will find it interesting. It is lightly edited. And it is in response to another person's post.

***
Let's talk about the impediment list more.

Along the way I will mention some of the problems I see in real life.

I find that most ScrumMasters don't have a list. Even in their head. And it leads to a low level of activity (bordering on none, much too often) in removing impediments.  One example of what they typically should have: We need better engineering practices (add XP things, one at a time).

I agree of course that not every impediment can be put on the list.

In Scrum we are working both with and against human nature. Yes, I agree it is human nature to want to hide. And yes we need transparency to be better.  So, the solution is some common sense. More transparency, but we have to be reasonable.

So, a public impediment list, but we don't show the one that goes 'George picks his nose in the team room' or whatever example you want to use.

Yes, managers don't want to see a list of 'bitches and moans'.  They don't want people saying 'your kids are ugly', ...meaning: If I as a manager put in place Process X, I don't like it when some team calls it an impediment.  Again, some common sense....  But in general, more public, please. The more mature the firm, the more public.

Next problem I see: (expressed in this metaphor)  There is a table with rolling wheels under it. And beside the table a movable wall, also on wheels.  You and I would say they are both impediments. I see far too many teams not even identifying them as impediments (the table and wall in my metaphor). When shown them, they say: Well, it would be impossible to (re)move them. We point out the wheels. They say: Well, still impossible. Only when we actually move them ourselves, does something happen.  Weird, but oh so true.

More broadly: They (the whole team) are not creative enough in identifying impediments. By making the list public, we can start to get more creativity.  Or at least see weaknesses in the list.  This is not anyone's fault.  It is just human nature. The pains you are used to no longer feel painful.  But we after overcome human nature (or parts of it).

Pareto: As with any work, there are a few items with the real juice, and lots and lots of relatively minor things. We must Pareto-ize the list. Prioritize it; order it.  Just like the Product Backlog.  But we need a good list first.

Ordered. Yes. There are dependencies in implementing better engineering practices. For example. These need to be shown in the ordering.

Social Contract: the Impediment List is like a social contract.  I will say, at this moment, between the firm and the team. The firm agrees to fix, within some reasonable constraints, the top item on the list.  And then the next top item.  And so on.  (The firm is investing in the SM to drive this.)  The team agrees to stop bitching and moaning about all the other stuff, and get some work done.  It's a much more functional deal than we had before.

Listened. We need the list public so each member of the team knows they were listened to.  Only if they see 'their baby' on the list, do they know it even got on the list.

Discuss and clarify value.  We need the list public so that each person can see where 'their baby' was ordered. And can bitch and moan some more if a stupid SM does not understand HOW important their thing is.  (Sometimes the SM needs a bit of educating.  Who knew SMs did not know everything!?!?)  I won't add how it affects the motivation of the whole team to see the ordering of the whole list...you can figure that out.

If there is a list, and the SM owns it, is he likely to focus more or less on that top item if the list is public?  I am thinking that visual management principles suggest that the distracted SM is likely to have a tad, just a tad, more focus if the list is public. (Ok, sorry if the sarcasm was a bit too thick. It helps, one hopes, fight through our rationalizations, and we all do that. So the sarcasm is directed at me as much as anyone else.)

Those are my main arguments for a (mostly) public impediment list.

Of course, if by magic always the top impediment is being removed and everyone is otherwise completely happy, then I am a practical guy. If life could not get more wonderful, screw the impediment list. In fact, let's forget about scrum.  

But as you suggested, I don't think human nature in the wild has evolved that far.

Now, as a tease, I will say that I am shocked, shocked that you don't want to be completely transparent.  Does that mean that we should remove the transparency idea from Scrum?

One final comment: I say, agreeing with you I think, that the impediment list never ends.  Since nothing we do is ever perfect, everything everywhere always needs to be fixed (improved). So there is an endless job for the SM. In fact, most Super Bowl winners can't even repeat the next year. So, yes, it is a hard job, daunting, and it takes courage. But that is just the truth. I could lie to you, and say life's a beach and growing old is completely easy.  Would that help?  Sufficient unto the day is the top impediment thereof. Just work on that one.  That is not so daunting.

So, after maybe 20 items on the list, I am not sure we need a longer working list. Then order the 20 or so items. As some are fixed, add more items to the list.

Now, to me an implication your 'daunting' concern is that we need some way to measure progress on the impediments. And I completely agree. Most mere mortals need some encouragement. And at least looking back, sometimes, at all the impediments thrown out of the path is satisfying and reassuring.  There could be other ways too....but we need to start with a (mostly) public impediment list.

I await your comments (and others' too).

Thanks,
Joe

Referral Program

We have introduced a referral program.

The idea is simple. We want to provide a token of thanks to those who refer a person to one of our classes.

The token is a $20 Amazon gift card (we can substitute other gift cards of the same amount). So, it is not a huge referral bonus, but a token.  Of our appreciation.

A few rules:
* One per course (ie, only one gift card per course, whether you refer 1 person or more). If you refer a second person to a second course, then a second referral gift card.

* The referee must identify the referrer.  Mostly likely in the check-out process, but this is not required.

* We need a simple way to send or deliver the gift card. Assume US Mail.  Assume we need a delivery address.  No overnight or expensive delivery.  Something close to $0.44 for the stamp.

* We reserve the right to change the rules at any time.

Help them fulfill their dream

Siraj Sirajuddin visited and spoke with Agile-Carolinas yesterday evening. And said many useful things.

One thing he said that was particularly helpful was a variation on the classic one: people don't resist change, they resist being changed.

Well, closer to what Siraj said was this: The organization has a dream of where it wants to be in 1 or 2 or 3 years.  The imagined future state.  And if, as a change agent, you take the time to respect and understand their dream, then they will feel respected. And feeling respected, they are much more likely to let you (the change agent) influence them.  If you ask, they will say 'yes, we would like to hear about your tools that will help us realize our dream.'

What cocktail parties teach us

This is the title of an article today in the Wall Street Journal.  The subhead is:

Brain Is Wired to Focus on Just One Thing; Which Tasks Are Easier to Combine

 It;s all about how we humans are built to focus. Multi-tasking is, well, inhuman.  A few monkeys pretend, but we lose all effectiveness.

 See this.  I am a "member" so it may not work for you.  I can email it to you, if you want. (But 'you' can't be too many people.)

Scrum tries hard to help the team focus. And not be interrupted.

I usually like cocktail parties anyway.  Now more.

Refresher Attendees: new program

As most of you should know, I am a Certified Scrum Trainer.

I have decided to allow prior attendees of my courses to attend the same course again, for a much reduced fee.

I expect the main usage of this is for people to attend again when some of their associates attend the first time.  But it is also true that research shows that attendees typically remember only about 20% of the content of a course.  I know that attendees only take in a small portion of what I really mean.  And, perhaps I am biased, but I think information about doing Scrum professionally is very valuable.

We have to have a few rules.

1. You have to have attended the same course / workshop with the same instructor.

So, if you attended a CSM course, then you can "refresh" at any CSM course (given by the same instructor).  If you took the Workshop as well, you can "refresh" the Workshop also.

The course does not need to be at the same location (same city). This is not restricted to the CSM course/workshop.

2. We must have space for the next refresher person in the class/workshop.

In this regard, there will be two criteria.  No more than 1 "refresher" for every 3 regular attendees. And, refreshers cannot be the main cause of bumping up to a more expensive room.

3. The current fee is $200 per day.  If you have a normal paying colleague also attending the same course, then your fee would be $150 as a refresher.

This fee may change. This mostly covers our food & beverage and hotel costs. And the processing/admin costs.

The rules are subject to change, as we see and learn how this works in practice.

***

We are interested in your comments.

Release Planning: Vision

This is the first of several posts on my suggestions for the details of doing better Release Planning.

See here for a list of posts about Release Planning.

The first step is Vision.  We define the vision, and make sure that all the right people see the same vision and "agree with it." Or at least start to align with it.

Who: The full team of pigs and the business stakeholders should do this together.  The Pigs include: the implementors, the ScrumMaster, and the Product Owner.

The business stakeholders (BSH) are the other key people associated with the team that provide key input about what the product should be. They may be customers or internal managers, or really anyone who will participate enough to provide valuable input.  It is mainly the Product Owner's job to make sure these are the best possible people, given the specific situation. Often the Product Owner must seek help in selecting the BSH.

In my experience, the BSH are never perfect representatives of 'the customers' of the product. But sometimes the level of imperfection is quite impressive. Sometimes, once the issue is identified and made visible, it can be corrected.

Typically the BSH represent two main groups: (a) 'the customers', meaning usually mostly the external and/or internal end-users, and (b) the firm, usually personified as the widows and orphans who own all the shares of the firm.

What: By vision we mean some relatively short statement of what the product will be, once completed.  What it will be, why we or the customers will be excited about it. And a few more scoping details.

It establishes the 'north star' of our direction.  It hints at what business value is.

And it is like an elevator statement.  Something short that you could explain in 2 minutes to your bosses' boss.

We particularly like this format, which comes from Geoffrey Moore's book, Crossing the Chasm:
    •    For (target customer)
    •    Who (statement of the need or opportunity)
    •    The (product name) is a (product category)
    •    That (key benefit, compelling reason to buy)
    •    Unlike (primary competitive alternative)
    •    Our product (statement of primary differentiation) 

In addition to these nice words, we also strongly recommend you find one or two key numbers to ground the vision. Examples: "We expect to make $3 million in the first year."  "Widget production will go up about 125%." Whatever metric (or two) makes sense.  The metric makes the words more tangible.

Why:
- To clarify where we are going. Yogi Berra: "You have to be very careful if you don't know where you're going, because you might not get there."
- To motivate all parties.  This is quite important.
- To set a direction and a rough scope. ("This is about the iPad-1, not the iPhone, nor any other iOS gadgets.")
- To start to get everyone on one page.  My experience is that this is very hard. They tend to want to be on different pages, it seems.

How: We find this typically takes about 1 hour. Sometimes less, sometimes more.  We find it is useful to do 15 minute timeboxes, to check if there is too much aimless or circular talk. To check for those talking too much, and those talking too little.

We recommend that the 'smart guys' (those who think they already know the vision) talk, and the dumb people (typically, the implementers) write the vision.  This helps assure that the implementers 'get it'. Sometimes, sooner or later, the Product Owner, who perhaps is better with words than some of the implementers, must improve the wording.

Remember that perhaps the most important goal is not to have knowledge (in one person's head) but to spread the knowledge into the heads of all the right people. 

Ending:  Usually the team forgets to identify a key metric. Go back and do that. Then, ask the whole team to get the thumb metric.  Tell them: "If the thumb is pointing straight down, this is the worst project you have ever been on.  If the thumb is pointing straight up, this is the best project ever.  Half-way, this is just an average, typical project around here. So, one-two-three, show your thumb metric..."

Then the Product Owner should lead a discussion of the results. Sometimes this means improving the Vision statement. Or the metric. Sometimes it is just a short discussion.

Roles: The Product Owner is leading the content. The ScrumMaster is leading the facilitation.  The SM checks the time boxes, and tries to assure that everyone talks the right amount.  The Product Owner is always assessing: have we said the right things so that the group is motivated?

Later: The war is not won or lost in the first hour of battle. The Vision is a start. Hopefully a good start. But some projects can start with a great vision and then get bogged down nonetheless. Some projects start with a clearer vision, some with a less clear one.

The Vision is typically improved later on, in any case.

***

Your comments please...

Minimum Definition of 'Agile' - 1

First, let's assume that we believe that our firm needs a good agile transformation to achieve important business goals.  Perhaps these are: (a) faster time to market, (b) more creativity in the product, and (c) greater productivity.  (In any case, not 'Agile' for agile's sake.)

One method to achieve more success from the agile transformation is to define the basics of agile for an agile team.  Not every detail, but the basics.

Probably on one page. In any case, fairly short.

And we have found it useful to ask each team: Are you really agile by this definition?  If not, we discuss it with them.  Occasionally they can make a good case for an exception. More likely, they don't understand agile well enough. Yet. And so we learn.

Now, if you think this is a good idea, where do you start?

Well, the Scrum-Butt Test is a place to start.  Here are its eight ideas:

• Sprints must be timeboxed to 4 weeks or less
• Features are tested and working by the end the Sprint
• The Sprint starts with an Agile spec
• You know who the product owner is
• •There is a product backlog prioritized by business value
• •The product backlog has estimates created by the team
• •The team generates burndown charts and knows their velocity
• •There are no project managers (or anyone else) disrupting the work of the team 

Does this cover all the important things?

Well, I think it is a great start. And in some circumstances very useful. But if you want to define agile for your teams, I think you should define more.  More, but not 5 pages of more.

Enough for today.
Comments?

Why add a Workshop Day to the CSM course?

Apparently I am one of the few Scrum Alliance CSTs (Certified Scrum Trainers) who always adds a Workshop day (or 2) to the CSM (Certified ScrumMaster) course.

Why do I add the workshop day?

The simple reason is because the attendees demand it.

Well, honestly, before they have taken the course the attendees don't know to ask for it or not. And often, after they have taken the course and the workshop, they can't compare with or without the workshop day.

But, for example, I had a manager at a major corporation near NYC send his whole team to our NYC CSM+Workshop course this week. His reasons:
(a) he knew me from having taken a course with me last November (with a workshop), and
(b) I was the only CST he could find who had the workshop day.

Next, I want to give credit to a friend and colleague, Catherine Louis (also a CST), who made me add the Workshop. (I was originally skeptical.) So, it was her idea originally. Now, based on experience I am a strong advocate.

Note: I still let attendees sign up only for the 2-day course. That is all that is required by Scrum Alliance to get a CSM.

Why do I consider the Workshop 'necessary'?  Or maybe better: why do attendees find it so valuable?

I get a few answers that are, to me, fairly similar:

1. It makes the ideas real.

In the class we talk and do exercises, but the exercises are never about the 'real work' that the team will do (or return to) on Monday.   Maybe similar to real work, but not their own real project or product. In the workshop, we use a real project, ideally the real project for the whole workshop team. Then the team starts doing Scrum (or at least release planning in a Scrum context) with their real work.

And the real questions come up. And get resolved. Or at least they see that their worries are not as great as they had imagined.

2. The ideas stick.

And attendee yesterday said, well, we need the first two days [the course days] because that gives us the ideas. But then we put the ideas into action on the third day.

And by putting the ideas into action, the ideas stick better. And, having put them into action, even if limited action, you know that when you go back to the real world, you can do this new agile stuff.

It is reactions like these (the two points above are based on attendee reactions) that lead us to always strongly recommend the workshop.

Here is another discussion and another customer reaction about the workshop day.

Kanban Question

A colleague asks: we are an out-sourcing firm and have a client who does not have a Product Backlog. In fact, they often can't prepare enough items (stories) for even a full Sprint Backlog. (2 week Sprints).  He is not used to Scrum or any other Agile approach. I am thinking of using Kanban with him.  What do you think?

For some readers I guess we should define Kanban.

Kanban

Kanban is the Japanese word for signboard or card.  The Lean guys in Japan stole the idea from Piggly-Wiggly in the US (a grocery store).

The idea is to use the cards to establish a pull system, to generate flow and to minimize WIP (work in process). It is very helpful if each card represents a small amount of work, and roughly an equal amount of work. We establish 3-7 'slots' for each of 3-7 process steps. This establishes the capacity of the 'system', meaning in our case, a team.

Another key idea is to use visual management (seeing the cards on a board) to manage the flow.  If flow stops, the issue is supposed to be addressed immediately.

This is a hugely over-simplified view of Kanban, especially as practiced by Toyota.  Indeed, Toyota does many other things besides using the Kanban cards to enable pull and flow, and to minimize WIP. When we hear something that sounds like a team is using 'only Kanban', we are worried, because that seems to us likely to not be enough.  Of course, almost always, they are doing other things as well, but often not calling them anything. 

Summary of recommendations

Scrum comes with a basic Kanban approach 'out of the box' with the scrum board (with backlog, in process, and done columns).  Once the team gets the basics of scrum down, we strongly recommend enhancing this board to make it a strong Kanban board.

In almost all real situations that we encounter, we want to maintain the basic strengths of scrum even while using Kanban on the board.  These include release planning, sprint planning meeting, daily scrum, sprint review (demo), and retrospective. Very rarely we see weird situations where this just won't work, but again that is very rare.

If the product owner is not 'good enough' or the connection to the business side is weak, we recommend addressing those impediments directly.  We do not recommend hiding those impediments by doing only Kanban.

Discussion

Some assumptions...

1. The team is a regular size of about 7.

2. The client has a product of a reasonable size.

3. The product is important, although not always as important to the CEO (of the client, in this case) as we team members might like.

4. An MMFS (Minimum Marketable Feature Set) for this product typically takes at least four weeks of work (or more) by the team. (This means to me, more than 1 sprint.)

I find that situations that don't fit within these assumptions are rare. But they do of course exist.  My recommendations above and my comments below are based on these assumptions.

First issue: a weak product owner or a poor connection with the business is very common!

I am sorry, but this true.  And scrum makes this issue visible, eg, in the demos.

These problems happen because Technology got divorced from 'the business'.  It happened because mutual disrespect has built up over the years.  It happens because no one has ever been asked to be a product owner before. And your firm typically does not have a seriously experienced and successful product owner to train or mentor the freshly minted product owners.

Solve this problem!  And it starts by making the pain visible.  (Further discussion of this issue in a later blog post.)

Second issue: which is better to implement first, Scrum or Kanban?

This is maybe the toughest question, with not always an easy answer.  My main answer is clear: Scrum.  Because it sets so many basic disciplines in play.  

This often requires a persuasive advocate for Scrum.  Scrum can appear hard (change always feels hard), Scrum is typically blamed for revealing real problems, etc.   And often the local advocate does not fully appreciate all the reasons that Scrum works.

Now, let's assume you have a good advocate and you have made a persuasive case for Scrum.  Maybe even gotten them to try it for 4 Sprints.  But they aren't buying it.  This can happen in real life.  Not saying that it should, but people are not always reasonable.

In that case, it is reasonable to say, ok, let's try Kanban.  And then later, as you identify issues that make some part of Scrum useful, you implement that part.

This is not to say that professional Kanban is easy to implement.  But maybe in some cases easier.

Third issue:  Retrospective.

Yogi Berra said: in theory there is no difference between theory and practice, but in practice there is.

In theory, we humans in a team should not need a Retrospective meeting, but in practice we do.  And we need one about every Sprint length.  (I like 2 week sprints, but I am not too bothered whatever length you want to say.)

So, if you implement only Kanban, then also implement a Retrospective every 2 weeks.

And the key here is to identify the top impediment and take action.  Action in the form of identifying a specific plan to fix it. Or in identifying a business case to fix it, that a manager will approve (once you make the presentation of the case).

***

This is already a long blog post.  Let me leave it here (although there is much more to say).  Tell me your questions, and I will likely write and explain more.