2024 Public Training Schedule
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
- February 27, 2019
- Build in Small Batches
In a lot of ways, I think that Practice 2–Build in Small Batches, from Beyond Legacy Code, is the core practice that made agile and Scrum great.
I was breaking down my software projects into smaller pieces as early as the 1980s. I didn’t call it agile back then. In fact, I was a bit embarrassed by it. I had trouble holding the entire program in my head at once so I broke it out into little pieces and built each piece separately, integrating them together as soon as possible as I built it. This turned out to be a much safer way of building software for me so I just stuck with it.
But there is an art in being able to break down a large project into small pieces. You don’t just chop things up randomly, of course. We need to decompose concepts so that they recompose easily later and they come together without a lot of rework.
There is definitely an art to story break down as well as a science to it. When we build small, we get more opportunities for feedback. We can also build more decoupled components that are independently verifiable.
Building small is really what makes agile great. This is really why we time box in agile. We make teams do two-week iterations because it forces them to build small units of behavior from start to finish so that the customers and stakeholders can see steady progress.
The seven strategies I want to discuss from my book on Practice 2 are based on one of my favorite blog posts. It’s called Seven Strategies for Measuring Software Development and I often refer clients, students, and associates to this blog post for some of my favorite metrics for measuring progress on software development teams.
But before we dive into these metrics I want to say that it’s easy to overdo it and we always have to be careful when we’re using statistics to analyze complex systems like teams or a software development process.
At best, metrics are indicators but in addition to metrics we have to look very closely at how collecting them incentivizes us to do certain things and de-incentivizes us not to do other things. As long as these things are in alignment with our greater purpose, then there’s no conflicts but too often these things don’t match up we get trouble. My advice would be to start with just a few metrics rather than trying to track a lot of them. Try to look at the ones that will affect you the most.
One metric that you won’t find me recommending that you track is velocity. I think velocity focuses us on the wrong things. Rather than estimating work, I prefer to work through a few possible examples for the features that we want to build so that we get clear on exactly what we want the feature to do and I can address any questions right away.
So, with those caveats, I present to you the next seven blog posts based on Seven Strategies for Measuring Software Development from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. Enjoy.
Previous Post: « Support Refactoring
Next Post: Measure Time-to-Value »