Scrum and Release Planning

I went to the Agile Ottawa group last night. Mostly I very much enjoyed the meeting — a lot of smart people, a lot of good discussions, but…

A Sad Tale

A gentleman there, a serious business guy, new to Scrum, said something like this: “It seems to me that Scrum has no up-front planning, and for those of us in the business world who must give some up-front estimate of time and dollars, this is not going to work for us. Does Scrum have some up-front planning?”

Several people answered, and I gave an answer: YES it does have up-front ‘Release Planning.’ Scrum does normally include up-front planning. This is somewhat controversial in Agile, but we have it. It is called Release Planning.

(OK, technically Scrum does not include Agile Release Planning, but very, very often we add Release Planning to it. Nearly always.)

And I went on to say some of the things I say below, but my comments were brief, and it seemed to me they were drowned out by Agilists saying, “Why do you want to do up-front planning?” (and similar comments), which is a good question, but again, it likely implied to the gentleman that all we ‘scrummers’ hate up-front planning. Perhaps I am wrong, but it seemed to me that he heard ‘Scrum does not do much Release Planning.’

I discussed this with a person in my CSM class the next day. His comment was, “Yes, based on the stuff I have read [and he had read several things] Scrum does not say much about the up-front planning. I can totally see how that person had that impression.”

To me this is very unfortunate.

[Aside: I call this a sad tale, with my tongue somewhat in my cheek. These are relatively normal human misunderstandings. Perhaps a bit sad, but nothing to compare to the sadness in Libya right now.]

Let me now make two references.

In the Scrum Guide (located here, among other places), Release Planning and a Release Planning Meeting are specifically mentioned and discussed. (See the Feb 2010 version.)

In “Agile Project Management with Scrum” by Ken Schwaber there are only two mentions of Release Planning (according to my Kindle) in the book — bboth not favorable (really about bad release planning). So, one can see why some people might get a wrong impression from that book, and some other sources as well.

What’s Wrong With Up-Front Planning

Now, let me guess why Ken Schwaber minimized the mention of Release Planning in the Scrum Guides after Feb 2010. First, Schwaber and Sutherland note in the Scrum Guide that a lot of the details about how to do Release Planning are outside the purview of Scrum. Meaning: Scrum is a framework only, and as such, it is probably not useful or necessary for Scrum to give guidance on this that could be seen as Scrum’s “answer” for everyone. Starting to do that risks making Scrum too big to implement in one step, relatively quickly. And risks giving great advice for one effort inappropriately to another effort or situation.

To me, these are quite reasonable concerns, and I think it stretches the point, though, to be so quiet about Release Planning more generally, and, indeed, the Scrum Guide, short as it is, does give a fair amount of guidance on Release Planning.

Another hypothesis I have is that Schwaber was concerned at the time he wrote his book that he was seeing too much Release Planning in ‘scrum’ implementations that looked too much like waterfall release planning. (I think I have seen this some too, although perhaps not as much.)

So, what’s wrong with that?

Well, first, the customer sees no value in Release Planning per se. It is, to use Lean terms, at most a ‘necessary’ waste. So, we want it to be as short as possible (but not shorter).

Second, too often people think the main (only) value from the initial release plan is the initial date and budget. Usually, as indicated above, that initial date and budget are necessary information to make some initial basic decisions. Maybe even accurate information if there were to be no changes, but anyone with much experience with projects has a near 100% experience of changes to projects after the initial Release Planning. Usually quite a number of changes and quite significant, in which case, the initial date and budget quickly become moot (in terms of accuracy; possibly still “directionally” useful, if you have a firm that thinks in those terms).

Third, often the initial Release Planning date and budget are used to drive people on Death Marches. This is an horrendous and utterly scandalous thing in our industry. It is shameful that we let stupid managers use this information this way, but that’s the way it often happens, and unfortunately, this gives Release Planning a bad name too.

And partly because of this, many coaches recommend that Release Planning not be done until the team has established a real Velocity. (To me, for reasons I will not explain here, this is the wrong solution to a very real problem.)

Fourth, because of the rapidity of change in many areas, many Agile people feel that the YAGNI (You Ain’t Gonna Need It) principle means that up-front planning should be minimized — very minimized. Often these people are from business situations where keeping Release Planning quite minimal will actually work, but, in my professional opinion, other business situations actually greatly benefit from some up-front planning, so long as everyone uses the plan (and all its refactorings) to drive good behavior (such as minimizing the stories that get in the real “minimum marketable feature set” of the next release).

I guess we need to be concrete here, to avoid silly discussions. I won’t give all the parameters here (and, to be more accurate, one should), but let me ballpark and say that a typical six months of work for a Scrum Team can probably be planned usefully using Agile methods (Release Planning) in about 1.5 days or less. Not a half day, but again, not two weeks or a whole week either. Again, there are potentially a host of possible factors; these are fairly typical real-life situations I have in mind.

What’s Right About Release Planning

OK, so we acknowledge that there are ‘issues’ with up-front planning (and more than we said above). These are not issues that either Scrum or waterfall create, but issues nonetheless.

Now, let’s look at some of the positives.

• Businesses need some way of comparing efforts, to decide which efforts should get started, and which should not start. Exact or even somewhat ‘accurate’ numbers are not essential here, just some rough sense of date/budget and level of accuracy. In virtually all businesses that I work with, this is (or should be, in my professional judgment) a requirement.
• The team needs to start to see, at a middle level, the interrelationship of the benefits and costs of the work (features) it will be building. To make many other decisions (architecture decisions, among them). Again, rough numbers are sufficient usually, and even very rough numbers are better than nothing. Release Planning provides this information.
• A sense of the rough time trade-offs is needed. Customers always want features immediately. When the initial conception of the first release looks, as an example, a long way off, it forces the mind into innovative solutions about how to scope down the first release. Release Planning can give the team enough information to start being innovative this way.
• I think the biggest value of the initial Release Planning is that the whole team starts to see the same elephant and the same effort in multiple dimensions — the stories (functionality), the Business Value (at a story level), the effort (at a story level), the risks and dependencies, etc. This is extremely valuable and, in my experience, the level of ‘same-page-ness’ is so very much better than what I always did in waterfall planning (and what I still hear). Again, extremely valuable, even though it will change.
• Re-Planning. The initial release plan sets up a base from which re-planning can be done easily, each Sprint. I call this Release Plan Refactoring (and sometimes we use other names for it, such as: Product Backlog grooming, Product Backlog refactoring, etc., etc.).

Re-planning, as Eisenhower implied, is essential. The way I will put it (maybe mixing some metaphors) is: We have to use Pareto to deliver just the most essential stuff so the customer gets the coffee while it’s still hot — a continual daily-hourly fight to see that most essential stuff. Mark Denne’s “Software By Numbers” talks more about why it is so essential to release a “minimum marketable feature set.” A great phrase.

Let me emphasize that in Scrum, we are always doing “Release Plan Refactoring” every Sprint. It includes re-planning in multiple ways, such as adding new stories, using a new known Velocity of the team, refactoring the story points on a few badly estimated stories, adjusting some business value points, slicing rising epics into smaller Sprint-sized stories, etc., etc.

Having mentioned all these things, we can remember: Scrum does not define these activities. Again, Scrum is a framework only. I have given you what I see and teach and advise for almost all situations (and other people whom I respect also concur with these), but the activities just mentioned are not defined in the Scrum framework.

• The final value is motivation. The team no longer feeling like they are getting the mushroom treatment. They see the ‘big picture’ at a more meaningful and at richer middle-level. The team feels they are respected. They see themselves as adults making an adult, well-considered commitment to build that product. This motivational impact is quite important, and is not affected much by the inevitable changes later.

_________________________________

More to say, but enough for now. For those interested, see our earlier posts on Release Planning, as well as future ones.

« « Additional ideas: adopting lean-agile || Agile & Religion – 1 » »