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
- October 21, 2015
- Rants
When I was first introduced to Agile I had a hard time understanding how to order the backlog. Agile says to do the most important, the most valuable work first but I used to think that was overly simplistic. If I’m building a house I shouldn’t build the master bedroom first just because that’s where I’ll be spending most of my time. I have to start with the foundation.
Complex construction of physical things often has an ideal sequence. In the case of a house, the foundation is built toward the beginning of construction and the roof is built toward the end. I reasoned that something similar must be the case for building software.
I was wrong.
What I’ve come to realize is that we want to build software features as independently from other features as possible. We can do this if we build a feature at a time. In Waterfall, we build to the release, not to the feature. When building to a release there’s nothing stopping us from creating lots of dependencies between features. While this can be seen as an efficient way to get to a release, it often binds features together in ways that make the software hard to extend in the future.
There are times when more than one feature relies on the same capabilities or services as other features. Sometimes it makes most sense to build the easiest feature first then build the harder feature that depends on the easier feature. But most of the time, delivering the highest value features will help your users the most.
Instead of focusing on the release, focus on the feature and build it to be independent from other features in the system. By doing this, you’ll build the most important stuff first and you’ll build it so it can be more easily extended in the future.
Previous Post: « Don’t Show me your Private Parts
Next Post: What Makes a Good Test? »