3 Methods to increase Business Value

Business Value IncreaseYesterday I enjoyed talking to Southern Fried Agile, the local one-day agile conference.  My topic was this: Three steps toward greater business value.

I was also pleased to see that many participants said they wanted to talk about this subject. So much so that the organizers decided to run the session twice. I am happy that this is considered an important subject. Certainly I think it is.

Some things we already do in Scrum to increase Business Value (or should do):

  1. Better partnership between Business and Technology
  2. Improve the Product Owner (and give him or her this job)
  3. Use a prioritized Product Backlog
  4. Order the Product Backlog to maximize the release of Business Value (over your chosen time frame)
  5. Build working product each sprint (if we get cut short, at least we can field what we have so far)
  6. Demo working product and get feedback from business stakeholders each sprint. Ex: “Did we build for you the most value stuff this sprint?”
  7. Release more frequently

Could we be doing each of those better?  (Ok, sorry for the rhetorical question.)

In the presentation, I suggested three “big” additional things we could do.

A. Business Value Engineering…

This is a framework for continuously getting better at delivering business value. By mapping the process, by articulating the underlying assumptions, by taking a fact-based approach to proving which improvements would be better.

B. Priority Poker

This is an easy thing to add to Release Planning or to Release Plan Refactoring. Or relatively easy. You enable the “5″ best people on business value (in your specific domain) to learn from each other more about business value. By voting “business value points” on each user story.  And the rest of the group learns too.

C. The Pareto Idea

This is classic, and in some sense, almost everyone does it already.  Except they don’t do it enough. And they don’t take it as a basic, everyday, mindset.  So, we fight every day to separate more the gold-platinum-diamonds from the silver-copper from the dirt.

This is a lot of hard work, every day, that we do while we break down the stories into small sprint-sized ones. (I like about 8 stories in a 2 week sprint.)

***

There is much more to all 3 of these ideas.  To be discussed later.  But they attendees seemed to like the ideas. But the real question is whether they got enough to start taking action (if only to learn more).  We shall see, I hope.

Agile Release Planning is not about the Plan

The past week and a half, I have enjoyed working in France.  I have worked with 3 different companies, and a bunch of great people.

In the third class, we did a 2-day workshop.  The Workshop was mainly about agile release planning. With the real work of that company and those teams.

As with most people, some of the people were waiting. They wanted to wait to do the plan.  They wanted to wait until everything was known.  Until at least much more was known. And, as they know, the Plan would be better if they knew more.

This is a very normal human reaction. (And this group was not unusual in this way.)

But this is not the way of life.

Life changes, we learn.

We must always be changing the plan.  So, we do not do Agile Release Planning to have one Plan.  We start Agile Release Planning now, while we are relatively dumb, so that we can learn, so that we can discover what the plan will become.

And we want to discover that with the crazy human beings that we are working with (the Team) and working for (meaning: the customers).

I say ‘crazy’ in a most affectionate way.

Crazy in a nice way, crazy in an inexplicable way, crazy in an emotional way.  Crazy in far more ways than we have understood yet.  Because what it means to be human, to be a customer, a teammate, a friend, another stranger on the road…what it means to be this we still do not know.  The customers and the teammates are, for so many reasons, both good and bad, changing all the time.

So… we do some planning, relative quickly, and we ask our co-workers to work with us, and help us figure out what we are doing, and how we shall do it.

Lesson 1: We plan now, even with very imperfect information. And then we evaluate, and think about what we need to make a better plan.  And we do some of the work, and then we learn more, and re-plan.

Let me also add this.  Sometimes it can be true that, before taking a path, some things must be known. Or at least…if we choose one path wrongly, it may be hard to change paths later. So, we want to know more.  If you are convinced you have this type of situation, you have a much higher need for more information early.  So, use common sense.

But we caution you. At least with a software product, and with many other products, from experience we guess that you are again using one of the standard rationalizations for procrastination. “I need to know more first.”  Analysis paralysis, as it is often called.  Almost surely, yes, review what you know now, but then learn from taking action.  The school of hard knocks is a wonderful teacher.

Comments?

The PO – The Team Daily Scrum

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever ‘scrum bible’ you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for ‘pretty good’ Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation — maybe about what to add to Scrum — not a religious war.

OK.  My views expressed too quickly:

  1. The PO is very important to success.
  2. Understanding business value and understanding detailed ‘requirements’ is very important to success. Both these ‘activities’ are extremely difficult.  Both for the PO and for the Team.
  3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
  4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
  5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
  6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs….not the most important aspect of self-org though.)
  7. I do not think it is useful to talk about a team within the team. (I hardly ever say ‘Dev Team’.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
  8. The PO must spend a lot of time with ‘people outside the team’.  I will call them, at times, customers. managers, business stakeholders, etc etc.
  9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
  10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say ‘I got the answer’) in the Daily Scrum.
  11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): “who is that guy; he is not part of the real team”.

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: “Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be.”  Meaning for example: If the PO comes to the Daily Scrum (usually), then over time it will make them at least a bit better.

Certainly some of you have done different things and been fairly successful. For example, with the PO not coming to the Daily Scrum.  But could you have been more successful by having him come?  Or might ‘my’ teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams to do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most ‘good’ (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than ‘the bare Scrum framework’.  The minimum that they want.

Release Planning: Completing the Plan

As discussed in the previous post on Release Planning, the user stories are now ordered.

(Please see this post for a list of all the posts on Release Planning.)

Now we must complete the Release Plan.

So, we must make the trade-off between scope and date.

There are three ways to do this:

1. Fixed Release Date.  We will release every X months or Y sprints.

Some teams or firms prefer to have a fixed release date. It makes things simple.  It makes managers and others realize that we will release.  They only question is exactly what will be in the release.

2. Fixed scope.  We will release when all of the scope (all the stories or PBIs in that scope) is/are done.

3. Trade-off.  We understand our velocity and go down the Product Backlog a ways. And ask: two sprints, umm, how many features are done?  Ok, three sprints, how many features are done.  Ok, four sprints, umm, customers would really like to see another release, the market needs it, but do we have enough?  Ok, five sprints, umm, I think we have enough.  Let’s shoot for that.  — It is that kind of trade-off.

This requires that we know our velocity.

Estimating Velocity

With an existing team, you might already know their velocity. With a new team, you must guess.

So, we do a calculation to get an educated guess.

First, for the 1 story point reference story (for effort)… how many ideal person days would it take. The Team huddles around the story and reaches a decision.  Imagine the number is 1 SP = 1.5 ideal days.

Imagine the Team has 6 doers (of real work).

Imagine the Team will do 2 week Sprints.

Let’s assume the focus factor is 60%. That means, out of an 8 hour day, roughly 60% of the minutes are usable for the project.  The other minutes are used talking about the game, taking breaks, eating lunch, getting interrupted, answering questions, reading the email, going to company meetings, etc, etc.  Maybe some work, but not work on this project.

Calculation:

2 weeks = 10 days.

6 x 10 = 60

60 x 60% = 36

36 x (1-40%) = 21.6

21.6 / 1.5 = 14.4 Story Points for the 1st Sprint.

—-

We subtract the 40% has a start-up “cost” for the 1st Sprint.  The Team is learning Scrum, the Team is “forming, storming, norming, performing..”, the Team always wants to over-estimate what they can do in a timebox.
For the 2nd Sprint, we subtract 20%.  For the 3rd Sprint, we subtract maybe nothing.

You may find that these rule of thumb numbers need to be adjusted for special situations.  But they seem to work for most start-up teams.

36 x (1 – 20%) = 28.8

28.8 / 1.5 = 19.2 story points for 2nd sprint

36 * (1) = 36

36 / 1.5 = 24 story points for 3rd sprint

And so on…

Communications Plan

I tend to put pressure on new Product Owners to release earlier.  They are mentally too tied to the concept of the 100% – 100% rule.  That nothing can be released until everything is done.  This is almost always just wrong.  Hence, I always ask for an earlier release.

Once the PO and Team agree on the scope and date, we then have to talk about the “communications plan”, as I call it.

If the Team works with a manager who truly understands adaptive planning (meaning that the current plan will be revised and improved every sprint… this is only the first guess at the plan)… then tell that manager the truth.  Here’s what we guess, this is what we are worried about.  This is our feeling about how it is likely to change.  And maybe we have contradictory feelings.

But often some key managers do NOT understand adaptive planning. These “tough” managers (or customers) want you to give a fixed date, and then deliver to that date.

Then you are stuck. So, we have to do what we used to do in waterfall. Add some “buffers” (aka padding, etc, etc) to the date.  For “problems”, for new stories to be identified later, etc, etc.

It is hard to guess how much buffer to add.  We have no additional magic.

But, we do strongly suggest that you protect yourself and your Team. Do not get them in a situation of a Death March, trying to meet an impossible date.  More about this later….

And then we talk about, “ok, how will we communicate the date?”  (Almost always, the key issue is the date.) You have to start setting expectations that the date will change if other things change (substantially), and they are likely to change substantially.  This is not one conversation by the PO, but a series of conversations by and with many people.  It is over time that the start to see and feel the power of adaptive planning.

For some of you, the issue is not so much “communications plan”, but “what do we put in the contract”.  Too big a subject for this post.

Finalizing the Plan

Assuming you have “business stakeholders” as I described them earlier, then always you have to review the release plan you have with them.  Get their buy-in or comments or adjustments.  This of course may affect the communications plan.

So, this is most of the basics.  A bunch of issues we have not addressed.  Some I will address in the next post.

Self-organization

We have this idea in Agile, that the Team should self-organize.  This is an important idea. And also an important occurrence (eg, the reality precedes the idea).

In Agile, self-organization is compared to command-and-control.

We think self-org is an important thing to study, both in general and in your Team.

Why

Well, one, because it is just right.  People are free, and self-organization is saying that the Team is allowed to be free.

I guess this needs to be explained a bit.  Some will say: well, the company has bought their time as employees, so the company gets to define what the Team does.  Well, let is concede this at a high level; let us say that the company may define the vision or the goal or the general product.  Perhaps even the user stories.  The Team members are not slaves, but we can assume that, as employees, they agree to do the company’s work for pay.  A contract.

But, devising the work, figuring out how they will get to the goal, they should have the freedom to do.

The second main answer is: self-organizing humans tend to do better work than human ‘slaves’ (humans directed by one or a few command-and-control people).

There is lots of evidence of this. The first book I recommend is The Wisdom of Teams by Katzenbach and Smith.  This is a rather old book.  But the basic evidence is that a self-organizing team out-performs, almost always, an individual.  And to such a degree that the extra cost is well worth it.  But, you must given them some degree of ‘freedom’.

There are also a lot of more recent evidence.

Some topic you may wish to research:
Self-organization
Complex Adaptive Systems
Maneuver Warfare
Free Enterprise
Knowledge Creation

Note: Some people say that a free enterprise system is mainly characterized by (mostly) private ownership of capital (means of production). And attribute its successes or failures to that. Others focus on the freedom of individuals to make their own decisions (much like the “wisdom of crowds” idea) and on the view of the national economy as a complex adaptive system, trying to accomplish high-level economic success via many individual agents (people or companies) making their own decisions.  In our view, successful free enterprise countries exhibit many of the successful characteristics related to self-organization.

Command-and-Control Managers

Lots of managers have been taught, explicitly or implicitly, that the ‘workers’ are dumb, and the manager must tell the worker how to work.  In our view, especially for virtually 100% of knowledge workers (our domain), this is very very incorrect teaching.  But it is nonetheless, what they have been taught.

Now, some of them also understand freedom to some degree, and understand that they want the people in their group to ‘think for themselves’. But, we can say with relative assurance, most companies have a lot of people who are relatively command-and-control in their style.

And, in pressure situations (our common situation), they want to use too much command-and-control.

Again, this is not true of all managers, but of many. It depends, in part, on the company’s culture.

It is hard to convince these people to be patient for self-organization.

Teams that won’t self-organize

This is seen in real teams.

There seem to be several root causes. One, the team has been beat down by command-and-control managers so much, that they have ‘forgotten’ how to self-organize.  Another: that they Team does not believe it when managers say ‘self-organize’.  Another: The Team is fearful that by self-organizing they will be ‘held accountable’ with punishment a likely outcome.  To avoid pain, they refuse to self-organize.

Whatever the reason, two things can be said.

Many Team (perhaps with Agile coaches) do eventually break out from being ‘stuck’ (not self-organizing).

And some Teams may take a very long time or perhaps never do it.

The key advice is this: If the Team will not self-organize, or seems to want to self-organize to mediocrity, then a good manager should intervene.  Temporarily.

Perhaps prior key advice: Be patient. Often Teams will self-organize in two or three sprints.  Keep talking about it, and ask them if they need help.

Third advice: In the view of some (including me), some Teams lack some key skills to self-organize. For example, a new junior Team may not know really how to break down work into tasks for the sprint planning meeting. Sometimes ‘holding their hand’ as they mature is a very successful approach.  And 3 or 4 sprint later, they can be very good at self-organizing their own Sprint Backlog.

Learning to decide as a Team

I think each Team learns how to decide.

The first, most useful thing, is that everyone in the Team gets to offer input on a decision.

Next, the Team needs to accept that no decision is ever perfect.  Thus, decisions in general must be made, perhaps not always quickly, but promptly.

The Team needs to understand the impact of decisions on the morale of the Team and on the success of the Team.

In our view, most teams go through a forming and storming period of decision-making.  And then later get better.

Good self-organization… and better

Lots of Teams seems to self-organize well.

What is also common is for most Teams to plateau.

In part, we may say that a root cause is that most Teams want to reach a stasis… a place where things are balanced and where change slows down.

But have they reached the height of improvement?  We think not.  Some Teams have reached much higher heights.  And some Teams keep on improving.

There seem to be two main factors (or sets of factors):
* magic — or, more accurately, a bunch of things that are hard to describe.
* a bunch of factors that people talk about, and some teams study and work on

Some of these last factors seem to be quite ‘soft’.  Love, listening, creativity, heart seem to be among them.

Lastly

If you have never been on a good team, it is hard to understand what self-organizing is all about.

Within the Team, it might be rather rough and ready. But a lot depends on the specific individuals in the Team.

Release Planning: Risks, Dependencies, Learning, MMFS and Other

Now we come to the point of (re)ordering the Product Backlog.

(This is a continuation of a series on Release Planning that starts here.)

You will recall that the Product Owner’s main goal is to maximize the Business Value from the Team.  In some time period (shorter or longer, as makes best business sense in your specific situation).  So, in theory the R factor (see the previous post) should be the way to organize the Product Backlog, ceretis paribus (other things equal).

But of course other things are never exactly equal.

So, here is where the most uncommon thing comes into play.  Common sense.

And we re-order the work based on these factors: Risks, dependencies, learning, MMFS, and other factors.

We recommend that anyone in the Team can propose to move a user story earlier or later based on these factors. But he or she must discuss the change with the Team and get reasonable consensus.  If there is no consensus, then the Product Owner gets the final decision.

So, let’s discuss each factor in turn.

Risks. There are potentially many types of risk. Business risk is often a big one. For example, we need to get a feature out before a competitor.  Or we have a weak understanding of the specific detailed features needed in area X.  Technology risk is another common factor. We are about to use new technology, and we are not sure how it will work.  And there are other types of risk.  In Scrum, we tend to want to attack risk early, by doing one or more stories in that area, to see if the risk is just a worry, or a real roadblock.

Dependencies.  Again, these can be of several types.  In the past, we often organized the work mainly by technical dependencies.  Since the job now is to maximize business value, we sometimes must sacrifice efficiency of the Team.  But if technical dependencies will destroy the efficiency of the Team, then we must deal with that. (Ok, seriously diminish the efficiency…).  And there can be business dependencies as well.  It makes more sense to develop step 1 in a process before step 2.  At least sometimes.

Learning. In Agile we recognize the importance of learning. We need to learn what the customers really want. We need to learn some technical things to become more effective.  These can be good reasons to chnage the order of the work.

MMFS.  Minimum market feature set.  This phrase is from Software By Numbers by Mark Denne and Jane Cleland-Huang.  The idea is that there is some minimal set of features that must be put together before a customer can realize the value of the whole set.  Sometimes this minimum is quite small, quite small indeed.  In other circumstances it is much larger.  In general, too many of us (producers and customers) have been brainwashed into believing the 100%-100% rule, so that we think the MMFS is much larger than it really is.  In any case, low value features sometimes must be moved up, in order to add the ‘missing something’ to make the next release truly ‘usable’.

Other. This is a catch-all for all the other reasons we have to change the order of the user stories.  My favorite example is this: A committee is going to me in 3 weeks to decide on the funding for our project.  George is on the committee.  In our opinion as PO and in the opinion of everyone else, George is much too excited about user story 87, which currently would not be built until the third release, and that is assuming no new user stories get identified, which is very very unlikely.  But, George is on the committee. And user story 87 is only 5 story points (our velocity is 25).  So, we ask the Team to go ahead and get the story done in the next Sprint so that George helps assure that the project gets further funding.  Not rational, not ‘the right thing to do’, but sometimes you have to deal with real people and irrational things have to happen.

In our experience, Risks and Learning should be used more often to re-order the product backlog.  And Dependencies less often.  But in any case, using the R factor solely is almost never the right answer.

How to do this

We recommend that the product backlog already be ordered by the R factor.

We recommend that the whole Team be there (PO, SM and implementers) and the business stakeholders.

Then, anyone in the group can start to suggest re-ordering the product backlog based on any of the ideas above.  Any move has to be explained to the whole group.  If there are disagreements, the PO makes the final decision.

Again, let me emphasize that sharing knowledge with the whole team is at least as important as any other outcome we are trying to achieve.  So, doing this without the Team is not recommended.

Normally this does not take very long. Again, 6 months of work for one team is typically expressed as about 50 user stories.  So, re-ordering 50 user stories, where most do not move, does not take long.

More to come….

Release Planning: Effort (2)

Now we come to the point of describing Planning Poker.

This has been done before, we will be brief.  It is described at greater length many other places.

***
Some basic characteristics:
* We find the 5 best experts on effort for this work.  In all most all cases, this means the team of pigs.
* Usually the Business Stakeholders (as I call them) will not stay around for this work.  This is ok. Not ideal, but ok.  We will bring them back in later.
* We use the planning poker cards with the Fibonacci scale.
* The approach is wide-band delphi.  Delphi means we use the best experts we can find. Wide-band means that we allow the experts to talk and learn from each other.  This bears strong resemblance to the knowledge creation ideas from Takeuchi and Nonaka.

The basic technique

We have 4-7 experts.  These are typically the people who will be building the product. We try hard to get all of them, so that none of them feels left out.

The Product Owner is typically not one of the voters, but he/she is there. The PO has to make sure that the team is understanding each story correctly.  Typically the PO is a business person and in any case is representing the Firm and the Customers.  So, when those kinds of questions come up, he must be there to give them the best possible assumption to work with.

The ScrumMaster (SM) is there to facilitate the meeting or the work.  Ex: To try to get the quiet ones to talk more and the talkative ones to talk less.

In this discussion, we will assume all the PBIs (Product Backlog Items) are in the User Story format, so we will call them stories.

The Experts must now choose the reference story.

Imagine that the team has 50 stories that cover about 6 months worth of work.  The Experts choose from that set the smallest story.  Well, except that it should not be too small. Ideally it is about 1 ideal person day (after adding together all the ideal hours from all the required skill sets).

The reference story is arbitrarily given a 1. Meaning, it has an effort value of 1 Story Point.

Note: For those who are just reading this post, an earlier post talked about how the Team must have a strong DOD (definition of done). The DOD should make clear what things are being done in the Sprint to get the story ‘done, done’ as we often say.  So, it is the effort of these things that we are estimating.  Earlier we talked about a minimal DOD.

OK, now the team estimates the relative size of all the other stories in comparison to this reference story.  This happens in this way:

Select the (next) highest value story.
Discuss it briefly to assure everyone understands it the same way. PO describes story. Experts ask him questions.
Someone asks “any more questions?”  If no….
Each Expert privately selects a Planning Poker card that best represents his feeling of how much bigger the new story is in comparison to the reference story. For example, if 7 times bigger, the choice is between a 5 card or an 8 card.  Likely, the 8 card will be chosen…
If all Experts are within 3 cards of each other (eg, all have either a 5, 8 or 13), then average the numbers. Example: 5, 5, 5, 8, 13 …. averages to 7.
If the Experts’ votes are more dispersed (ex: 3, 5, 8, 13, 20), then the two extremes talk (mostly). In this example, the person with the 3 and the person with the 20 both talk about their assumptions, etc.  If the assumptions are business-related, then the PO can decide which assumption is correct.
With the new information, each Expert votes privately again.
Voting and discussing can go on a couple of rounds.  Almost always, the final answer for a card is the average after the Experts get within 3 consecutive cards of each other (Ex: votes are 2, 3, or 5).
Once the number is decided, it is written on the card (story) in such a way that everyone knows that it represents the story points (color and placement on the card usually make that clear).

A few additional comments:
The discussion is actually the most valuable thing.  The numbers drive a better conversation about the more important stuf
Sometimes important assumptions are identified. In that case, the assumption should probably be recorded (eg, on the back of the card?). Later, if we discover that the assumption is incorrect, we can refactor the story points for the related stories.
Sometimes the Experts will want to address certain general issues.  Issues might be architecture or design related. This is where the SM has to use good judgment. Typically let them discuss for ‘a while’ but not too long. Maybe make one or two drawings.  Make and document a few assumptions, and then get back to Planning Poker.  Sometimes one or two people on the team want to discuss these issues too long. In this case, the SM must use good judgement and get the Experts back to planning poker.
You will  hear of people suggesting that the Experts must agree on 1 Fibonacci number (eg, 8) for a given story.  This is _not_ recommended.  First, it gives a strong incentive for people to too quickly start to shade their numbers, rather than vote what they really think.  They find that George, the senior guy, is stubborn, and to avoid conflict and to keep things going, they decide, almost subconsciously, to start voting a closely to what George says as fast as they can.  The research shows that the average is more likely to be the correct estimate. And it actually takes less time to reach that number (if everyone is voting honestly).
Usually one or two new stories are identified while we are doing planning poker. This is normal. Occasionally it turns out to be the most important story.

At the end

It usually takes about 1.5 hours to estimate 50 cards well.

Once all the cards have been estimates (for effort), all the cards should be put on the wall. And then the whole Team should gather around. And see if they can identify one or two ‘stupid’ cards.

It is very common that 2 or 3 stories that were estimated early on will need to be re-estimated, in the team’s opinion.  This is fine, good even.  And normal.  They know, as a team, are much smarter than when they started planning poker.

Cost-benefit analysis

Now one or two people in the team calculate the R ratio for each story.  BVP divided by SP.  For each story.  The R should not be more than one decimal place.  This gives:
the low hanging fruit
the bang for the buck
the return on investment
..however you want to put it.

We next suggest that the PO organize the story cards based on the R number. Highest R first.  Lowest R last.

We ask them: What do you think?  Is this the right way to do the work?  Often they say: Well, it is a good start but we need to make some changes.  Which is 99% of the time, the right answer in my opinion.

What ideas do we use to re-order the work?  More on that in a post soon.

Release Planning: Vision

This is the first of several posts on my suggestions for the details of doing better 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…

***
Prior posts on Release Planning:

http://agileconsortium.blogspot.com/2011/03/scrum-and-release-planning.html

http://agileconsortium.blogspot.com/2011/08/joes-approach-to-release-planning.html

http://agileconsortium.blogspot.com/2011/07/why-release-planning.html

http://agileconsortium.blogspot.com/2010/11/release-planning.html

http://agileconsortium.blogspot.com/2010/09/release-planning-early-warning-system.html

http://agileconsortium.blogspot.com/2011/08/release-planning-with-business.html

http://agileconsortium.blogspot.com/2011/09/release-planning-business-value-points.html

http://agileconsortium.blogspot.com/2011/06/planning-poker-1.html

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.

Agile & Religion – 1

I heard recently someone comment: “Well, watch out for those guys who get too religious about Agile. We don’t want that around here.”

This general topic gets talked about in the Agile community a lot. And, I think, often ineffectively.

But I think it is a difficult topic. It is hard to explain the issues around this well.

So, I will try to do several posts with specific examples and situations.

The first thing to say is that lean-agile-scrum is mainly about results. Results for the individual, the team, and the customers. Results such as: better products, higher quality, more fun, better work.

It is not about doing Scrum just for the sake of doing it. As though purity of Scrum, alone, were a high value.

It is important to say that virtually all the people who are experienced with lean-agile-scrum are concerned that they see too many people doing it “weakly”. Schwaber talks about ‘flaccid Scrum’. The XP guys talk about how Scrummers don’t have strong engineering practices. Others talk about ScrumBut (or ScrumButt). And there are other phrases.

What is important is that they have a sense that playing Scrum ‘weakly’ means that the people are getting FAR less of the value than they deserve.

In summary for now: lean-agile-scrum is not about religion or belief or faith. It is about reality and testing and real results. That seems to me to be pretty far from ‘religion’ as most people use that word (when they use it as a put-down).

The next thing to say is: when a Scrum advocate talks about doing Scrum better, we should talk more about WHY ‘better Scrum’ means a better life or better results. More on this in the next post.