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:
Adela asks this question: Imagine we have a brand new project. And we must bid on it, and we want to use the agile-scrum method. How should that work?
This is a good and a hard question. I will answer it quickly here. Too quickly. I have partly answered it in my book, Joe’s Agile Release Planning. And partly elsewhere.
Why is it a hard question? Because business and life itself wants us to do what is impossible. To perfectly predict the future. And to know everything in advance. And, while we all forever will wish those two statements were true (well, at least part of each of us will), they never will be true.
So, let’s make the case fairly simple. Imagine that the project (the work) is about what one Team can do in 6 months.
Then I recommend Agile Release Planning (as explained fully in my book).
The Team (including the right ‘business stakeholders’ or SMEs or customer reps or whatever you call them) do the following:
Ok, let’s imagine further that the client asks for a fixed price. So, after Step 10, we have to give a price to the external customer.
Now, the first time you do Agile Release Planning, I think you will get a better (slightly more accurate) scope-date-budget than you do using your current method. Still, for the first or second time, I do recommend doing it both ways. And comparing the results, and learning from that.
By the third time, I predict that you will be happier with this agile approach than your current approach.
Will the agile approach on day zero ever be ‘perfect’? No.
Always we guess at the buffer or padding. And always that guess can be too much (not a big problem if the customer agrees) or too little (a big problem if it causes us to go bankrupt). Notice that we as a vendor are biased to want to win contracts, and hence often ‘close our eyes’ and go with too little ‘padding’. Often.
In any case, once we get a signed contract, I recommend running the project in an agile way. Again, this cannot guarantee success, but it will enable us to manage the effort to better success (or a lower loss).
That’s the summary of my answer in one short blog post. I am sure I left many questions unanswered.
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.
We have a problem in Scrum.
First, we do well to call it more an opportunity than a problem. We have a lot more opportunity sitting on the table that we have not grabbed yet. Scrum, in general, can help us get a LOT more improvement than we have gotten. Yet.
There are many root causes behind this problem (opportunity).
And many possible solutions also.
But I think the biggest solution is more education (more coaching is maybe next).
By more education, I mean of the whole man, or the whole team. Not just explicit knowledge, but tacit knowledge. Not just of rational things but also of more squishy things (that’s the technical terms for them (smile)). More discussion of how the Scrum practices really work (eg, correcting Scrum-Butt). More discussion of the lean-agile-scrum values and principles underlying the practices. More learning about other things that must be added to Scrum to make it work in your environment.
Which leads me to discussing the new SEU path to the CSP. SEU means Scrum Educational Units. CSP means Certified Scrum Professional.
So, I am a big advocate of a well-rounded education in general. Scrum education is what we are talking right now.
The SEU path to the CSP allows you to choose the ‘education’ that fits your specific needs. And it requires that you show significant related experience that at least indicates you have attained, both via education and action, a ‘professional’ level in Scrum.
Our specific contribution (more to come) is a Scrum 201 course. This 2-day course plus the 1 day workshop gives you 22 SEUs towards the CSP certification. But, more importantly, I think the Scrum 201 gives you essential information that will take your Scrum to the next level.
Next: I just received today a request from a headhunter for a CSP person in Charlotte. A scrum-agile coach, and they want the person to be ‘good’, so they are asking for that person to have a CSP. Umm. Start of a trend, I think.
What is really important? Well, results. Real results for real people. What is next most important? The ability to regularly achieve results. (And, down the list, …does the person have a meaningful certification — and in the process of getting it, might have improved his abilities.)
Why is this important and what does it mean? Let’s consider the meaning first.
So, normally in Scrum estimates mean estimates of relative size/complexity in Story Points. See Mike Cohn’s book:
Each story (or at least any story in a Release Plan or Product Roadmap) needs a story point estimate. You can’t bring into Sprint Planning any stories without Story Points. No, no, no. (If the Story is discovered in Sprint Planning, that’s a bit different.)
And these estimates are created by the Team of implementors. Those who will do the real work.
Well, estimating my own work gives me much more motivation. And responsibility. And another reason to appreciate how my work interacts with the work of others. If the Story Points come from some other person or group, they don’t have the same feeling. The same impact.
Yes, there is a downside. Not every Team is equally good at estimating. Yes, it’s true. But we are convinced that the negatives are more than offset by the positives.
Usually, though, only the Team knows what they really can or can’t do very well. So, only the Team can do relative estimating.
Another key reason for this item on the test is how we will, later, use Story Points to know velocity. And how we will use velocity for many things, from which I will highlight three:
OK. That’s some commentary to start with. Now put your thoughts into action.
Jeffry Hesse wrote this blog post. And it inspired me to write the post below.
The new Scrum Guide says that PBIs (product backlog items) must be well-understood and granular enough (just before going into) for Sprint Planning. And that PB Refinement is the process we use to get them to Ready.
Those are not quotes, but that is how I read it. I think accurately.
Jeff Sutherland and I and others advocate the ‘ready, ready criteria’. Roman Pichler and others call it the Definition of Ready. I am ok with either phrase.
So, what is it?
Well, like the DOD (definition of done), it must be specific to each Team. Each Team must define one for themselves. And they vary some, depending on many factors.
We want the User Stories (or PBIs) to be more defined than they often are for some ‘agile’ teams. But this does not necessarily mean the voluminous documentation that many waterfall ‘teams’ have. (I put ‘team’ in quotes here because I never find that waterfall teams have anything close to the team feeling of agile teams, especially a good agile team. Nor the productivity.)
So, ‘ready’ is kind of a Goldilocks concept (like most things in life): not too little, not too much, just right. A balance. We definitely want to leave some room for the Team to be creative during the Sprint.
The ready, ready criteria are similar to the concept of GIGO. Garbage In, Garbage Out. Or rather, obviously, the opposite. We want ‘good stuff’ going into the Sprint, so that ‘good stuff’ can be completed at the end of the Sprint.
I conduct courses and workshops all the time, and I ask people: what do you want in your ‘ready, ready criteria’? The context is: Imagine we are having a short meeting about 1.5 days before the Sprint Planning Meeting. What are the things you want to review to be sure the ‘top items’ are ready, ready? And we assume a 2 week sprint, with about 8 small PBIs (stories) about to go into the next sprint. (Yes, I am making lots of assumptions that may not apply to you…)
Here are some of the things they say. This is a super-set. First, any list would not apply to ‘every’ user story you have. Second, for your specific team, you might make this list longer, shorter or just different. Suitable for your specific situation.
So, here are some of the things I recall them saying (that I agreed with):
This of course is more work if we have just identified a new story (which should happen sometimes in real life).
If a couple of stories get rejected, the PO has another day to ‘get his stuff together’ to get them ready for the SPM (sprint planning meeting).
This meeting is one of the two meeting I like to have to do Release Plan Refactoring. This one is short-term focused. The other is ‘long-term’ focused. These two meeting go together. We do not have one without the other. We plan longer-term so that Sprints go better. We do Sprints to fulfill the longer-term Vision. They go together.
This meeting (just before SPM) requires that the PO ‘get his stuff together’ beforehand. For example, the acceptance criteria should already have been defined, and the question is: does the Team think they work?
And not all that work is done by him (or her) alone. But the PO is responsible. It is expected that a few issues will be found. The POs work is expected to be good, but not perfect. (Again, it is not solely the POs work; many others could have contributed.)
We have the assumption that every day we are learning, and every day things can change. Both for the good and for the bad, and for the ‘bad’ (eg, maybe good for the customer, but harder for us as a Team to deliver). Hence, we have to have this meeting at the last responsible moment. (Cf. the Poppendiecks.) Just before the next sprint planning meeting, leaving some time for the PO to recover from some issues.
Are some of the issues or concerns above being addressed on other days during the Sprint? YES! By the PO. In some one-off quick meetings. In some pairings, maybe with business stakeholders. Etc. Etc. Etc. But this is the last time where the whole Team (together) reviews the stories about to go into the Sprint. It should be a fairly short meeting (about 1 hour).
Or, so I coach for most teams.
Are there other ways to do it? Surely. Are they more or less successful? I don’t really know — I have not tried all the million other ways. I see my teams having more success with my approach. But honestly I do not have double-blind independent studies. Do you?
Two points additional points:
The Team must be motivated to do this. And I would try to include some business stakeholders. By giving the Team the ‘thumbs up?’ vote, that tends to get their attention.
In a 2 week Sprint, I also like to do another meeting, in the first week, that addresses the Release Planning for the longer-term. That meeting is also typically about 1 hour. More on that later.
I hope you will give feedback. I hope you will try some of these ideas, and that they help you. And then give feedback again.
Here are the impediments that the Charlotte class identified:
Maybe these give you ideas about your Team.
Here are the top impediments identified by the recent Montreal class. There may be some things that are similar (a different person might be trying to say essentially the same thing, but for his team). Maybe your Team will recognize some good things to work on:
A couple of things that I noticed.
First, I asked them to identify the key root causes that lead to project failure. From their real experience.
Second, I asked “What are the biggest 1 or 2 impediments for your team now?” Sometimes that identified new things that came out with the first question.
Now, this can happen for many reasons. But one thing this tells me — if you ask the question a different way, you get different answers.
They hear it differently each of these ways:
You may mean the same thing, but they hear it differently. And respond differently.
Fix the most useful one thing first. Usually small incremental steps of improvement.
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.”
To me, they are not perfect, but they are an excellent expression of many of the key ideas behind Agile. And we should be thinking about them every day. They require thought and common sense to consider how they should be applied on a day-to-day basis. And explanation. Yes, I meant every day. In part because we humans so easily forget, and in part because the opposite ideas are also quite deeply embedded in us.
Now we come to something that I have not been discussing nearly as much. The Scrum Values. They are here. Rather than being ideas about how Scrum or Agile works, they are more guiding ethical ‘laws’. A bit more like the 10 commandments from Judaism.
I guess in theory Ken Schwaber, their author, wants you do follow these while you are doing Scrum. But really, as you read them, if you believe them, you should be doing them ‘all the time.’
Let’s list the key words: Commitment and Focus, Openness, Respect, and Courage.
To me, for most humans, they seem like great things to strive toward. And things about which I will always be making mistakes. If I am honest.
I encourage you, at least while you are doing Scrum, to consider them, and to try to follow them to the best of your ability. And to help your colleagues follow them.
To err is divine, to forgive human. So, encourage your colleagues to follow them. And don’t forget, also, to forgive yourself for your own failures.
Ken Schwaber, in a recent blog post here, compares the Scrum Values to the values (and also principles) articulated by Kent Beck, in his book Extreme Programming Explained. I definitely recommend Kent Beck’s book, and its chapters on Values and Principles.s