One of the hardest things for our sales team, our project managers, our development team, and our customers to agree upon in agile development is what constitutes an acceptable stabilization period.
Let me expand. I have been in software consulting for almost 10 years now, and the hardest part of any project is gaining final customer acceptance that the project is "done." With custom software, there always seems to be another bug to fix. The customer is afraid of giving up their rights to have the undiscovered bugs fixed if they sign off too soon.
With agile development, the idea we have implemented is that there is a set amount of time after new development for the team to focus on changes or fixes from any prior iteration. We set aside one iteration for software stabilization. We set this expectation with our customers up front, and they agree.
When it comes time for the stabilization period, however, it seems that as new development tasks from prior iterations take more time than anticipated the new development tasks bleed into our stabilization. While agile touts that our customers should be able to prioritize all outstanding work - be they new development tasks or bug resolution - based on their needs, it seems that the customer always chooses to add the new development tasks and never choose bug resolution. Then, when stabilization is over and there is a list of bug fixes, the argument comes up that we did not deliver a quality product.
While I understand that this problem is all about setting the appropriate customer expectations and about working with the customer to convince them that new development tasks should not be planned in the stabilization phase, it seems that we repeatedly get ourselves into this same situation. I love the agile approach. I love the idea of working closely with our customers, and getting immediate and real feedback as we deliver working software on a regularly scheduled basis. I also think it makes sense to weigh the tough decisions with the client sponsors in order to prioritize remaing new development tasks against the agreed upon schedule - excluding the stabilization period.
However, just like I found with the waterfall process, as soon as the schedules start to slip or estimates go over, the first thing to get the ax is testing. In this case, stabilization gets the ax. And when that happens, how can we confidently deliver quality to our customer and agree that at least the first phase of the project is in fact "done?"
Subscribe to:
Post Comments (Atom)
3 comments:
One possible solution to this is to come up with a support contract that describes the relationship between the consultants and customer after the project (iterations) are complete. That way, bug fixing can continue in an agreed manner. The tough part is that the expectation of a support contract must be set early on when engaging with the customer.
I wonder if you could use two stabilization iterations instead of one, and have one completely devoted to bug fixes? That way, you would force the customer to prioritize just bugs, and still give them an opportunity to include enhancements in the other iteration.
Selling a customer on two iterations for stabilization might be challenging. Perhaps the iteration for enhancements could be called something else.
On the other hand, it seems that if a customer is making a business decision that the enhancements are more important the bugs, they shouldn't be surprised at what they get. But as you said, it is hard to know how much time things will take sometimes, and so perhaps they have an expectation that you will get to most of both.
Two iterations could be cool, and I agree that setting expectations upfront is another good way to pave the path for a realistic support phase post-production roll-out.
I have heard managers compare the expectations of custom software support to be about 20% of the original development cost per year. Too often, though, I do feel that customers expect bug-free software that requires no support and are disappointed when they realize that is not what they purchased.
Post a Comment