One of the most attractive aspects of agile is its ability to allow you to change a teams direction when a business needs change. However there can be confusion about when it’s appropriate to change a teams direction. In this post I will attempt to discuss the iteration social contract, what threatens it, and how to work through those threats.
Different agile implementations handle direction changes differently. Scrum uses a straightforward rule: after a sprint starts, no new work is added. Period. When a team completes all of their story cards they get to drink martinis on the beach until their next sprint. In some extreme programming approaches after an iteration is started no new work is assigned, however there may be “pull aheads” which developers can grab and work on after completing their scheduled work. Bonus points, hugs, and gold stars may be distributed as well.
One common theme is that in no agile implementation is it appropriate to simply remove items and add new ones in the middle of an iteration. To some this may seem counter to the principles of adapting to change over following a plan, however I disagree. Why? People who do not know what they are committed to doing cannot be expected to do it! The start of an iteration is a social contract that says “Yes. I understand these things and will do them by the end of the iteration.” The team commits to doing the work on the board while the company commits to letting themdo it.
If the social contract breaks down your teams productivity sinks with it. Team members don’t know what is expected of them, wheel spinning occurs, firm commitments cannot be made, progress slows down and time frames for long term objectives slip further and further into the future.
No one wants that. Right?
If the results are so bad, then why would we break the contract? There are three things I have noticed that make it difficult to keep the iteration social contract: Estimation Complications, Service Outage Surprises, and Unexpected Extra Work.
Estimation Complications
This is when a team thinks a story card is going to be of very little effort, but in reality it is requires much more effort. Perhaps some story cards were not well defined enough to be estimated or maybe the team didn’t know enough about the technology to make an informed decision about difficulty. Either way the result is the same: it takes significantly more time for the team to accomplish the card than they initially thought.
Again, different agile methodologies handle this differently. In Scrum, the team is expected to pull extra hours or do whatever it takes to complete their cards. At Menlo Innovations, a primarily XP shop, pairs are required to immediately notify their project manager as soon as they believe an estimate is wrong. This allows priorities to be reorganized in light of increased cost.
Both of these have advantages as well as drawbacks. In Scrum teams appear to be punished for not knowing how much work they really can accomplish. Yes, the features that were agreed upon got done, but it can make teams more timid about pushing their limits in the future. At Menlo the team doesn’t have to work extra over time, but the project plan will have to either push back the project timeline, decrease features, or increase personnel.
Service Outage Surprises
This one is a doozy, and seems to be prevalent in companies with high levels of technical debt or low staffing. Imagine this: your product or service has a defect that prevents it from providing the level of quality that your customers expect. Immediate action must be taken to rectify this issue. In order to rectify the issue the iteration contract must be ripped up and thrown out the window.
In Scrum the product owner cancels the sprint, has the team fix the problem, performs a retrospective, and starts a new sprint. The way my company is handling it is to write up a story card, pull off story cards we had committed to, and place the new “Fix the problem!” story card in their place without doing an entire iteration reboot.
Obviously, each way to handle a service outage surprise has its disadvantages. Canceling a sprint means time needs to be spent again in planning and estimating and retrospecting. It does provide a nice, clean break from the previous iteration and allows the contract to be rewritten. Pulling off the story cards allows more flexibility in an iteration, however it kind of reminds me of Darth Vader on Cloud City: “The deal has been altered! Pray I do not alter it again!”
There is a third option which is worth mentioning. Create a fire squad whose entire purpose is to fight off surprises and protect the team from the danger. While this in some ways virtually eliminates service outage surprises for a team, it also insulates them from the consequences of writing bad software as well as can reduce manpower when there are not service outages. It also sets the expectation that outages are normal and it’s perfectly reasonable to have them.
Unexpected Extra Work
This is somewhat similar to the service outage surprise as well as the estimation complication, but is more related to internal business needs as opposed to customer outage. A case study of this would be this past week, where I initially thought we would only need to spend a day of the teams time in the interviews, but then discovered that we needed much more time for preparation. The result is about eight hours worth of work which was not accounted for when the team did planning. Oops. My bad.
Frankly I don’t know of any official way to handle this other than not to do it. An unofficial way I’ve seen companies do it is to plan for approximately eight to fifteen plus hours a week that is non sprint time. Obviously this hurts team productivity and focus, but it allows the business needs to be met while providing some level of stability for the team.
Some General Solutions
One of the ways my teams have worked to combat these issues is to reduce their sprint iteration length. By changing from four week iterations to one week, they are able to more accurately plan things on a week by week basis. This makes user stories and features much harder to write from the perspective of a customer and not the team, but overall it seems to be a very beneficial change.
Another part of the solution is to focus on quality of your work, not just speed of delivery. By writing testable, modular, well designed software it becomes easier and easier to estimate the difficulty of work items and prevent service outage surprises. This solution requires much more time for teams with high amounts of technical debt, but in the long term it pays off.
There are probably more dangers and solutions I’m overlooking, but I believe that the “no new work” iteration social contract is important and should be adhered to. Simply put: Don’t change a teams direction in the middle of a sprint. Do change it after the iteration is complete.