ALN RDU: Joe’s Agile Release Planning

I had the pleasure of talking with the Agile Leadership Network group in RDU tonight.

First, there were a lot of smart people there and I enjoyed it.

Here are some things I forgot to say or did not emphasize enough.

1. I have different goals that many have for what we call agile release planning. With different goals, we have different methods.

2. To me, the main goals include…

Increase the motivation of the Team (fingerprints, part of the creation)
Get everyone on the same page, seeing the same elephant.
Get alignment.
Sharing the tacit knowledge
Team building
Who knew the people were most important?

Yes, there are other important goals, but these are the primary ones, in my view.

3. I am NOT proposing a ‘one size fits all solution.’

I feel confident that my ideas for Agile Release Planning work in many situations, at least common situations that I meet commonly.

But I do not feel that these ideas fit all situations.

If they work for you, fine. If not, I am ok with that.  You should use what you think will work in your situation.

4. We need to keep it simple, as simple as possible.  This helps many things.

So, I have described it simply, perhaps too simply for some. And more simply than it really is in real life.

But if your team needs to add things or make it more complex, please do. It may be useful and necessary for you.

Again, what I am proposing may also not work for you.  It has not been tried in anything close to ‘every situation’.  Use judgment.

5. The hip bone is connected to the thigh bone.

Meaning: Everything we do is, to some degree, connected to everything else. For example, to deal with some issues, one can talk about a solution as part of ‘agile release planning’ or as part of Pareto-izing the work in the course of the Sprints.  To fully understand ‘agile release planning’ one must really understand ‘everything else.’ And yet, we never have time to describe ‘everything else.’

Perhaps the biggest things I want to add are these:

We hope the conversation helped us all to think more and better.  And that that, in some way, leads to better results.
We hope we mentioned some ideas that you try to do, and that some of them are useful.
Thank you!

SAFe, LeSS, DAD, and ScrumPLOP

First, I wanted to say that I feel each ‘large scale agile’ situation is different.  The key problems are different.  And therefore, the solution(s) should be different.

And I like the idea of patterns. This is the patterns idea: “Here are some things (patterns) that others have found useful, and maybe I can steal from them, and maybe even these things (patterns) will be useful for me.”

One of the nice things about patterns is that they start modestly.  They do not boast “oh, I am sure you MUST have this tool.”  They simply suggest: “Oh, you might find this tool useful.”

Here are some places where you can steal (in a nice way).  Because I like patterns, perhaps I like ScrumPLOP best.

SAFe.  Scaled Agile Framework, associated with Dean Leffingwell. See here.  Notice the lengthy glossary.  And you will notice a whole bunch of Scrum words that have been redefined.  Or slightly redefined.  There is quite a lot there.

LeSS.  Large Scale Scrum.  See Scaling Lean and Agile Development by Craig Larman and Bas Vodde.  I really like that book.  Here is some info on the web.  You will notice both similarities and important differences with what “Scaled Agile Framework” is suggesting.

DAD. Disciplined Agile Delivery, associated with Scott Ambler.  In some sense Scott has been talking about these issues for years. But now he and others have this site. Again, some similarities and some important differences as compared to SAFe and LeSS.

ScrumPLOP. The Scrum Pattern Language group.  The two key people behind this (in my opinion) are Jeff Sutherland and Jim Coplien.  I have already said I like the patterns idea.  And I have worked with Jeff Sutherland fairly extensively, and I have only the highest regard for him. This repository covers many things, and is not just addressed to the issue of ‘scaling’, however one might define scaling.  But, it has a number of ‘scaling’ patterns.  Some of the scaling patterns include: Chief Product Owner, Product Owner Group, Scrum of Scrums, Impediment Removal Team, Organizational Sprint Pulse, etc.  You will notice that some of the groups mentioned above use these same patterns, although they may call them something different.

I hope these resources are useful to you.

Again, I wish to remind you and caution you: Do not forget the individual team(s).

If you have great scaling and bad teams, you have almost nothing. If you have great teams, and fairly weak scaling, you still have something quite powerful.  Don’t lose focus on what is important.

Why I prefer ‘Release Plan Refactoring’ to ‘grooming’

I was just doing a course with Dave Muldoon in Canada. One of the workshops was scaling. In that context, we discussed release plan refactoring or product backlog grooming.

To me, the Scrum community has many definitions of ‘product backlog grooming.’ In fact, the community has many different words for it. And it is confusing, especially to beginners.

I like to use the phrase ‘release plan refactoring’ instead.

Today, briefly, I wanted to explain why.

But first, why is this question even important?  Because ideas affect actions. If we do the action without a deep understanding of the intent, we are very likely to do the action in an ugly way.

Basics

The bare framework of Scrum does not define ‘release planning.’ Nor does it define ‘backlog grooming.’ The latest Scrum Guide does have a few vague phrases like this: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process….”

My understanding is that Jeff Sutherland and Ken Schwaber are not against doing specific things and using specific words in specific situations. They just feel that they don’t want to include those things in the bare framework of Scrum. Why? Well, that’s a lengthy conversation for another day.

Probably not all teams need what I call ‘release planning’ — the short, quick up-front activity of defining a product backlog and guessing at what the next release or 2 or 3 might look like.  And maybe some other things. Not all teams need release planning I guess, but in my personal experience, virtually all teams the teams I have worked with have needed some short quick up-front release planning.

In any case, we have some sort of product backlog. And, clearly in real life and clearly according to the Scrum Guide, that product backlog must ‘evolve.’

What to call it

So, what should we call that activity that makes the product backlog evolve?  (Well, the true root cause of course is ‘change’ very broadly speaking.  But you know what I mean…)

PB Grooming:

To me that connotes two chimps grooming each other. I visualize grooming my face, or a man grooming his beard, or a beautiful woman putting on make-up, or grooming my toenails.
When I see ‘regular’ teams do what they call grooming, it is mostly these things:

• breaking down stories (or PBIs) into smaller stories (or PBIs)
• Identifying new stories
• adding Story Points to the new stories
• adding acceptance criteria
• more broadly: getting the top stories ready for the next sprint

And this is great. Very important. Useful, good.

BUT…incomplete.

Usually they are not doing, or not doing effectively, the longer-term activity of managing the product
backlog toward success in the release (and here I am assuming that it takes 3 to 10 sprints to build the release).

PB refinement (the term in the Scrum Guide), when people use that term and you watch what they do, they usually do (and say) about the same things as for PB grooming.

Note: There are many exceptions, of course, to how people use these terms. I am saying what I generally hear and see.

Release Plan Refactoring (RPR) – Why I like it

First, RPR suggests that the ‘whole’ release plan needs to be refactored.  In every way.

In software development, the word ‘refactoring’ has a set of strong connotations. Of professionalism, of robustness, of having to be on top of it all the time. But also of balance and cost-benefit approach and other things. Almost all of these things apply, at least by analogy, to Release Plan Refactoring.

Also, to me, RPR helps express, to people in the Team and people outside the Team, one key idea.

The initial release plan is never ‘good enough’, and we are always trying to make Release Plan closer to what we will do to make the release successful.  So they can say tp themselves: ‘yes we have initial release planning… but immediately we embark on continuous release plan refactoring to make the RELEASE successful.’

Release Plan Refactoring also includes the ‘getting ready for the next sprint planning meeting’ stuff too. It include the ‘short-term’ stuff as well.

To me, one of the key advantages of RPR is that it connects
(a) the longer-term thinking around ‘what does the release need to look like’ and
(b) the short-term thinking around ‘what will we do next sprint’.
To use two words, it connects tactics with strategy.  And both are required to be successful.

And my feeling is…
(a) we could try to re-define PB grooming or PB refinement to include those ideas of connection, so that the community ‘gets it’ better, or
(b) we can start using a different word (well, 3 words, RPR) to express that idea.

Clearly, I think (b) is the better approach.  Am I right? (You decide.)

Now, really, the words per se are not important. What is important is that people have the right ‘tacit knowledge’ when they take an action.  They need to know, when they try to ‘improve’ the product backlog (the release plan), why they are trying to do it, and how all the different things inter-connect.  For example, how the short-term stuff connects to the long-term stuff.  How tactics connects to strategy, if I may use those words in this context.

***

If you are interested, I discuss the practices more in my new booklet “Joe’s Agile Release Planning”.  Available here.