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
- October 7, 2015
- Rants
What’s the real difference between Agile and Waterfall? Is it short iterations, standup meetings, having a ScrumMaster, or what?
Clearly, there are many differences between Agile development and Waterfall development. Agile involves less planning and more feedback but those are not the major differences from Waterfall. Some people will tell you that it’s a “mindset” shift but that isn’t very specific either.
I’d like to propose one key difference between Agile and Waterfall that seems to make the biggest difference: how frequently you integrate. This may not seem like the most important distinguishing factor but in reality it’s one of the main drivers of agility.
How frequently we integrate predetermines our development process. If we integrate code after it’s written, even just a few weeks after, then we’re really doing mini-Waterfalls and not Agile. It’s only when we continuously integrate that developers get the instant feedback that shifts the dynamic of development.
Remember Pavlov’s dogs? Stimulus and response has to happen close together, otherwise we won’t see the connection. The same is true for all of us. We have to see the consequences of our actions immediately, not in days, weeks, or even months later. If we don’t, we won’t make the connection between our actions and the end result. This is why Waterfall development is still popular even though we all know it doesn’t work.
At the end of a Waterfall project when code is integrated we usually find the worst bugs. I remember dreading integration on the many Waterfall projects I worked on back in the day. I don’t have that dread integrating code anymore because I integrate my code as I build it.
Integrating code as it’s built removes the dreaded integration phase in Waterfall development and turns our biggest impediment into our richest form of feedback. Integrating a year’s worth of development can be insanely hard but integrating what I did in the last hour (or few minutes) is very simple and I can immediately fix any problems while it’s still fresh in my mind.
We’re all familiar with the idea that it costs orders of magnitudes more to find and fix bugs after release than it costs if a bug is found immediately after it’s written. We want to find bugs when the code is still fresh in our minds. When we do we get instant feedback on what works and what doesn’t work and that immediate feedback is what we need to change our behavior. In a very real sense, we know what not to do and we stop doing it, without even thinking about it. That’s the real value of Agile development.
Previous Post: « What Mr. Robot Says About Bugs
Next Post: Don’t Show me your Private Parts »