Agile Release Planning – Some Questions & Issues

Last week I did an Agile Release Planning workshop.  Several different kinds of people there, including from 3 different firms.

And some new questions and issues.

Some things I should have said:

• The Agile Release Planning Day is the beginning, not the end.

I did say that, but not well enough.

Whatever you do the first day, you can always look back and think of things you “we need to do”.  And also wonder, “should we have done those during the ARP day?”

First, this is inevitable.  That there is more to learn, and still many good ways to learn.  And I think inevitable that we don’t think of everything.

So, the way to think of it: The ARP Day is a day of assessment.  A beginning.  And tomorrow, and until the first sprint, and every sprint thereafter — they all are more days to learn and then make the plan better.

One of my quotes:  “You are always chasing the tail of change, and trying to catch up.”  And that change includes all the learning by the Team.

• You can and probably SHOULD add some activities to what I suggest for the ARP Day.  eg, One or two extra steps or exercises.

Your team is special, they already know things that another team does not, and also do NOT know some things that another team would.  And the situation (the work, the project, the product, the broader situation) is always different.

For those reasons and others, it would be really valuable for your group (Team plus Business Stakeholders) to do one or two additional exercises that would not be helpful (helpful enough, at this time) for another Team.

It is likely, when you first start doing ARP, that you will not think of these one or two things in advance.   (You can think of them during the day.) But, later, with experience, you will think of some in advance.  Anyway, I do not think you lose a lot by doing these things later (after the ARP day).

Let’s remind ourselves: The whole situation at first is very confusing. New people, a new product or peoject.  It is impossible to think of everything.  So, do the best you can do in the timebox of Day 0 (as I call it).  And then do more later.

• An Agile Product Release Strategy

Obviously, if you are doing Agile Release Planning, it implies that you are identifying Releases (eg, their contents, such as built stories, and the date).  In Agile we also assume (although not always true) that you are delivering the evolving product in a series of releases.

In any case, you want to have a theory about how you will release, whether bigger or smaller, sooner or later, and why. And why this theory (or strategy) is something that you think will make us (the Team, the Company, the Customers) more successful.  Part of this strategy must include some basic ideas about content.

My opinion for most people is that they have been deeply influenced by waterfall (whether they know it or not).  And one of the BIG things in agile is to deliver less: to deliver the minimum minimum viable product.  Thus, only after you have a set of relatively small stories can you start to piece together the puzzle of “what’s a good first release.”  Often we do not make tough decisions until we see “oh, darn, if I include all this stuff, the first release is going to be later than I really want.”  And you can’t act on that realization until you see some relatively small stories in the Product Backlog (or laid out in the sprints).

One way of thinking about this: The strategy will tell us how to form and decide about when we have (on the story board or in real life) a good Minimum Viable Product.

• Waterfall Thinking

One of our key problems, when we first start doing Agile Release Planning, is that our thinking (and the thinking of almost everyone) is too dominated by waterfall thinking.

Therefore: I am ok if we discuss the strategy early or later.  I do think, to be agile, we must assume we are always open to a new strategy, if we start to see things a different way.  I think always, in real life, the exact MVP to some degree “emerges” as we see the product “come to life” as more and more done stories are added.  Or because the “customer”, commonly represented by the BSHs, just tells us: “OK, release that stuff now. I can use it.”

A key waterfall idea: “I have done X, I should stick to it!”

Example: We have a product release strategy, we should stick to it.

So, I am ok, particularly for those new to Agile Release Planning, if that release strategy is not clear on Day 0.  We and the PO make some decisions on Day 0, but in the following days it becomes a lot better.  Maybe some ideas become clear on Day 2.  Or the PO has some ideas on Day 1 (the next day), but those change notably in the middle of the first Sprint.

• Question: When do we do a top-down approach to the work?  The top 3 or 5 (or so) sets of work.  So that we can relate all the work (or much of it) back to the top 3-5 things.  When?

This question came up in this latest session.

I had not made this clear.

I said the Manager, who comes and tells us (eg, we are the proto-team at that point, commonly) which “thing” (the project or product) we will work on, also brings us some paper and tells us about the work.

I meant, but did not explain: That manager almost always defines the top 3-5 things (or big pieces of work) that we will be doing.  In more agile companies, the Steering Committee had a list of 3 or 5 or 10 or so “Epics” (in the user story format).  Whatever list they have, the Manager shares it with us and explains it to us, at least some.

Whatever the Manager gives us, if we like it, we go with it for now.  And we share it, before the ARP meeting, with new Team members.  If we don’t like it, we can (re)create something similar but better.  And, again, share that with new Team members before the ARP day.

We share it, but in agile thinking, we are never stuck to it, blocked by it. The list can change (if there is a sensible reason).

•  The Top 3-5 Drivers

Remember that we do recommend identifying the top 3-5 Drivers.

Yes, these are not exactly the main 3-7 pieces of work.  But they are similar.

That is a very similar idea to the question asked.  It is more about value, and being measurable, and less about “the work.”  But it does to some degree define the work.

• Identify the 5-7 Roles (actors, personas, user roles)

Identifying the user roles is definitely part of the ARP.

I would rather focus on the customers, and what they want, than on the work.

Remember: we want to do as little work as possible, to give them an MVP (that makes sense) quickly.  Quickly because they want something quickly and also so we learn faster.

Anyway: The “5-7 roles” is similar to the top 3-7 “things.”

***

Next.

I talked in that ARP session about the Top 3-5 DRIVERS and the 3-7 User Roles.

• Do some people tend to do things Top-Down first and others do things Bottom-Up?

I think this is basically true, for many people. And I think I see that more of our people are top-down than bottom-up.

So, I am expecting people to work that way, no matter what we say or want.

So, sometimes people in your group (Team plus BSHs) will sometimes ask: “Let’s write Epics first, then break them into Features, and then break them into smaller Stories.”  Frankly, I have not gotten that specific request (in the many ARP sessions I have done), but I have talked to people who want that.

Is that ok or good?

One answer: If your people really want it, to some degree you have to do it.

As I will explain, I am concerned that it becomes a back door to letting “waterfall” (or partial waterfall) back in.

• Back to Waterfall thinking.

We mentioned this before.

Let’s be more specific now.

One kind of waterfall thinking is to divide the work into big chunks.

Well, honestly, the big chunks themselves are not waterfall.  But rather, they may lead us toward waterfall thinking.

THEN (key): We start assuming that we must do everything within a large chunk before we start working on the next large Chunk.

Which, particularly to a waterfall person, makes them lean toward this idea (following): Release 1 will be all of Chunk A, Release 2 all of Chunk B, and so forth.

And almost always we get no benefit from the 80-20 rule, we build way too much low-value stuff, we do not question the need for every feature – so we will build (more) stuff they don’t want, and therefore the releases are delayed a lot compared to what they could be.  And therefore we learn slower and adapt more slowly to the changing conditions.

• What to do?

Identifying the work initially as these Big Chunks is not so bad, if we do it quickly, and do not take it too seriously.

And especially, if we remain open to how the Release could be much different (maybe looking to outsiders more like a collection of “random” stuff, that then, magically “comes together” in the PO’s mind, and then the customers love it).

Also, delivering only part of Chuck A in the first release can sometimes be part of a decent release strategy.

By picking smaller things, we think you reach this goal faster: small things that cohere to the customer, delivered faster, enabling faster learning and adaptation, and each delivery still has higher Business Value to the customer.

***

Please give me your comments on these thoughts and suggestions.

 

« « HBR: 5 Questions to Get Your Project Team on the Same Page || Notes for Improving Scrum Clinic » »