This is the fourth in a series of posts on dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The fourth antipattern discussed in the post is…
4. Adherence to strict feature-set goals per iteration even if extra time is needed
The old command-and-control mentality demands that software development teams establish plans and march to them. So if a team decides to implement 10 stories during a sprint and they run out of time, they must keep marching until those 10 stories are complete. At some level, this seems to be a reasonable mandate.
The team committed to delivering a set of functionality as defined by a group of stories. That commitment was reported to the business stakeholders. Commitments need to be kept, right?
What about time?
The original commitment won’t be met by allocating more time. There was a time element included in the commitment. The feature set would be delivered by an end date. Moving the end date (a commonly used tactic in software scheduling), doesn’t make the team successful.
One of the major advantages of any agile development approach is that software is delivered early and often. This is a critically important notion. The team can always add more features to the software, however, they can never reclaim lost time.
If the team misses a trade show deadline, the damage is irreparable. If the software is not ready in time for a major customer demonstration, the sale is lost. If a marketplace window is missed, competitive advantage is gone.
Think ‘Continuous Delivery’
It’s not about delivering faster and faster. It’s about making reasonable commitments and meeting them. Being agile requires timeliness. In turn, timeliness requires discipline. The team has to learn to accurately estimate the work to be done and deliver on time. If all the estimated work can’t be delivered in the time allocated, the team must assess the situation and take corrective action.
The estimates might be overly optimistic. There may be obstacles within the team that are slowing everyone down. There may be external factors beyond the team’s control that are causing delays. It’s important for the team to re-group at the end of each iteration or cycle and identify areas for continuous improvement.
In my experience, marketing, sales and customers are willing to accept fewer software features in exchange for timely delivery and a commitment to keep delivering until all the requested features are included. Time is at least as important as features, and almost always more so.
Identify the mission-critical stories and focus on them. Don’t get dragged down by superfluous features early on. There will be plenty of time for the little stuff later — if you deliver the big stuff sooner.
By the way, I don’t mean to ignore or slight quality. My operating assumption is that quality must always be kept high. You can cut corners on features. You can cheat on time. But if you compromise on quality, you’ll lose.