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.

Basic Agile ‘scaling’ terms

Below are several key terms used often when we discuss ‘Agile Scaling.’ And we want to discuss them.

Why?

Our experience is that when the community talks about these issues, they use these words in a very loose way.  The problems behind these words are quite real. And can at least be somewhat improved if we work hard and use the best ideas.  But the lack of clarity in the word usage gets in the way of good communication and good thinking.  And then the actions are muddled.

Let’s review these terms:

• Scaling
• Broader Agile Adoption
• Agile Transformation
• Cultural Change
• Distributed Agile or Scrum

What do each mean?  While the issues often overlap or come at you at the same time in the real world, I think each is different.  And that being clear about the differences can help us think and act in a more useful way.

Here are my definitions.

Scaling: Means having multiple [Scrum] teams work together on one Product.  In some sense, they are ‘in the same code base’ if it is a software product.  Two teams working together is one kind of problem. 3-7 teams is one kind of problem.  8+ teams is another kind of problem.

Broader agile adoption:
Means  to have more and more teams using Agile. Or new departments or divisions using Agile.  For purposes of this idea, assume that each team is working completely independently.  Note however: If your group is say 100 people, usually you also will be having some scaling as defined above (ie, here and there, at least, several teams are working together).  Very common.

Agile Transformation:
Means mainly having the whole organization become truly agile, in values, principles, and practices.  Not just the ‘development’ department (or whatever name your firm uses for that group).  This often covers many different kinds of issues.  However, it is fair to say that just introducing Scrum to a few teams almost inevitably leads to a kind of ‘transformation’.  It tends to affect, as we say, ‘everything.’
It can be said that even a small company with one Scrum team will have a kind of Agile Transformation. And then a company of 100 people people will have a more complex Agile Transformation. And then a company of 300,000 people might have a far more complex Agile Transformation.

Often this term is used to encompass ‘everything’.  Meaning, all the changes needed in a big company ‘going agile’.  ‘This is our Agile Transformation initiative’ is a sentence one could hear.  OK, but then those two words many lots of different things to different people.  Even with my relatively narrow definition, it starts to mean too many disparate things, in my opinion.

Cultural Change: This is where the culture of your group (team, department, company) must change because of Agile, or to make Agile more successful.  This is almost always needed to some degree with most any of these other changes.

Again, cultural change is often assumed in the phrase ‘agile transformation’.  And in a way, that is fair, almost always.

But at least in theory one can imagine a situation in which no cultural change is really required — the firm though could still need an Agile Transformation in terms of hierarchy, incentives, HR things, ways of managing, etc.  I think it is useful to think of the culture change as a separate issue.  Yes, as we are seeing, all these different things interrelate.  This is in part why the words have been mushed together.

Distributed Agile or Scrum:
Covers two situations:
(a) one team has members in more than one location.  In fact, if people are on two different floors, that is a ‘distributed’ team. Often distributed also means that at least one person is in a different time zone than another person on the team.  And, typically, the wider the time zone split, the worse the problems.
(b) two or more teams must work together, and each Team is in a different location.

You might want to call (a) distributed team and (b) distributed agile.

I also use the term ‘disbursed agile’ to mean a team where no two people on the team are in the same place.  I find this to be particularly hard to deal with. Typically.
Many people assume that ‘distributed’ is the biggest problem in scaling (or agile transformation — whichever their favorite word is). And yet many firms can be doing scaling or agile transformation without doing any distributed agile at all.

***

Maybe there are more terms to add to this list.  And maybe these definitions can be improved. But it is one set of eyes on these ideas.

This post does not try to provide any solutions. In fact, it barely hints at what the real problems are. The only purpose is to give you some basic tools (ie, words) to start to think about what the problems really are.  If we identify the problems better, then we have a better chance to fix them properly.

I have mentioned these ideas to a few other people. Some have been, at least I thought, rather cynical.  And with some reason, I think.  They see lots of consultants and others running around using words for marketing, and the feeling of these people is that consultants running around throwing around words is not helping. I have some sympathy with that concern.  But I have not become cynical.

Second, I think they feel that these words and issues have become hopelessly muddled. I think their feeling is that talking about them publicly is a waste.  Or, at least, humorous in a cynical way.  (Maybe talking about these words in one room with 7 people is useful, but not in public.)  Again, I do agree that getting many people to agree on common definitions of these words is almost hopeless.
Still, I obviously think that discussion in public is not hopeless. Although it is difficult.

Key Impediments – Toronto

I am a big advocate of a public impediment list.  (Yes, for some of you, I am saying this again.  I think in general it bears repeating and repeating in a company.)

There is some discussion to explain skeptics WHY I recommend this. I will not attempt that discussion here (but maybe I should soon in another post … I have in the past, just search).

By the way, I recommend only ONE list of all impediments.  Some people are tempted to have several lists. One for org impediments, one for agile adoption issues, one for Blockers (things that block a story from getting done, is the usual definition), one for impediments (however they define that term).  To me, ALL these things (and more) are just different types of impediments. We we need only ONE list.  And work from the top.

In the Toronto class this week, the group identified these impediments.  They are not in any specific order.

• Poor skill Team (skill sets are weak)
• Non Formed Teams
• Source Availability Planning
• Under estimate scope by Prod Owner
• Lack of investment (don’t remember what kind of investment the person wanted)
• Lack of requirements
• No product road-map (vision)
• Scope creep
• Lack of Comms
• Final product quality was poor
• Project team over-worked
• Senior leadership commitment & mission
• No clear product owner
• Unrealistic Time/Scope commitment
• Low accountability
• Project over budget
• Lack of ownership individuals
• Business down – layoff of developers / teams
• Ownership to one person
• Technology hurdles (ie, infrastructure)
• Too Bossy, No Teamwork
• Not able to remove impediments
• Low communication
• Not doing demo (sprint fail)
• No connection between Dev & Business

Pretty good list.

Changing culture

I am giving a presentation at Southern Fried Agile on Oct 18th, 2013.

On “Culture & Agile & Change”.

Here is the presentation slide deck so far.  To me, it is mainly a reference and a take-away.  But it does highlight some of the key things I will say (and many things I am sure I will not get time to go into).

Please read it and give me your comments.  It is a draft.  As I revise it, I will try to upload the new version.

What is culture? And do we start to change it?

Some of us in the Agile community think:  an organization's culture needs to change before agile can be fully adopted.

This certainly seems to be true.

Let's define this more precisely.  The idea is this:

Before a company can realize the full and extreme benefits

 of lean-agile-scrum, it must change its corporate culture to 

be consistent with lean-agile-scrum values and principles.

 This can seem a daunting task.

But, first, what is culture?

To me, it is that air in which we live and breathe and have our being.  Well, not exactly that.  But is the culture of the main group or groups within which we live.  It is what is in our heads, as a group. It is values and norms and common behaviors.

So, it includes the idea that we are not individuals (so much), but rather we are more 'groups', and that the key ideas or values or principles or norms of the group 'control' to a large extent, our behavior.  Without our even thinking about it.

Now, from our point of view in terms of the change, in many ways, the new behavior is more important than new thoughts (or subconscious thoughts or feelings).  But we want the people to be autonomous, and 'do it on their own', so we want the thoughts or feelings to be there, so they naturally do it, naturally act agile, on their own.

Moreover, we want the broader culture to be consistent with agile.  With lean-agile-scrum.  People typically find, if they do things consistent with the culture, they seem relatively easy. And, if you do things counter to the culture, it usually is hard or harder.  So, having an agile culture should mean that agile will be more successful. Other things being equal.

Ways of changing

Asking people to change their culture is difficult.

Well, clearly to ask itself is not difficult. But to ask, and then expect results, and then to know if results actually occurred...that is difficult.

Let's consider 3 days to make cultural change happen:

1. Talk to them.

Depending on your point of view, this is either remarkably successful or remarkably unsuccessful.

I mean this: My expectation is that normally this should have almost no impact.  And yet, for a few people, it can have an impact.  Sometimes.  For a period of time. So, compared to my expectations, this can be remarkably successful, sometimes.

There are many ways to talk to them, or with them. Many different contexts, different people who can do it, frequency, etc, etc. A lot more to discuss than we will discuss here today.

From another point of view, many people expect this approach to be very successful. And it is remarkably unsuccessful.

2. Get them to act and 'reward' their good behavior.

Pretty close to classic behaviorist theory.  Maybe it works. It is not tried often.  And, it seems, it must be tried a lot to have it start to replace the old culture with the new culture.

 Actions come in many shapes and sizes, including speaking original words.  And rewards come in many types.  Rewards must be close in time to the action.

Frankly, this is treating people like monkeys. I don't want to believe in this theory. But it is there.

3. Have them experience something

What you want to do is get them to help you create the new culture.  You teach them a bit, and then they become self-acting.  By teaching themselves things, by building the culture themselves.

And it turns out that if you are clever, you can start to build this self-reinforcing system.

But, according to Kotter, it starts with a gut experience. An experience that is fairly profound. And that gets them to commit to changing themselves. Kotter calls it 'a sense of urgency.'

Let me say again.  Changing the culture is the work of many months (or more) for a group of people, and then the new culture will start to replace the old culture (or, ultimately, be overwhelmed by the old culture). So, it takes many months and many people before it starts to be self-sustaining.

So, given the likely counter-action by the original culture, what you need it not one experience per person, but multiple experiences.  Over several months (or longer).

Then, once the new culture is established, it must be sustained.

If it is a culture of mediocrity, then sustaining it is less of a problem. But if it is a culture of high achievement and difficult tasks, it can take extra energy to maintain it at a high level.  (I think this is the case for lean-agile-scrum.  It has many pleasures, but it is demanding in terms of energy commitment and overcoming of obstacles.)  Now, focus on the successes and pleasures can clearly be part of sustaining the new culture.

Let me make clearer what we are doing with this last method.  We are not just asking them to change. We are asking them to join us in changing the culture. Maybe quickly, maybe little-by-little.  But we are asking them to participate in 'making it happen'.  Over time.

Here is where we start to bring in the word ritual.

***

So far I have over-simplified. To explain some key basics.  Much that I dd not say, but a start in setting out a basic framework.

One tip bears repeating: It is easy to start out to 'change the culture' and end up accomplishing nothing.  Be careful.  Pick your battles.  Prioritize. Get small wins.  Build on progress.

It is, in many ways, a battle in the air over ideas. But make it concrete and tangible too. Show the new culture in actions.  Then others can help you.

Lastly, let people tell you the truth.  As one example: If they can't explain well why we do a specific thing in Scrum, do not punish them for being human. And give them some support.  Maybe a local person in their location to support the change.  Changing the culture is not easy.

Scaling: How about the “Don’t do it!” option?

There is a lot of talk lately about scaling. And, to some degree, scaling is necessary and good.

They say that only truly professional Teams try complicated plays.  Or should try complicated plays.  Most ‘lesser’ Teams do well to stick to basic blocking and tackling.  I think this is wise advice for most teams.

Scaling by its nature is complicated. It is attempting the impossible. To keep a large ‘blob’ of people fully informed about what each other is doing.  No, not 100% informed about every detail, of course, but ‘fully.’  Meaning: I, as a member of the blob, know everything I need to know to be effective (and to not be counter-productive) about anything that anyone else in the blob is doing.

Impossible.  Human communication is very difficult in a Team of 7. Just about impossible in a blob. Unless it is extremely slow moving. Which of course is what blobs naturally do.

So, how about this?  Instead of 50 people in 7 teams, let’s take the ‘best people’ from that blob, and make one Super Team.  The hard part is finding ‘super’ team players.  Or maybe better to say: The hard part is appreciating the value of being a team player over having a so-called ‘extraordinary skill-set’ (usually a specific skill or knowledge domain in our business).  We all have seen that a bunch of high-ego people often won’t work together well.

Still, form your Super Team.

Maybe the other people can be useful, but the first rule is ‘do no harm.’  Get them the heck out of the way!!  And let the Super Team run.

Can these other people doing anything?  Well, yes: mow the grass.  Honestly….they can do some ‘spade work’ that never gets in the way of the Super Team.  They can do things that enable the Super Team to go faster. They can prepare things. But the key thing is to optimize the speed of the Super Team. (Ceteris Paribus.)

It’s an alternate idea.  From a business point of view, often faster, cheaper and higher quality.  And higher innovation.

Will this approach work well every time?  Is it the best option available?  Not sure; probably not.  But often it is the best option available.

Deliver Faster

Why do we want to deliver fast, and then faster?

Well, the first reason is...that's what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.

The second reason: time to market.  In this context, I mean we need a good poduct to market before the opportunity goes away.  Before the competition beats us there, or before the most important problem has changed.

Third.  More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped "we need to deliver faster than the next re-org". This meant within the next 3 months.

So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.

But there is more. We need to deliver faster because we get more feedback.  In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.

This minimizes risk. This minimizes WIP, whose value...if we wait long enough...will always eventually go to zero.  So, we have minimized the potential loss in value of the WIP, the work-in-progress.  We have reduced the risk.

All the reasons that make us want to deliver something faster.

Yes, it must be a minimum marketable feature set.  But we are learning that 'minimum' is smaller than we thought.

Deliver faster.  This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.

Then the question becomes: how do we do that?