2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – 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
- March 28, 2018
- Rants
I believe that Agile software development is ideal for discovering what really needs to be built and to build it in a way that it will last, but I don’t believe that Agile is required on every project. There are many kinds of projects and many reasons for not doing Agile.
I’ve written quite a few accounting systems in my day. Credits and debits. I helped to build a multi-currency accounting system for the wholesale banking industry in the 1980s. I know a lot about accounting systems. If you wanted me to build a new version of the system that I was already familiar with then I probably wouldn’t have to build it with Agile methodologies.
If you know exactly what to do, then there’s no need for discovery. There’s no need for feedback. If you can’t do anything with the feedback, then there’s no need to get feedback.
Agile is about learning as we go. It’s about taking the giant daunting task of building a software system and breaking it down into little pieces that each provide value and in and of themselves are simple to build.
I worked on many Waterfall software development projects back in the day and not all of them were failures. Several projects that I had worked on, as well as other developers that I’ve known, were quite successful in the Waterfall world. But I’ve had my share of failures as well, especially on Waterfall projects. And I’ve seen this same outcome throughout the software industry.
Agile helps but it’s no panacea. You can turn Agile into a whip and start getting the worst from people. Agile is not intended to be a tool for manipulation people.
And it’s not just a planning tool. Before Agile became the management process known as Scrum, Agile was a set of development practices that software developers used to effectively build products for clients in the wild.
To me, Agile is about the technical practices that deliver on the principles of Agile and help us “continuously deliver valuable software” to our customers.
Agile isn’t for everyone and Scrum isn’t for every team. The reason that Waterfall software development is still so prevalent is that it provides synchronization points with the business because most businesses are cyclical.
Since most businesses are cyclical there is always a component of interfacing with the rest of the business that happens in cycles. Lots of teams stay in synchronization with the rest of their company by following a Waterfall process for planning and interfacing with the rest of the business but internally they employ the practices of Extreme Programming.
I have several clients that build software using Waterfall methodologies in terms of designing to a release. However, it always makes sense to build the system feature by feature, integrating each feature into the system as it’s being built. To me, this kind of continuous integration is the very essence of Agile software development.
Previous Post: « Build What Users Want
Next Post: The Power of Continuous Integration »