When iterating is taken at face value without further discussion and clarification, the concept can create a misunderstanding about what we’re striving for with agile development. Here are a couple of negative connotations typically associated with iterating:
“We’re re-taking ground that we have already covered.”This can lead to that inevitable judgment:
“We didn’t‘do our homework up front.”
“This agile stuff is crap. We’ll never get anything done by continually re-working everything.”In the first place, if you are re-working everything, something is fundamentally wrong that any process alone can’t fix. It’s a signal that you aren’t aligned with what your customer wants. In fact, you don’t even have a basic understanding of what your customer really needs.
However, a more likely scenario is that some things that you deliver will require re-work. Users struggle with reconciling written requirements, user interfaces mockups and the behavior of the system until they actually interact with working software. That leads us to the inevitable, “Now that I see it…” statement that precedes a request for change.
Before I continue, let me set the record straight: Iterating should never be the result of not thinking things through or being undisciplined. Agile development all about disciplined thought and action. But it applies a different type of discipline than other approaches. Agile development leverages iterating in specific ways.
A prerequisite to low-cost iteration involves when we spec out the details. Agile seeks to eliminate waste by elaborating requirements on a just-in-time basis, benefiting us by avoiding spending time on detailing and estimating requirements too far in advance because:
- Some requirements will likely be down-graded in priority as time passes, even eliminated from consideration in favor of other things that have become more important as time passes.
- Other requirements will change, either because business conditions change or because the customer changes their mind based on what they learn as they interact with the software.
- We can start work sooner because we don’t have to perform detailed planning for large batches of work up front. We spread the elaborating and planning throughout the development effort.
- We can re-prioritize work and accommodate change at a lower cost. This is because we haven’t heavily invested in detailing requirements up front along with tasking work out, estimating in hours, and generating detailed project plans.
- We can accommodate change quickly. Many organizations will state that they adapt to change, but there are delays built into typical formal change control processes that involve reviews, projecting impact to the current schedule (by re-working details) and approvals that agile seeks to avoid by localizing decision-making to those performing the work, simplifying and speeding up the process – at low risk because we are delivering small amounts of work in short cycles.
- We can incorporate what we learn from the customer as we elaborate new requirements on a just-in-time basis. And because the development team and the customer have learned from each other as they have interacted, inspected and adapted using short delivery cycles, the likelihood that new features will need change once they are delivered actually decreases as time goes on.
Planning for value: We prioritize our work based on value and then progressively plan the delivery of that work using short delivery cycles, keeping the cost of change low.
Learning: We continually inspect and adapt in those short cycles by reviewing working software with the customer, modifying our plans to accommodate changes they desire along with asking ourselves how to better deliver that value in the next cycle.
Adapting & Improving: The act of implementing change to add value to the product in the eyes of the customer along with adopting practices and techniques to improve the quality and/or speed of our delivery. We also use information gleaned from the experience on future work, improving those results as well.