2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- August 3, 2016
- Integrate Continuously
Different people have different ideas of what it means to be Agile. For some, Agile means doing standup meetings and two-week iterations. For others,it means doing all the practices from Scrum, Lean, and Extreme Programming.
For me, what it means to be Agile comes right out of the Agile Manifesto, which says: “Our highest priority is to satisfy the customer with early and continuous delivery of valuable software.”
For me that statement says it all. It states the goal of satisfied customer and the means of reaching that goal: continuous delivery of valuable software.
This is easier said than done in most situations. There are several prerequisites for reaching continuous delivery including writing testable code and a suite of reliable unit tests that can quickly regression test the system without any human intervention.
Why is this so vital? Because without the infrastructure of continuous delivery we’re doomed to build software in phases, which throws us back into Waterfall development.
Virtually every Agile implementation I see requires a separate QA effort on code that was finished in the previous iteration. That’s Waterfall.
We’ve known since the 1960s that as the time elapses between when a bug is written and when a bug is fixed, the effort and cost required to resolve the bug grows exponentially. But this is just the tip of the iceberg. Bug reports from previous iterations interrupt developers’ flow and force them to reacquaint themselves with code that is no longer in their short-term memory.
Having a separate QA effort can shift the responsibility of bugs away from the developer who wrote them and introduce a great deal of instability in the software development process. One bug can prevent a system from compiling or running properly and cost several more bugs to be hidden. When software isn’t tested as it is written, it’s most likely not being integrated immediately after writing it. And that means the most pernicious bugs often go unnoticed until software is integrated and tested. This is one of the big problems in Waterfall development.
The center piece of true Agile software development is in continuous deliverability, but that doesn’t mean we have to release continuously to our customers. Releasing code to customers is a business decision. But virtually all software should be built to be releasable all the time. Because only when code is integrated and tested as it’s built do we get an accurate measure of our progress and our risks.
It’s the infrastructure for continuous delivery that creates the context for all the other technical practices in Agile software development. I always recommend to teams that moving toward continuous delivery is the best place to improve their Agility.
Previous Post: « Agile Amped Podcast
Next Post: The Single Level of Abstraction Principle »