Jeff Sutherland did a presentation at Agile 2013 that I think everyone should read and think about. And read and think about again.
Here is the slide deck:
Jeff Sutherland did a presentation at Agile 2013 that I think everyone should read and think about. And read and think about again.
Here is the slide deck:
I was speaking to a smart guy who had taken (some while ago) my CSM course. We were both waiting at the Cluj airport. He made me think about this problem.
The first thing to say is that Scrum is not a panacea. It requires hard work. Often people expect Scrum to magically make things better. And it can have a huge impact. But it requires a lot of effort in several ways.
One advantage of Scrum is that a manager (and the Team itself) can quickly see if a Team is not doing well. If they are willing to look and they know where and how to look.
Here are some of the things Scrum requires to be successful.
These are 6 key factors for success. Usually that is 5 more than I can deal with today. If you can get one or more of these fixed, perhaps it will ‘work for you.’
Hope they help you or a friend. I am curious as to your first 5 or 6 guesses as to why others may feel ‘scrum is not working for me.’ Or more, what could they do about it?
Another way of looking at this issue is the Scrum-Butt Test. Which I have already written about extensively.
And hello to my friend and all my friends in Cluj.
Here are some additional patterns to consider when Scaling.
For now, consider that I am using a narrow definition of scaling, to mean only, collocated teams working together on one product in a fairly tight way.
1. Upfront Work.
To over-simplify, if we create any product, we plan, we build, we release. That is the simplest pattern.
And, often, especially with ‘greenfield’ products, we have to do some ‘upfront work’ along with the planning. This is true even with one Team. I call that work I-A-D. Infrastructure, Architecture, and Design. There are many names for it, and the exact nature of the work can vary a lot depending on the nature of the product. And god knows, there are lots and lots and lots of variations for how people are doing this work currently.
There is so much to say about I-A-D. Let me say only a few things here, today.
One, we must keep it small, but which now I mean mainly small in duration. It is so easy to ‘take-off’ 6 months to do a perfect architecture, as an example.
Two, it must be tested incrementally. All knowledge work should be tested quickly after the knowledge is created. And re-tested and re-tested.
Three, as we scale, we must accept that, ceteris paribus, we usually need more of it than with a smaller effort. Or an effort with fewer people. It, for example, has to be documented somewhat more.
Four, we want ‘everyone’ in the 3 scaling teams to know ‘everything’ about the I-A-D. Well, as soon as I say that, you see our dilemma. Getting all 21 people on the same page about the I-A-D is a ‘knowledge management’ nightmare. But, as soon as we have scaling, that’s what we want. So, using common sense, we do things to help the knowledge appropriately spread throughout the Group (the 3 Teams).
Ok, for today I feel I have said enough. Good people, with common sense, can execute on those ideas. But it is true that many of us need more detailed patterns, even for only 3 teams. More on that later.
2. Coordination of Sprint start and end dates
In general, it appears to be a good pattern to have all Teams in a scaled group start and end their sprints on the same day (or days).
Why? Well, they have to be coordinated together. In part, this means that they must receive feedback together. And then use this feedback together.
Yes, I entirely understand that this pattern, as much as it helps, also presents problems. How do you actually do it? What is the same person needs to be in 3 meetings at the same time? Etc, etc. Still, it seems to be the better pattern.
Both in theory and in practice. If it makes you feel better, think of it this way: this pattern sucks the least.
3. Changes to Sprint Planning Meeting
As soon as you scale, you want all 3 Teams in your Group to be at one Sprint Planning Meeting. But then you have roughly 25-30 people in one meeting, and a meeting that size always sucks.
So, what to do?
Clearly (from experience) you cannot have each Team working alone, in their own Sprint Planning Meeting with no ‘outside’ influences. Also, clearly, having a whole day meeting with 25-30 people is very very hard.
The usual solution is to compromise. That is, spend part of the day as a Group. And part in individual Teams. I like starting as a whole Group. And ending as a whole Group. And maybe a middle whole Group meeting where you review the stories selected for each Team.
4. Changes to Sprint Review
As soon as we scale, and we want to have the Sprint Reviews for each Team on the same day, someone says: “How can we do that? We need the same people, or many of the same people in every Sprint Review?” Which usually is a correct observation.
So, we use common sense. There are many similar answers, but I’ll suggest what my colleague Catherine Louis calls the Science Fair approach. You probably did this as a kid. Each kid or team had a table in a large room, maybe the cafeteria. And all the parents would file in over 2 hours, and the judges too, and look at each of the ‘exhibits’ or ‘experiments’. And go back and forth.
And that is the idea.
So, each Team continuously demos its features. At a separate table. And the CPO (chief product owner) and the POs (the product owner for each of the 3 teams) and the BSHs (the business stakeholders for all 3 teams) all move from table to table, trying to see what has been done, how it fits together (or doesn’t), and deciding how to give the best feedback.
And in fact, team members also shuttle amongst the tables, trying to see what has been done by our Team and the other Teams, and how it all fits together and what it ‘means’.
As you can see, doing this well requires some skill and experience. And you can imagine the self-organization that also takes place each time. And in ways that cannot be predicted. People will see issues and identify inter-relationships that could not have been anticipated beforehand.
In any case, hard as it is (and in some ways, it is easy), we recommend the Science Fair approach. It takes somewhat longer, but it pays dividends.
We also recommend that each Team have a short ‘review’ discussion. And that the whole Group have a ‘review’ discussion. Probably a short Group review at the beginning, and then again, at the end, to review the overall feedback and its implications.
If only scaling were simpler! For that matter, people! You know, if we could only get rid of those pesky customers, things would get a lot better real quick!
That reminds me of the most important advice about scaling: KISS. Or, as Einstein perfectly expressed it: “All things should be made as simple as possible, and not simpler.”
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.
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…)
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:
And this is great. Very important. Useful, good.
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.
I have been thinking a lot about corporate culture lately, and what we can do to change it. For example, to enable Scrum to get better results.
Here is one article by John Kotter. Pretty good I think.
So, what can we do. Here’s my advice to myself:
1. “Whether you think you can or you can’t, you’re right.” Henry Ford
In other words, don’t give up before you start.
I think we have to be modest. We don’t control anything, really. But we all do have influence. And if we are a bit clever, we can gather and leverage some influence, and make some change happen.
2. Show up.
Show up every day. And do something every day. Very few of us are great change artists. But by working at it every day, we become better and better.
3. Gather your ‘friends’.
Don’t try to do it alone. Never works. I don’t think it has ever worked. Although if you look at some changes, there has been a stronger clearer ‘leader’, and with other changes, it appears to be more a ‘group.’
If the change you are proposing is at all good, you will find others to help you. Pull them together. Work together, as best you can.
4. Decide what culture means to you. Be as specific as possible.
Most of us, in my experience, are terribly vague about what we mean about culture. Make it more specific. Describe what specifically you’d like to change. Propose, clearly, what you want to add or put in the place of something.
As one minor point: If you say “We need to redesign things around here” many are likely to object. If you say “I want to exchange the old faucet set in the bathrom or this faucet set” then they might easily agree. The FUD factor is gone (Fear Uncertainty Doubt).
5. Pull together some ideas about people. You’re going to discover a lot about people. Your new BFFs. You need ideas to help talk about people and groups of people.
In my experience, most people don’t understand people very well. It turns out that a few people, over the course of time, have studied people and how they change. So, study up with these ‘experts’ on what people are like, how they work in groups. How they change.
Get some theories and talk about them with your group of revolutionaries.
I expect, hopefully, that you start to have some sympathy with the people you want to change, whose lives you want to change. You start to see them as rich complex people in a social milieu. They are not just ‘in the way’ things to fix. One quote related to this: “People don’t resist change; they resist being changed.”
I also mean here that you will see that people ‘lie.’ They will be supporting the change, or say they will, and then they will become your ‘enemy’ in an important meeting. Did they really ‘lie?’ Well… it’s complicated. People are complicated. So, be patient. Be forgiving. Expect some bumps, some surprises.
Freud, Maslow, Daniel Pink, John Kotter, Dan Mezick, Geoffrey Moore, …I am not that picky which theory or theories about people you pick. I would look at multiple theories.
6. Decide how you would know some useful ‘change’ had happened. (eg, “They allow us to start a 2nd Scrum Team and fix these 3 impediments.”)
Metrics. Well, maybe that’s what I mean.
Well, it does not have to be metrics per se. But, how will you get an idea that you are making progress. This can be a hard problem for any kind of knowledge work. And changing culture is about this most abstract kind of knowledge work I know of. So, making progress visible with ‘culture change’ is a key problem.
Culture change can be a hopelessly vague concept. Example: “We want the culture to accept failure.”
But if you say: “I want George and Sridar to accept that, at the end of the Sprint, the Team may not always get all 8 stories done? And this is ok, in part because the Team learned a lot in the Sprint.” — if you say that, then you have made the vague culture change much more do-able. And you can see progress, one Sprint, one Team at a time. Or maybe lack of progress. But it is more visible.
7. Define the culture you want. Incremental-ize it.
It is hard to make a large change happen, all at one time. I find it hard to get myself to lose 5 pounds in a month. And that is a small change for one person.
So, define what you want to change. Pick out a few things in a limited scope. Then do that. Pick out the next few things in a limited scope. Do that. Step by step.
Allow your plan for change to … change itself. As you learn more.
The definition of the culture change in this list does not have to be super-precise. But precise enough that you can ‘feel’ how big each piece is. And feel that it all fits together. Feel whether those things together will lead to a good result.
There will be, roughly, 3 sizes of changes.
A. Large changes.
Ex: We got 4 teams doing Scrum. This might all happen in 1 week.
In Lean, they call large changes Kaikaku.
B. Medium changes.
Ex: Team 3 started moving toward TDD at the functional level (A-TDD). With mostly automated testing. They do not have automated regression testing really yet. (In some places, this could be a big change.)
C. Small changes
In Lean, they call small changes ‘kaizen.’
Ex: In the Retrospective, we made a bunch of changes to make our Daily Stand-ups better.
Now, even each of these can be made more incremental, if that would help. And often taking things step-by-step helps.
These ideas are not everything. We have more. But we think they are a good start. Some of you will note that several are inter-related. They make more sense together.
To some of you, at least some of these ideas will be basic. Assumed. “Of course we do that.” But this is not so for others. And we often disobey our own obvious rules. So, remember to talk about these with your change group, and remind them.
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.
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. It 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 is 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, a 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.
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.
We have added a 1 day Workshop to our course in Toronto. And will add this to courses in some other cities. The one day is composed of 1/2 Day on Story Splitting. And 1/2 Day on Scaling.
What. Story Splitting is always required. We always need smaller stories in the Sprint. Some experienced Teams do this regularly and quite effectively, but lots of less experienced Teams struggle with this. So, the immediate purpose of the workshop is to move them beyond the ‘struggle’ stage more quickly.
Value. Story Splitting is not the only factor that can assist your Team to achieve the following benefits, but it is important, and often key.
See here for a fuller description of the Workshop.
First, here is a page that starts to explain SAFe. SAFe is one of the better known ‘scaling agile’ frameworks. http://scaledagileframework.com/
You should also look at Larman and Vodde’s book: Scaling Lean and Agile Development. See also their LeSS (Large-Scale Scrum) framework, here.
Next, Jeff Sutherland and Jim Coplien and others have worked hard on ScrumPLOP. This is the patterns around Scrum. This deals with more than scaling, but includes many scaling patterns. See here. As one example, see the Chief Product Owner pattern.
Next, here is a blog post by Ken Schwaber. Many of you know that Mr. Schwaber is one of the co-creators of Scrum.
Next, here is a longer blog post by David Anderson. Many of you know that Mr. Anderson is the main advocate behind the agile “Kanban” method. (I say it that way because I think of kanban first as the ‘signcard’ idea that Lean uses. Which is notably different.)
A few comments by me:
First, I think Dean Leffingwell is a good guy who is trying to help. Some want to paint him as the devil, which seems silly. But whether all our ideas that ‘wish’ to help are, in the end, truly helpful…. that is another question.
There are a lot of ideas in SAFe that I know and love. What troubles me more is the ‘weight’ of the whole framework, not individual things in it. The implications of the whole thing.
In general, I think Anderson and Schwaber don’t agree very much on ‘things’ in general. Hence, I am struck by is how much they agree about SAFe. Their concerns to me are very similar.
I simplify their shared concern as this: ‘SAFe has some good ideas within it — maybe even all the individual ideas are good — , but the strong bias will be to implement it as a single big turn-key heavy almost ‘waterfall’ solution. No matter what the stated ‘intention’. And no matter what the particular situation. And this is likely, in several ways, to be unhelpful.’
I want to note that I understand Dean Leffingwell has said that he does not want SAFe implemented that way. To which Schwaber and Anderson might say: ‘Well, he may say that, but de facto something else happens. I’d rather discuss the reality than his words.’
My general biases are these:
* some scaling in some situations is inevitable.
* In general, some scaling is not really necessary or useful. The answer should often be: “One real Team, one really good Team, would be better for this.” How much is ‘some scaling’?
* in general, all scaling is ‘ugly’ (my technical term for it, which I need to explain more). Mainly because communication across more than 7 people is really hard. No amount of lipstick on the pig will make it less ugly. Still, some things might make it ‘more effective’.
* in general, all scaling would benefit by a KISS approach — keep it absolutely even more simple than you can possibly imagine.
* all talk of scaling inevitably mis-directs attention away from the core engine of activity: the Team. This is not good; minimize it!!!
* inevitably, ‘smart people’ involved in ‘the scaling part’ want to assume more importance and more control than they should. Greater importance and control should be given to the Teams.
* in the end, there are trade-offs. OK, you must decide your trade-offs in your situation. BUT: KISS. KISS! KISS!!!
* I think that the term scaling should be restricted to having multiple [Scrum] teams work together.
* I think ‘broader agile adoption’ should be used when you want to have more and more teams use Agile. Perhaps all teams.
* I think Agile Transformation should mainly mean having the whole organization become truly agile, in values, principles, and practices. Not just the ‘development’ department (or whatever your firm calls it). 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.’
* I think Distributed Agile or Scrum should be restricted to these two situations: (a) one team has members in more than one location (ideally only two locations and only one time zone), or (b) two+ teams must work together, and each Team is in a different location. I would prefer that (a) was called ‘distributed team’ only.
* As it is now, all these terms are used quite loosely. So that real communication is low and mis-understanding is likely high.
* In general, many firms attempt (a) Scaling, (b) broader agile adoption, (c) Agile transformation, (d) distributed agile (both versions) — all at once. As soon as one recognizes this, the benefits of KISS are apparent. (One hopes the benefits are apparent.) As if by magic, the word cluster-bomb comes to mind.