This presented a common conflict. On the one hand, we always welcome changing requirements and customer interaction over a plan, right? On the other hand, there were hard deadlines like trade shows. How can you keep adding work, but still hit the deadlines?
I have already discussed this conflict in an article called Welcome Changing Requirements, where I covered the Iron Triangle. However, I’d like to additionally stress the importance of something I have started calling the “Cone of Sanity.” Outside of the iteration, scope and priorities can be in a state of perpetual change. However, inside the Cone of Sanity, which is the 1-4 week iteration, there should be little or no change. The iteration should be like a calm oasis where the team can focus on delivery. In essence, the Cone of Sanity shields the team from the turmoil of new feature requests and shifting priorities inside of an iteration. This creates an “eye in the hurricane” which helps development teams maintain focus, thus optimizing productivity and resulting in frequent, quality releases and return on investment for the customer. Keep the iteration stable and you will reap much improved quality and quantity of output, a satisfied customer, and a happy team.
Posts
I get this. It is great to be flexible, but sometimes customer ADD can get ridiculous. It is a good idea to put a stake in the ground and provide some stability for the development team.
ReplyDeleteI've found that this can work sometimes, but often the customer (in my case, the marketing department) demands changes now, NOT in the next iteration. This happens a half dozen times every iteration. How would you handle this kind of a demanding customer?
ReplyDeleteI agree that this can be a tough one. One of the main points of Agile is to remain flexible, but disciplined. I have consulted at marketing-driven companies where developers had 100% planned workloads but spent another x% of their time handling last minute requests. And while some requests were completely valid, some were whims of a particular employee that would end up delaying more important features. Common examples: “But I already bought the ad space to run in 2 days!” or “We need to match a competitor’s offer NOW!” Developers were frazzled, releases were delayed and buggy.
ReplyDeleteWe did a few things with the process to improve the situation. First, we switched to one week iterations, so most high priority (non-critical) items could wait for the next iteration. Second, for “rush jobs” we’d usually take on easy things like misspellings, but anything that would actually impact the schedule had to be signed off by the Marketing director. This led to prioritization discussions within the Marketing group, and many of these “critical” issues had their priorities downgraded. Going to the director also meant providing visibility into their own poor planning in some cases, which often led to some requests being voluntarily de-prioritized with a resolve to plan better the next time. Third, as we identified how much time was spent on planned work vs. on-the-fly requests, we started building time for these on-the-fly requests into our schedule.
There are also potential technical solutions. If many of the last minute fixes needed are content related, you might more heavily use a content management (CMS) tool so that the business can make updates themselves without involving developers.
Hope this helps!