For whom was the sticker made?

A couple of days ago, as I was grabbing my bag out of the overhead compartment on the quite small plane I had taken between Newark and Raleigh/Durham, I noticed a sticker in the back of the compartment. Most planes I have flown with were bigger and I’m just not tall enough to see that far in so I don’t know if the sticker is always there but in this plane it was at least. The picture I managed to take is quite blurry but what it says is: “MAX. CAPACITY 60 LBS/27 KG”.

Great, they don’t want the compartment to fall down on the head of some poor schmuck sitting under it.

I don’t know what’s wrong with me but I immediately wondered why they put that sticker there. What is the difference between having that sticker and not having that sticker?

Let’s pretend you’re a passenger and you are the first one to put something in the overhead compartment and you actually manage to see the sticker. What goes through your mind? Probably nothing much. Most of us have a bag that weighs less than 10kg but that doesn’t really matter because we don’t know what it weighs anyway. So you put your bag up there. Next person comes along. If she can still se the sticker after you’ve put your bag in there, what will she think? Probably that her bag is lighter than the limit. She has no idea how much your bag weighs and she most certainly won’t take it out and try to estimate the combined weight so she puts her bag in there as well. If there’s still any room up there, no one will see the sticker because of the bags and jackets already there and they’ll keep loading their bags.

Let’s pretend that the airplane manufacturer put the sticker there because they were concerned for the safety of the passengers. Jerry Weinberg uses the expression that you should eat your own dog food, meaning that you should try your own products for yourself before exposing them to your customers. If the manufacturer had actually tried to board the plane and recorded how the sticker changed their behavior they would probably have come up with zero.

But what if the sticker wasn’t even the manufacturer’s idea. What if it is some government agency that is looking out for us, the passengers? Did they make a rule that says that the manufacturer must make sure that no one gets an overhead compartment in their head? Did they express it in such a way that no one will get an overhead compartment in their head? They might have said that the manufacturer is liable for informing the passengers about the maximum load. But they certainly did not say that the manufacturer is liable for making sure no one gets hurt. Because if they did, that sticker would not have been there.

Now I don’t know who decided that there should be a sticker there and for whom it was made and
Therefore, I send to know
for whom the sticker was made,
it wasn’t for me.

Enough of paraphrasing John Donne and back to the game. If the purpose of the sticker truly is to save people from getting an overhead compartment in the head and not just a way of keeping the manufacturer out of court when someone has been hurt, then I consider it to be an example of poor problem solving and I’m more interested in good problem solving so I’m asking you, dear reader:

What would you have done to prevent people from overloading the overhead compartment?

Explicit Expectations Exercise

Assumptions is the mother of all … flurps.

I would say that the majority of our failures in cooperation and  collaboration arae due to assumptions. We also fail largely due to poor or lacking communication but this is based on an assumption that we don’t need to communicate in order to succeed.

I’ve seen so many problems arising from people making assumptions about other people. We prefix a lot of our statements with “I think that … ” or “I believe that …” and yet we continue acting based on the statement that follows. What is up with that? Shouldn’t the words “I believe …” raise a warning flag so red that it would have brought a tear to Karl Marx’s eyes?
My suggestion is that whenever you hear yourself or someone else utter words to that meaning, you should challenge yourself or the other person to validate the assumption.
I use those words all the time and I want someone to challenge me since that will provide me with great opportunities for learning.

When it comes to teamwork, I find that a lot of assumptions take the form of implicit expectations. We expect people around us to behave in certain ways and we assume that they know this and that they will act accordingly. This is a breeding ground for bad feelings and even less communication because we often attribute peoples failure to live up to our expectations to spite on their part. In an attempt to lessen the frequency and impact of these hidden assumptions I’m designing an exercise to help make our expectations more explicit. I’ve only run it a couple of times so far and have updated the format every time and I welcome any and all suggestions for improvement that you might have but I will describe the exercise as I plan to run it the next time.

Part 1:
I begin the exercise by creating columns on a whiteboard, headed by the different roles in the project; project manager, product owner, ScrumMaster, developer, tester etc. I’m aware that Scrum only prescribes three roles but the goal of this exercise is to make things explicit, not wishful thinking. I also ask a representative for each role to act as secretary for the second part of the exercise. I then hand out pens and Post-It notes to everyone present (all roles from the columns need to be present for the exercise to be meaningful). Then everyone gets to write down their expectations on the different roles on the Post-It’s, and post them in the column for the role they have expectations on, as they write them. The expectations are written on a format similar to user stories;
“As a ‘role‘ I expect ‘another role‘ to ‘fulfill some expectation‘ so that ‘some benefit will occur‘.”
I might for example post the following expectaion in the Product Owner-column:
“As a ScrumMaster I expect the Product Owner to be available for the team members at all times during the sprint to answer their questions about requirements so that they don’t have to guess what the customer needs.”
I give this part about 10-15 minutes or stop it when no more notes are being produced. People usually need some time to think during this exercise and they tend to write during the time available.

Part 2:
Then I go through role by role and note by note, asking for clarifications if needed, and also asking the representative(s) for the role if they intend to live up to the expectation on the note. I will ask the secretary to take additional notes from the discussion. Usually people want to live up to the expectations but not without clarifying what is meant;
“What do you mean by ‘at all times’?” and “What do you mean by ‘available’?“.
Sometimes the expectations are off, it can be a project manager expecting team members from a Scrum team to report progress to him or a developer expecting a product owner to add every technical story they can come up with to the backlog. The discussion around these expectations is really important because it will clarify and set boundaries. It will validate or invalidate assumptions. I have found that for a group of 15-20 persons this part of the exercise will take about one hour if it is heavily moderated. Make sure that you have enough time for this discussion because this is an investment that will pay for itself.

Part 3:
After the exercise I ask the secretaries to take home and rewrite the accepted expectations as a contract, with any clarifying notes from the discussion added. The expectations should be turned around and rephrased as commitments.
For example:
“As a Product Owner I commit to be available, at least by mail and phone, five days a week for the team members, to answer their questions about requirements so they don’t have to guess what the customer needs.”.
The contracts are then to be signed or at least acknowledged by everyone representing the role.

The main goal of the exercise is not to produce contracts but to bring out as many assumptions and expectations as possible into the light. The contracts are just reminders about the exercise and a way of repeating what was agreed upon one more time after everyone has had a chance to digest the exercise.

This exercise can be done as an activity at the beginning of a project as well as later on if you experience communication issues in your project and suspect that they might stem from hidden assumptions. If you run this exercise, please share your learnings here so I can continue to improve it.

You can’t stop people or yourself entirely from making assumptions but you can tell other’s about yours and you can as them about theirs.

MoSCoW Prioritization Poker

Today it felt like I had one of my brighter moments. Sitting at my new client, faced with a backlog way too long to implement in the time available to us, I had an epiphany. We needed to prioritize the backlog and get a first shot at a release plan in a two-hour meeting.
“How about prioritization poker?” The words jumped out of my mouth before I had even considered what they meant.

Let’s jump ahead a couple of hours now. “My” idea about prioritization poker would most certainly be worthy of a blog post so I started writing it in my head on the subway back home. Then another thought hit me, almost as hard as the one earlier today; wait, this was too obvious, I might not be the first one coming up with this idea. And sure enough, some googling told me that this guy called Mike Cohn had already invented prioritization poker. C’mon Mike, you already have so many other things going for you, couldn’t you’ve let me have this one? Anyway, so what if my idea wasn’t unique? I think we had a little different twist on it and it proved to be quite useful and thus I’m still going to write this post.

Back up a couple of hours again.
“Prioritization poker? What is that?” My colleagues gave me weird looks.
The words kept pouring out of my mouth faster than my brain worked; “I guess it’s like planning poker but you do it with MoSCoW instead of numbers or t-shirt sizes. Do you want to try it?”
“Sure. I have a planning poker deck in my bag.” One of my colleagues replied.

So we picked out the 0, 1, 2 and 3’s from the deck.
“0 is Won’t, 1 is Could, 2 is Should and 3 is Must. Kay-O?”

Our product owner read the first story out loud and we began asking for clarifications. After a couple of minutes it was time to play our cards. We had 1 and 2 and 3. Certainly a difference of opinion. After a short discussion where the extremes put their views forward we played another round. All 3’s! On to the next story.

After one and a half hours we had gone through the entire backlog and managed to divide it into almost equal chunks of Musts, Shoulds, Coulds and Won’ts. The remaining half hour of the meeting was spent putting all Musts into the first version of a release plan.

Wow! I’m very familiar with the power of planning poker but this was a new experience for me. Using the poker format brought our assumptions out to be examined and corrected when necessary. We managed to align our views on what needs to be done and to get a common understanding of the requirements. Whenever I felt safe about understanding a requirement someone challenged my view by questioning the meaning of a certain phrase or a specific word. This kept happening until we narrowed the description down to something everyone could agree upon.

Using MoSCoW for the prioritization also proved to be a good idea. At first I thought I had made a mistake by not including the “?”-card in the game. Some of the requirements didn’t make any sense to me and I had no idea what prio to give them. Then I realized the power of the values in MoSCoW. When we got to the first story that I was clueless on, I thought about digging out a question mark from the poker deck on the table. But then my wheels started spinning again and I gave it a 0 … a big “Shazbot! We’re not doing this.”
The others who considered the requirement a Should or a Must looked at me like I was crazy again.
“No, we’re not doing this requirement until someone can sell it to me.” I said.
And they began explaining the importance of the requirement until I understood it and could agree on its’ importance.

This exercise also showed me how important it is to force people to take a stand. There’s a huge difference between prioritizing in a continuous range from 1 to four, or from low to high and if you’re using a scale that includes “Won’t”. If you give something “low” priority or a 1 on an importance scale, people are still left with some hope that the requirement might be implemented and they will with great certainty be disappointed when they realize that it’s not happening. If, on the other hand, you tell them that the requirement is a “Won’t”, you’re effectively telling them that this is not going to happen unless they manage to get it reprioritized. People are forced to come to terms with reality a lot sooner or to take responsibility for making an alternative reality happen.

This was my first experience with prioritization poker and it was a good one. It proved to be a great tool for our context today and I’m pretty sure that I will use it, or some modified version of it again.

Na-Nu Na-Nu!

Making Decisions Tentative

Decisions, sometimes hard to make, but we do need to make them and we do need to live the consequences of them. Some decisions can be changed along the way and some are irreversible but almost all of them are made without full knowledge about the problem. Waiting for full knowledge would leave us stuck in limbo though, because we will never gain it.

When we make a decision, no matter if it’s irreversible or not, we should not make it final. We need to leave a backdoor open for learning to enter. Making a decision final is when we invest so much prestige into it that we’ll stick by it even when we know better, or when we refuse to accept better knowledge even to ourselves.

We need to keep making our decisions and to keep standing by them as the best we could do at the moment, but we should make them tentative in the sense that we’re willing to learn and admit that we’d do it differently the next time around when we’ve gained new insights.

Throw Out Quality – And Tell Me What You Really Want

In an open space session a couple of days ago, a colleague of mine said that we’re using the word quality a bit carelessly. I’d like to go one step further and say that it is a careless word. It is a careless, sloppy, non-specific word that leads to careless decisions and sloppy measurements, and I want to take it out back and put it to sleep.

We have pondered the question of what quality is for years and years. A number of smart people have come up with several good definitions of quality such as:

• Fitness for use
• Meeting and exceeding customer expectations
• Satisfied stakeholders
• etc …

These are all fine but they’re not very precise. Quality seems to be almost synonymous with “good”.
“Yes, I’m with the good assurance department. We make sure that the level of good in the product is at an acceptable level.”

Of course we want to make sure that our product is fit for use and satisfies our stakeholders but that won’t happen unless we become more explicit. What happens though when we use such a sloppy word is that management gets a non- or at least ill-defined parameter to negotiate with and to measure.
“At this point we must let costs take priority over good.”
“How is the good coming along in our product?”
“What KPIs do we have for measuring good in our product?”

I’m sorry, but I won’t answer one more question regarding quality from now on. You will have to be a lot more specific if you want to know how good the product is. If you want to know about usability, you will have to ask me about usability. If you want to know about maintainability, you will have to ask me about maintainability. If you want to know about errors in programming, you will have to ask me about errors in programming. I will probably keep probing even more about what you want to know and why you want to know it, but if you ask me about quality again, my answer will be … 42.

“So tell me what you want, what you really really want” – Spice Girls

It’s 42! What did you want to know?

- It’s 42 boss.
- …
- Yes boss, that’s higher than the 5 bugs we had a couple of sprints back.
- …
- No boss, that was the sprint when we spent the majority of the effort implementing the configurable splash screen and the easter egg TicTacToe-game. The features that you predicted would triple our sales.
- …
- Yes boss, it is also lower than the 50 bugs we had last sprint.
- …
- Yes boss, last sprint. You know, the one when you hade us work overtime every second day in order to fulfill our customer’s demands of removing the configurable splash screen and the easter egg TicTacToe-game. Remember how they said that the features lowered the productivity for their employees?
- …
- No boss, it’s still 42 this sprint. However, we’re only on week three of our two week sprint that you’ve prolonged to four weeks in order to fit some extra functionality in. So I guess the number might still go up.
- …
- Boss, I think I’m actually beginning to see the value in counting bugs. These numbers seem to have a strong correlation to the decisions you’ve made. We can probably learn a lot from them.
- …
- What the hell was it you wanted to know boss?
- …

There’s an old saying that a lazy programmer is a good programmer. I’ve never heard an old saying about a lazy manager being a good manager but yet there are all too many of them out there.  Not the good kind of lazy manager who is willing to delegate work and to let people do what they’re good at without micromanagement. No, we get the other kind of lazy manager – the Panacea Manager – who is constantly looking for a shortcut.

The Panacea Manager will measure the organization on what he can count on his fingers and toes because words bore him, unless of course they’re his own. The Panacea Manager will ask for bug count, lines of code, number of test cases etc.

What do you think the Panacea Manager will receive when asking for these numbers?
Is it hard for a developer to produce a lot of code if that is what she is being measured on?
Is it hard for a tester to produce a lot of test cases if that is what he is being measured on?
Will the number of bugs found tell you anything about the quality of the software after they’ve been corrected?

Do our customers care about the bug count or LOC or number of test cases? I don’t think so. Bug count and most other numbers that we collect are just proxy variables for quality as we think our customers perceive it. Measuring quality and productivity via proxy variables might very well result in quite the opposite of what we’re trying to achieve.

How about if the Panacea Manager took a long look at the system he has built or inherited and started making deliberate decisions based on how he actually wanted the system to work? What if he stopped measuring bug count and lines of code and began asking the customers for what really matters to them? Would it make his job harder if he tried to compare customer satisfaction over time instead of employee hours spent in the work place? It probably would to some degree but it would also mean that he actually began doing his job.

So what should we measure then? I’ve learnt that many people itch to ask that question after listening to my arguments. Please don’t! That means I’ve failed at getting my point across and I’ll loose even more hair on my head. Begin with asking yourself; what decision do I want to make and what do I need to know in order to make that a good decision? THAT is what you should measure.

You are always in the blind spot – Let the coach expand your field of vision

As a leader – or team member as well for that matter, you are faced with a big problem every time you try to implement some sort of a change in your organization.
No, that’s not true. You face a lot of big problems, but one of the bigger ones is … you.

You are trying to interfere with a system without being able to see the entire system. You need to get a helicopter view of the landscape while at the same time being grounded as an important part of the very same landscape.

Most of us don’t understand how much we affect a system that we are a part of, and more importantly; we don’t understand in what ways we affect that system.
Our presence in a meeting can set the entire tone of it without us doing anything in particular. Likewise, we can also affect the outcome of a meeting just by being absent from it.

How do we interact with our systems? What messages do we send to them? Do you have a total coherence between your thoughts, your words and your actions? If not, what parts of your intentions and your communication are getting across? Vice versa; what parts of your coworkers’ true intentions get across to you.
How can we possibly know how a system will react to a particular change if we can’t see the entire system?

Being a lean/agile coach, I’d like to suggest that you get yourself a new set of eyes and ears. As a leader or team member, it’s your duty to be a part of the landscape. You must be the intricate part of the machinery that you are. I, as a coach on the other hand can reserve the right to stay outside your particular system. I can put my stethoscope to the heart of your organization and listen without the distorting filters of preconceptions and interfering echoes of my own actions.
(… at least for a while. Sooner or later we all get biased.)

There are also tools like the left hand column exercise and Virginia Satir’s interaction model that can help us learn to see how our own behaviors affect those around us. If we accept the help and take the time to study ourselves, we can begin to move out of our own blind spots and get our helicopters in the air.

Quality – It will only sting for a second

You all know that stress is just a killer to quality, don’t you? I think all of us know this at some level but we often act as if it wasn’t so. I’d like to share a story about how this became painfully apparent to me today.

To follow up on a recent kidney stone, I needed to take a blood test. I figured I could do this during my lunch break today so I walked down to a medical clinic quite close to work. I had barely sat down before a nurse in her mid 120’s (let’s call her Nurse Singer in tribute to Mr Isaac Merritt Singer) called me in. It was obvious that this lady had been in this line of work for a very long time, which actually made me feel kind of relieved. Younger nurses often have a tendency to wuss around a bit more and unnecessarily prolong the process and since I had a lunch meeting to attend to in just a couple of minutes, this suited me just fine.

We went through the usual procedure with me spelling out my name and social security number while she prepared the needle and tubes. I then rolled up the sleeve on my right arm and she tightened a rubber band around it. After some poking around she seemed to have found a good enough vein and stuck the needle into it. First tube went just fine but mid second tube my lunch date called on my cell to find out where I was. This must have made the nurse jump enough to move the needle out of place because the tube stopped filling up. She tried to find the vein again by moving the needle around but to no avail. I asked her if she wanted to try again with my other arm. She accepted my offer and tied the rubber band around my left arm instead. This time she had some obvious problems finding a good vein and decided to go for a smaller one. After bringing out a thinner needle she once again stung me. This one was a duster to begin with. She pushed and pulled the needle a couple of times but no blood was coming out.

Nurse Singer was becoming apparently nervous now and offered me a stream of apologies. I told her that it wasn’t any problem, to just relax and give it another shot. So she pulled out a fresh needle and went back to my right arm. After a lot of poking this time she decided that she had found the vein to hit. Needle went in and … no blood this time either. More excuses and this time she told me that this wasn’t really working out for her so she would go and fetch a colleague instead (let’s call her colleague Nurse Nightingale). She came back after a minute telling me that Nurse Nightingale had just started on a new patient and that I would have to wait for a while. Already late for my lunch date I was getting a bit stressed as well so I asked Nurse Singer if she didn’t want to give it another shot. After some hesitation she picked up a new needle and went back to my left arm. Well, to make a short story even shorter; it was another barren well.

This time we both agreed that waiting for her Nurse Nightingale would be the only sensible thing to do. Five minutes later I was seated in another room, Nurse Nightingale (another contemporary of Lucy) calmly poked my left arm a couple of times with her index finger, pushed a needle into it and swiftly filled two more tubes with my blood.

Now I’m convinced that, in spite of her turning me into a Swiss cheese, Nurse Singer is probably a very competent nurse who just happened to end up in a stressful situation. She made a small mistake and then noticed that I was in a hurry. Trying to rush things she only managed to lower the quality of her work even more and thus created a need for more rework. In software projects this happens all the time. As deadlines approach, we get stressed (or get stress put unto us) and we begin to make poor decisions. We take shortcuts and we skip good practices to save time. We might not perforate our clients but we do harm to them by wasting their money on low quality products. So the next time you start to feel stress coming over you, remember the old proverb that “haste makes waste”. Take a couple of minutes to calm down and become the Nightingale your clients need.

Rotting Estimates

Have you ever been part of a late project where you constantly update your estimates and plans but they continuously get worse instead of improving? Where you finally get to the point where your estimates get out of synch during the time you fetch a cup of coffee?

No? Then I congratulate you because it’s an extremely demoralizing and costly situation.

Yes? Then this post might be able to provide some insights to the dynamics at play.

The model

A colleague of mine just recently presented me with the generic project model built on the work of Pugh Roberts in the early 70’s.

The model is very simple but it gives a good starting point for discussing the recurring dynamics in projects. We pull work from our “Work to Do” box and implement it, either correctly or incorrectly. Work done correctly goes into our “Work Done” box while work done incorrectly goes into our box of “Undiscovered Rework”. Note that this has nothing to do with our physical deliveries, both work done correctly and work done incorrectly will move along the same physical path since we haven’t been able to distinguish the two from each other yet. When we do discover the need for rework we will assess the problems and move them back into our backlog of “Work to Do” again.

What is “Undiscovered Rework”?

In this post I will mainly focus on the “Undiscovered Rework” box. This is our backlog of work that we think we have completed but that will not be accepted as it is. Some of the rework will be discovered when we implement new functionality, some will be found during testing and yet some will be discovered by our end users in production. Anything we produce where the quality is unknown carries the potential to end up in this box.

The sources of “Undiscovered Rework”

The amount of work in  “Undiscovered Rework” tends to grow quite fast as a project goes along. A couple of factors that speed this growth up are:

• Not having a good definition of done
• Postponing testing until the end of the project

Both of these factors hide the true quality of our product and allow for different kinds of errors to pile without us knowing it. If our feedback loops for determining the quality of our product are too long or if they are missing entirely, there is really no limit to how much waste we can add to this future todo-list.

The implications

The big problem with “Undiscovered Rework” is that it hides the true progress of our project. It hides our status because we do not know how much work is actually done and we do not know how much work is actually left to do. It also corrupts our view of the rate at which we make progress.

Normally when working in an agile project where we use our velocity to predict future deliveries, our estimates narrow in and get better and better as we gather data over the sprints but this only holds true if we don’t let our hidden backlog grow. If we do not know the true quality of our product, the only thing our velocity tells us is at what rate we can produce crap. If we allow the amount of “Undiscovered Rework” to grow, our estimates will keep deteriorating over time.

An example

Let’s imagine we’re in a project where a serious amount of the testing is done at the end of the project. We begin this project with 15 user stories in our backlog and find that according to our velocity we can implement three user stories each sprint.

The thing is that one third of this work ends up in the “Undiscovered Rework” box. We move into our next sprint believing that we have finished requirements A, B and C and that we will be able to do requirements E, F and G during the next couple of weeks. The problem is that stories C and G will need to be redone completely later on (I’ve simplified the example by gathering all errors in one user story here).

After going for four iterations believing that we have a velocity of three, we look at the last three remaining items in our backlog and think that we are one iteration away from our goal. But testing will show that we actually have four more stories to complete from our previous sprints. So we actually have seven (!) stories to implement.

We are not talking about one more sprint anymore. That is more like two and half sprints. But wait a minute, our true velocity was not three stories per sprint, we actually only managed to produce two stories of good enough quality per sprint so that means that our seven remaining stories actually will take three and a half sprints to complete. Now we’ve gone from being almost done, to being halfway done.

The insights about the remaining work in the previous example will not happen all at once. They will usually dawn on us one at a time and without us being able to see the connections. The symptoms that management and we will see are that work suddenly begins to slow down. So we begin to re-estimate our work when the first bug reports come in. During our first re-estimates we probably still believe that our velocity is three stories per sprint and we will just add some time for the bugs that have been found so far. Then as we move closer to testing and get faster response on our fixes our true velocity will begin to show and we will need to re-estimate again. What often happens at this point is that pressure from management will force people to take shortcuts so the rework becomes fixes and the fixes becomes workarounds and these workarounds will create new problems for us. Stress generally forces people to make bad decisions that will put the project even more in a pickle. If we are totally out of luck, management will fall back into old command and control ways of thinking at this point and force the project to go from pull to push while beginning to micro-manage people and thus slowing down progress even more. Now there is really no saying how long this project will take anymore.

Conclusion

Good estimation is about always being correct but adding precision as we learn more.

Most projects start out with a well-defined status (i.e. nothing has been done) and they stand a fair chance of making a somewhat decent initial estimate. Nurturing this estimate by collecting data while at the same time assuring quality will help bring precision to it. But if we allow for quality to be an unknown and still fool ourselves into believing that our data gathering will add precision to our estimates, then we are heading for a crash. The false sense of knowing where we stand will only make further estimates more and more off for every new data point gathered.

Turning this knowledge around though, you can use it as a canary in our project. If you experience that your estimates begin to get worse over time instead of improving, it might be a sign that your project has some serious quality issues.

Scrum Commitment – A Contract in Blood?

There are probably as many ways to look at Scrum commitments as there are teams doing Scrum but I think that I have seen a couple of patterns emerge that I’d like to share with you.

The Galley Slaves

The first team I’d like you to meet is called the Galley Slaves. When we first meet the Galley Slaves they are in the middle of sprint planning.

PO: This is our prioritized backlog. I’d like to remind you all that we’re way behind for the next milestone so I want you to commit to as much as possible this sprint. We have to get the top 18 user stories into the sprint or we’ll never make it.

Team: But that adds up to 65 story points and we’ve only managed 45 during our last two sprints.

PO: Yes, but remember that Peter was home sick for three days last sprint and John had to stay home with his kids for two days the sprint before that. You should be able to make it. This is no time to under-commit.

Team: Okay. We will commit to the top 18 stories then.

So in this situation we have a PO or PM that’s pushing the team to take in more work than they should. This is not the first time it’s happening so the team has a history of missing their previous “commitments” and have a disadvantage when trying to convince the PO that they should do even less. The team might even feel bad about not meeting their previous commitments and have some delusion about being able to catch up.

Next time we meet the Galley Slaves is mid-sprint.

Team: It seems like Peter came back from sick leave a bit premature. He had to go back home again right after sprint planning. It also looks like John caught the same thing because we haven’t seen him since then either. We will never be able to finish all of this on time.

PO: But you made a commitment to these stories …  I’ve communicated that you would do this to upper management. It looks like you’ll have to work this weekend now.

At this point we get to see even more push from above. The team has made a promise and other people will get into trouble if they don’t meet it.

But who did actually make the commitment? Usually in cases like this, one part of the organization has made promises to another part of the organization and now people whose butts are on the line try to shift the blame further down the organization.

The Flagellants

The second team I’d like you to meet are called the Flagellants. The flagellants were a medieval brotherhood that thought they could scourge themselves to absolution. In 1417 the church banned the flagellant movement but they are still very much alive in modern-day corporations.

Let’s see how sprint planning goes for the Flagellants.

PO: This is our prioritized backlog. I’d like for you to pick from the top the stories that you think you’ll be able to finish during this sprint.

Team: Okay, we’ll have to bring in at least the top 18 stories if we’re going to make the next milestone in two sprints.

PO: That will be 65 story points and you’ve only managed to deliver 45 points per sprint the last two sprints. Do you really think you can make this?

Team: If we are to get everything into the next release, we will have to go for it. So we will commit to these 18 stories.

This team obviously feels a strong responsibility for the entire product. As with the Galley Slaves, the Flagellants have a history of not meeting their commitments and they really want to make up for it. Every time.

Now we meet the Flagellants mid-sprint.

PO: So, how’s your commitment coming along? Your burndown chart has been flatlining for three days now and it was quite flat even before that.

Team: Yeah, but we’re on top of that. Peter has cancelled his vacation and we’ve all decided to work Saturday as well so we will catch up. You know we had some database problems at the beginning of the sprint but it looks like we will be able to solve those now.

This team if full of optimists, no doubt about that. They always believe that the last hurdle has been passed and everything will be downhill from now. They also make a commitment at the wrong level. A sprint level commitment can be contained and controlled to quite a large extent by the team but any promises made by the organization on release- or product level are outside of the team’s control.

Team Alfa

Finally I’d like to present you with team Alfa. These are my favorites. Let’s watch their sprint planning.

PO: This is our prioritized backlog. I’d like for you to pick from the top the stories that you think you’ll be able to finish during this sprint.

Team: We have picked these 12 stories. They correspond to our velocity during the last three sprints and we feel confident that we will be able to finish them. This is our commitment and we will do our best to deliver these stories during the upcoming sprint.

This looks healthy to me. The team is looking at their history and they make a commitment that is both feasible from a historic perspective and it is a commitment that they actually believe in themselves.

But alas, even team Alfa can run into troubles. Let’s listen in on them mid-sprint.

Team: Unfortunately we’ve fallen behind since this one story called for changes in a database outside of our control. We didn’t see that one coming. We have tried to work around the problem; Peter stayed here until eight o’clock last night but this will take quite some time to handle. We don’t think that we’ll be able to do the last two of the stories that we initially committed to anymore.

PO: Okay. Let me take the last two stories back to the backlog and re-plan them for the next sprint. In the meantime you do your best on the rest. Does that sound like a plan?

We will always make estimates that don’t come true. There will always be unforeseen events happening. What we need to do is to accept this as a fact and adjust our game to the reality.

Conclusion

What will happen to teams like the Galley Slaves and the Flagellants in the long run?

• We will get quality issues. When we start looking at commitments as truly fixed, our sprints become miniature projects with fixed time, fixed resources and fixed scope. The only dimension left for the teams to compromise with is quality.
• Disappointments. The teams will get disappointed in themselves for not meeting their commitments and they will lose credibility towards the rest of the organization.
• Burnout. No one is able to handle this much negative pressure and overtime in the long run. The Flagellants are in the worst positions since they really don’t have anyone to complain to.

The reasons that we ask for commitments are that we want to be able to look into the future for planning purposes and because it gives the team a good intermediary goal to work towards. That is; prognosis to see what will be ready when and the motivational factor from having clear expectations set by oneself.

What we need to remember about these commitments is that they are still based on estimates and estimates come with a confidence level. We need to inspect and adapt even within the sprints.

Everyone is entitled to their view on what a commitment are but there are two parts of the agile manifesto that (in my eyes) trump any personal interpretations of the term commitment:

“Responding to change over following a plan.”

And

“Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”