Scrum and Release Planning
I went to the Agile Ottawa group last night. Mostly I very much enjoyed the meeting. 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. 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.
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.
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.
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.
In "Agile Project Management with Scrum" by Ken Schwaber there are only two mentions of Release Planning (according to my Kindle) in the book. Both not favorable. So, one can see why some people might get a wrong impression from that book.
What's Wrong With Up-Front Planning
Now, let me guess why Ken Schwaber minimized the mention of Release Planning in the book mentioned above. 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 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 Release Planning. Usually quite a number of changes and quite significant. In which case, the initial date and budget quickly becomes 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 3 month release can probably be planned usefully using agile methods (Release Planning) in about 3 days or less. Not a half-day, but again, not 2 weeks or a whole week either.
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.
A. 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 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.
B. 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.
C. 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.
D. I think the biggest value of the initial Release Planning is that the whole team starts to see the same elephant. The same effort. In multiple dimensions. The stories (functionality), the business value, 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. In part, because it gives the whole team a relatively easy way to 're-plan' the overall effort as things change (really, more "re-see" than just "re-plan").
Let me emphasize that in Scrum, we are always doing "Release Plan Refactoring" every Sprint. (People using Scrum often call this continual replanning other things, but it includes re-planning in multiple ways, such as: adding new stories, using a new known velocity, changing some story points, adjusting some business value points, slicing rising epics into smaller stories, etc, etc.
E. 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 richer middle-level. The team feels like 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 by changes much.
More to say, but enough for now. For those interested, see our earlier posts on Release Planning.