Scrum Commitment Drama
So you’ve figured out team capacity, you’ve planned your iteration, and the scrum master looks around and asks everyone if they are willing to commit to the iteration. What does he mean? Is he referring to how many days you’ll be available to work during the iteration? Or is he referring to something deeper….an emotional state or pledge of some kind? How do your colleagues understand commitment? How about management and the business owner? It probably depends on what company you are working for, but more deeply….the answers seem to come in two flavors:
- commitment to complete the stories and tasks within the iteration time frame.
- commitment to *try* and complete the stories and tasks within the iteration time frame, but you’ll probably need to move some to the next iteration.
This nuance can’t be understated. Those of you working on scrum software development projects know what I mean. Colleague A is a realist and thinks commitment is putting in 8-10 hours a day and making every attempt to complete the work knowing he has a family and other commitments. Colleague B sees Colleague A as a slacker. Colleague B is a driven visionary that regularly puts in 10 hours or more per day and is willing to do ‘whatever it takes’ to get the iteration complete. He manifests himself through his work. So who’s right about commitment?
Your heart might swing you one way or another as you gravitate to the view that most closely mirrors your circumstances. But the point of this article is to weigh both and hopefully find some commonality that mitigates the drama and machinations around ‘commitment’.
Why is this important?
Misunderstanding the nature of the commitment to the iteration is a source of team tension and a potential sinkhole to productivity. Does it have to be? Probably not, but before I go too far I’d like to point out that it’s not just Scrum and Agile iterative planning that have this dysfunction. Rather, agile methodologies, with their open culture and self organizing, bring to the front what is often tucked neatly in the corporate closet.
Commitment – How do you define it?
A good question. And like many good questions it should be asked up front….in the interview. No one wants to walk into a job and find the level of commitment asked is not what they are willing to give. That’s fair, but this presumes the scrum team knows the answer, they’ve defined what commitment means for them. How many scrum teams can say they’ve done that? If you’re like most….the team is polarized by the two views first mentioned with shades of gray in between. So how do we define commitment to an iteration? What are some options so that when we ask during an interview; we know what we’re looking for.
Mission from God
This level of commitment isn’t for the faint of heart. When you joined this scrum team you signed with your own blood. All stories in an iteration “HAVE* to be completed….the velocity is law. No exceptions. Commitment here is a spiritual, emotional exercise in discipline and belief in the product. Seem crazy? Maybe. But before you dismiss it; there are industries and situations in which this completely makes sense. Some examples:
You’re at the absolute dark bleeding edge and trying to keep your technological advantage.
You’ve created a startup and money is not exactly flowing like water. To keep you’re funding you must deliver.
Heavy competition is driving the need to be first to market.
That’s the culture…..”it’s what we do.”
The drawbacks to this mode are known, but worth stating: burnout, setting up expectations you can’t sustain, and a work intensity that excludes many good candidates.
Time Bound
A less demanding road to commitment is the time bound agreement. It might work like this: We as a team agree to work between 40 and 50 hours a week and believe the stories in this iteration represent that time. For those who come from the “mission from god” shop this would be called a ‘union mentality’. However, it does have it’s place, and gives those with families, friends, and hobbies a chance to hang on to those commitments as well.
This team will ideally try to achieve their velocity each iteration, but has an open gate to move stories to next iteration if the team has met their time commitment. The drawbacks: Commitment in time, space is achieved, but not in spirit. Do those hours include lunch or not? What about smoke breaks? It gets nettlesome when you start counting the clock.
Stair Step
A more proactive response to managing your velocity and defining commitment is using a stair step model. It works like this:
- Team velocity is 40 story points.
- Iteration 1 the team commits to 35 story points. An easy iteration for them.
- Iteration 2 the team commits to 45 story points. Not easy, not hard.
- Iteration 3 the team commits to 55 story points. This is a stretch. They might make it ; they might not.
- Iteration 4 the go back to committing to 35 and repeat the stair step again.
This allows the team to proactively engage and manage their iterations; segmenting them into simple jogs, brisk runs, and marathons. The team then knows upfront that which iteration will be a tax on their personal life and whihc one will give them more freedom. Drawbacks: it sounds ideal but you’ll likely have folks find excuses to be ‘out of the office’ during the marathon iteration.
Grouping
This concept works well if you have multiple scrum teams. Here’s the scoop:
1. Team A’s velocity is 40 story points and their commitment is ‘Mission from god’.
2. Team B’s velocity is 28 story points and their commitment is ‘Stair Step’
3.Team C’s velocity is 20 story points and their commitment is ’40-45 hours a week’.
The advantages are obvious: new employees can fit into the organization regardless of their personal commitment levels, a tiered or group approach allows a team member to try on different levels of commitment, and those of like mind get to work together.
Drawbacks: requires a big software development project(s) and budget, competition/hostility might erupt between teams, and poor performers may gravitate to one team…giving that commitment level a bad name.
Leveling
Leveling is stair stepping by individuals. Team member A might put in a hard iteration this time. Team member B might put in an average effort. Team member C gets it easy this iteration. Next iteration they rotate roles.
Making the Decision
This is only a partial list of ways to address the commitment conundrum. Whatever choice is made; it won’t be perfect. Poor performers and top tier talent routinely clash. Objectively defining commitment is only half the battle. The other half is getting the team to follow through on that commitment. This comes down to solid leadership skills from your scrum master and others. A framework needs to be enforced if it is going to be effective, trusted and used by the team.
However, getting to an agreed commitment level is essential if you want your velocity to represent the optimized potential of your team.
Summary
Ultimately the scrum team’s goal should be to produce on a rate that is consistent with their potential. Making certain everyone understands and agrees to the commitment level up front removes a blocker before it manifests itself. Some may read this article and say, “Commitment is a function of story points. You let your team run a few iterations and gauge the average number of story points they can complete. That gives you your velocity…which forms the basis for your commitment.” There are two problems with this: the foot dragging team that ‘games’ the system and sets its velocity well below what it could do, and the perception of effort from those who are paying for the project.
In the first instance the team is composed of individuals who are less than honest for one reason or another. It is hard to know this up front, but if left unchecked your project will suffer financially and materially. Setting the tone and agreement up front takes away the possibility of misunderstanding the nature of the commitment and gives you a more solid understanding of how the velocity came to be.
In the second instance ,while the project may get done at a velocity level that is lower than what the team could achieve, the risk is that the product owner will feel they’ve been taken for a ride, and “this agile thing is a way for developers to goof off.” If your velocity is 40 story points but the team seems capable of taking a 2 hour lunch twice a week and doesn’t show up till 9am and leaves by 4pm; the commitment is going to be questioned. Dangerous? You bet. The options for fixing such a scenario are dire. So, to mitigate such a risk up front it behooves the scrum master to set and agree to a commitment level up front; making sure the product owner is in agreement.
Finally, human motivation and desire to do any task is not strictly limited to working agreements. If after agreeing on your commitment level; the scrum team still is not performing well then further investigation is warranted. An agreed commitment level puts lines and boundaries on the playing field; but your team’s willingness to win will be an alchemy of many variables.
Pragilematic 
Pingback: Can Agile Work in Big Organizations? « An Agile Story
Pingback: Predictive *AND* Adaptive Planning | An _____ Story