Release Planning: Vision

Posted on April 22, 2012 by Joe Little

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

A list summarising Scrum

Posted on April 17, 2012 by Joe Little

The list below is not self-explanatory, but it covers the key ideas one has to know and execute on to do Scrum professionally. Of course, becoming proficient at doing them at the highest level (at the rugby World Cup level) is a lifetime’s work. Rugby is a simple game with simple rules, but to reach the highest level of play is very difficult.

This list could be used as a starting point to defining ‘agile’ or ‘scrum’ in your firm. I am suggesting such a definition could drive useful conversations. And it fits on one page (a key criterion).

A list summarizing what is Scrum:

Roles:
Product Owner
ScrumMaster
Implementer (‘Dev Team’ role)

Events:
Sprint – 4 weeks or less.
Sprint Planning Meeting
Daily Scrum
Sprint Review (Demo)
Sprint Retrospective

Artifacts:
Product Backlog
Product Backlog Items
Sprint Backlog
Working Product
Increment (of working product)
[Sprint Burndown chart]
[Release Burndown chart]
Definition of Done
[Public Impediment List]

Key Ideas:
Scrum is a process framework
Deliver business value faster
The Product Owner is maximizing the value delivered by the Team
Empirical Process: Inspect & Adapt
Transparency
Self-organizing
7 plus/minus 2
Build iteratively and incrementally
Working product at the end of each Sprint
Potentially shippable product increment
Need for feedback
Always learning
Always adapting to good and bad change
Usefulness of high quality
Scrum hates technical debt.
Knowing work remaining in a Sprint (daily)
Knowing work remaining in a Release (every Sprint)
Protecting the implementers from disruptions
Protecting the implementers from the Death March
The ScrumMaster drives the removal of impediments
Must add other practices (e.g., engineering practices) to Scrum to do work
Scrum does not include agile release planning (but you probably need it)
Do Release Plan Refactoring every Sprint
Scrum is consistent with the Agile Manifesto and Agile Principles
The Team should be having more fun (and be more creative)
Sprint Planning Meeting, parts 1 & 2.
The Product Owner orders the work in the PB; the implementers decide how much they can do in a Sprint.
Sprint Goal
Sprint “commitment”
The 3 Daily Scrum questions
Purpose of the Daily Scrum: enable self-management
Demo working product & get feedback
Servant leadership
Chickens can help

Minimum Definition of ‘Agile’ – 1

Posted on April 15, 2012 by Joe Little

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?

Posted on April 13, 2012 by Joe Little

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.

Who should fix Impediments?

Posted on February 20, 2012 by Joe Little

In the Certified ScrumMasters LinkedIn group, Michael asked: Who should fix impediments, the SM or the Team?

His own answer was: Both. And then he discussed. This topic has drawn a fair number of comments. Here was one of mine.

***

1. Michael is right, that who should fix the impediments and how much the Team should be involved is not a simple question. I think this discussion has brought out the issues.

2. I like what Mike and others said about changing the mind-set of the Team.

3. Clearly, getting the Team involved in impediments is important. To me, the first thing is getting the Team better at identifying the top impediments (imagining that real change can happen), and then better at giving the SM information about how to prioritize them.

4. Clearly the SM should always be working on something, although I do think “observing” is important and hard work. (It can identify some people impediments, for example.) Working to get others to complete the fix of an impediment is also important. And the SM should also actually fix some impediments, where he has a decent ability to do so. (If an SM does not know what CI means, I would not have him work on Continuous Integration. I think.)

5. The list of impediments is endless, in some sense, because never do we have even one thing running perfectly. So, in theory, we could spend all of our time fixing impediments. I think spending about 1/7 of our time on impediments is reasonable. (This is a bigger issue, but relates to this conversation.) There are definitely limits to how much the Team should work on impediments. We want them mostly doing ‘real work’.

6. I have never seen a Team reach optimal productivity. Never. They may get to 5x or 10x, but they still have not max-ed out. I don’t believe Michael Phelps has swum his fastest possible race. In fact, most Teams can’t win the Super Bowl the next year…they can’t even stay at that high level. Never, never, never send out a team without a ‘coach’ (without an SM).

***
Comments?

More on: The Product Owner and the Team

Posted on February 16, 2012 by Joe Little

There has been some interesting discussion on this topic recently.

Two things I wanted to add to my prior post.

1. The business side cannot force the Doers to “do all that I say” in the Sprint.

This is of course a well-known rule of Scrum. But this rule does eject the PO from the Team.

So, in one scenario, the PO cannot force the Team to do all X stories that he or she wants done in the Sprint.

But even before that, the PO should want reliability, meaning, if the Team commits to 8 stories, then at least 8 stories will get done (or done, done — if you prefer) in that Sprint. The PO does some of the ‘real work’ (in the form of providing information about the stories and feedback, mainly), so the PO has a say about what he/she can or cannot do to support the Team that Sprint.

What I usually find in the real world, is that the Doers (eg, the coders and testers) want to over-commit. And the PO (at least) should be saying “no, let’s not over-commit — I and we need to predict for the customer, and we need to know what the Team can really do at sustainable pace”.

But at least the Business side (often in the person of the PO) cannot force the Team to do 8 stories when, in their professional judgment, they can only do 7. As an example.

Exactly how the Team self-organizes to reach that judgment is up to each team, but ejecting the PO is not an option. The PO has at least some lights on the problem, and so should be heard, just as, for example, the junior tester has some lights on the problem.

There are many possible scenarios, but these are the basics.

2. The issue of whether the PO is part of the Team (yes!) is far greater than just the issue of Sprint commitment.

Yes, Scrum teams have problems with the Sprint commitment. All kinds of problems, with multiple root causes. This was partly discussed (indirectly) in a recent post.

But in the shorter term (eg, intra-day) and in the longer-term (eg, release), the PO is an important part of the (full) Team.

Let’s take the Release, and the use of Pareto’s idea of the vital few. So, the whole team must be optimizing the 80-20 rule at every level of work (tasks, stories, epics, etc.). And discovering how to do the least amount of work to deliver quickly the best possible product. (See the Agile Principles.) This is a Team effort, led in large part by the PO. But still a full Team effort. The key related idea is cost-benefit analysis (hey, there’s another new one!)… how to get the most benefit or business value for the least effort. Again, a joint effort by the full Team.

When troubles arise (and troubles in some sense always arise), who is the Team that will address them? ….well, both the Business side and the Technology side together must collaborate to address them. We might too easily say that in general, both sides must compromise. Each side must accept “lack of control” but high “power to influence”, and create some modus vivendi….some way out of the problem together. How do we do this in a practical manner? The simple way of saying it is that the full Team (with the PO) must figure it out.

Again, there are many scenarios, but those seem to us the basics.

***
Yes, I know there is much ‘legacy code’ in our wetware (our brains, etc.). But this I think is the way forward.

Why an Intermediate CSPO (Product Owner) course?

Posted on January 30, 2012 by Joe Little

I am about to do an Intermediate Certified Scrum Product Owner course in Orlando. Feb 21-22. Followed by a Business Value Engineering workshop. Feb 23-24. See http://leanagiletraining.com/courses.html

In this post I wanted to talk about why the Intermediate CSPO is important and how it is different.

First, our finding is that the Team is important. Any focus too much on one role, or one role in isolation, is potentially leading people astray. In a Team, every role plays with every other role. (Yes, we might do some work in isolation, but always for the use or benefit of others. So, the isolation is only temporary, and not very meaningful.)

So, I like all Product Owners to start with the CSM (Certified ScrumMaster) course. And ideally to take this with the rest of the Team.

And then to play Scrum for some time. So, the PO starts to have real questions from the real world.

Second, I think for almost all teams, the biggest impediment is that the PO is not good enough.

This is not because we don’t ask good people to play the PO role. Usually we do. Sometimes excellent people. It is because no one is a trained and experienced (eg, for 5 years) Product Owner. At first. So, very good people appear weak because they lack training and coaching and experience.

So, I find that the best thing is to take POs with a CSM and some experience, or no CSM and a fair amount of experience, and send them to an Intermediate CSPO course.

The course actually covers most of the same topics. But from the point of view of an experienced person.

For example, we review basics. In this course not to explain them the first time, but to check for real world understanding. And to correct the mistakes that beginners in any sport always always always make. The bad habits, we might say. The Scrum-But that they have started to do.

Third, we try to build the aspiring Product Owners into stronger Product Owners. I have just suggested my key point-of-view: That becoming the Tom Brady (the Quarterback of the New England Patriots for those in Rio Linda) of Product Owners is a journey that takes years. So, when we say aspiring, we do not mean that they come to the course with no accomplishments, but rather that whatever they have done, they aspire to be better.

A lot of the basic things we talk about are also discussed by other trainers. And on the website above.

What are some key ideas that we talk about that others (usually) do not?
* minimizing work in progress
* maximizing learning
* ordering the product backlog to optimize BV delivered over some period of time
* focusing on the gold, platinum and diamonds, and ignoring the silver, copper and dirt (Pareto)
* sizzling steak and killing babies (the psychology of an earlier release)
* a brief intro to the BV Engineering framework (approach)
* no Technical Debt (is a PO issue too!) (Well, zero is a very low number, but that’s the direction.)

Committing for the Sprint

Posted on January 23, 2012 by Joe Little

This is, to me, still a New Year. And a friend suggested I talk about New Years’ resolutions. Or something like them, Sprint commitments.

Henry Ford said: Whether you think you can or you can’t, you are usually right.

So, let us work backwards.

To me, in most business situations, the main thing is satisfying the customer. Helping the customers solve their problem(s).

This is very hard because:
* the customer does not understand his or her problem well
* the customer cannot articulate the problem well
* the customer typically does not understand the technology capabilities that might be brought to bear in the solution, and what their strengths and weaknesses might be
* we (technologists) don’t hear very well (we are human, after all)
* we tend to want to build what is cool to us
* our companies tend to be overly involved with existing products (‘to a man with a hammer, everything looks like a nail’)
* and several other reasons…

Still, satisfaction is what we are after. Unless silly lawyers and such get in the way.

Typically what we have to build to assist with gaining satisfaction takes several sprints. (The length of time depends on many factors, but first the general domain and what one might call the maturity of the product line or its current technological complexity.) Most products take more than 1 sprint. Some take 2-4, some take 20-25+. Although most are in-between, I find. At least for the first (next) release.

So, how do we climb the mountain? Well, one step at a time, of course. And because we know it is hard and fraught with many misunderstandings, we try enable more and more feedback.

So, we have Sprints and Sprint demos. Among other things. And by going slowly (eg, by taking the time to optimize negative feedback early) we can go fast (deliver the product the customer really wants sooner).

Within Sprints we have ‘stories’ or Product Backlog Items — small pieces of functionality or features. Now, a customer never really wants the individual pieces (well, ok, many with a few rare exceptions). The customer wants what we like to call the Minimum Marketable Feature Set — that set of features that helps him or her (partly) solve a problem.

So, we do have to focus and enable feedback at a detailed level. But the point is not the detailed level, but rather customer satisfaction with the production release (ie, that’s what the software people call the final product).

***
Is it worthwhile to have a Sprint goal? Yes, absolutely, although it is possible for it to become more important (to some people) than it should be. But the Sprint Goal does tend to give a common goal for all the Team. so the team tends to work together better. And the Sprint Goal tends to diminish the possible myopia of too much focus on individual stories, being “lost in the weeds” as they say.

Now, should the Team commit?

This has recently become a controversial question. Let me explain. In the new Scrum Guide from Schwaber and Sutherland, they have eliminated the word ‘commit.’ They are rightly concerned, I think, that some managers are forcing Teams to fulfill commitments under ‘innovation’ conditions. And they say, and I agree, that in innovation conditions (which is what most of us should be working in), forcing people fulfill every Sprint commitment is silly. Just too many variables in our business, too many unknowns and unknowables. Forcing overtime or punishing people because our work is uncertain just does not help.

Still, after the Sprint Backlog is done, the Team still should commit to that plan. They should start believing that they can do it (I say ’9 times out of 10′). Not that they always *will* do it. But, today (the beginning of the Sprint) with what we know today, we feel this is reasonable and can be done. It is nothing like a fantasy plan, that could never happen. That’s the way I have explained ‘commitment’ for years and how I continue to explain commitment. A commitment in our business can never be a ‘guarantee.’

Managers may not ask (ok, should not ask) a team to work overtime to fulfill a commitment. This is silly and unproductive. (A discussion for a later blog post.)

Now, the biggest problem I find is that Team’s over-commit. And then disappoint everyone, including themselves. This must stop. Promise what you really have a good chance of delivering. If you have extra time at the end of a Sprint, take on an extra story. But do not pretend to be able to do more than you can reasonably do. ‘Stretch goals’ do not help. (again, a topic for another post).

So, what should the Sprint Goal be. Well, something that brings the Team together, and that represents the main focus of the Team for that Sprint. Typically, a one sentence version of the top 5 stories out of the 8 ‘commited’ for the Sprint — something like that. So that when we learn, and maybe things need to be adjusted, we might modify stories, but we are less likely to modify the Sprint Goal.

Product Owner & the Team

Posted on January 16, 2012 by Joe Little

Is the product owner a member of the team? Yes. Fully and completely.

What is the biggest problem that most teams face? That, at the high level (value) or the low level (details), they don’t understand what the customer wants well enough.

And who is mainly responsible for managing the flow of this ‘business information’ into the Team? The PO of course.

And this is a never-ending job. For example, at the lowest level imaginable, as they complete each step of work, he should be giving feedback: “well, that was not quite what I meant”, meaning really “I don’t think it is quite what the customer will want.”

The feeding of the team, this feedback to the team of Devs (meaning, in overly simple terms, creators and testers) is essential. And must be done daily.

When we start with a past tradition of thinking and working, there are many obstacles to this ‘union’ or yoking of the PO with the Devs. One is that the Devs wonder “what is that guy doing hanging around here?” Another is that the PO feels kind of weird around all these geeks and their geek-talk.

But both sides need and will eventually learn how to live and work with each other. It takes time.

Only together, as a full team, can they win.

Why call it "BV Engineering?"

Posted on November 29, 2011 by Joe Little

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.