In Part 1 of “Agile Antipatterns: Easy to Spot, Hard to Change”, I talked about the ten antipatterns signifying that an organization may not be ready for adopting agile and offered some suggestions for dealing with the first three of them. In this post I`ll pay a closer look to the next three impediments on the list: adherence to strict feature-set goals per iteration even if extra time is needed; expecting the software to be built better, faster AND cheaper; and postponing refactoring until later, usually after a release.
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.
Comments