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
- December 6, 2017
- Build in Small Batches
The key to unlocking agility is to think small.
The whole purpose of building software in time boxes is to help us get better at scope-boxing, which is working in smaller pieces—breaking large tasks down into smaller tasks.
I’m not a big believer in using story points. It’s better to be able to break down all tasks into smaller tasks that can be accomplished in about half a day. When tasks become both small and homogeneous they’re much more straightforward to process. So rather than focus on task estimation, I focus on breaking down tasks into manageable sub-tasks. This gives a different focus to planning meetings. We spend our time working through examples of what we want to build rather than estimating tasks, which helps move a project forward more rapidly than spending a lot of time estimating tasks.
Being able to think small and break large tasks down into sub-tasks that are more manageable actually requires a whole range of key Agile skills and techniques.
I’m a big fan of behavior-driven development (BDD) or as it’s sometimes called acceptance test-driven development (ATDD). Unlike test-driven development (TDD), which is about building testable behaviors in the system, ATDD is about defining features and their acceptance criteria so that we know when it’s complete.
Automating acceptance criteria for features can be amazingly valuable for organizing a project and keeping it on track. Knowing rather than hoping we’re done with a feature allows us to move on and work on the next feature with confidence.
When I say “think small” I mean to think in terms of independently testable behaviors that are also independently verifiable so their acceptance criteria can be automated.
Abstractions are another way to think small. Abstractions let us put lots of similar things in the same category so we can treat them in conceptually similar ways. This is how we imbue our programs with meaning. Software, like all language, is a communication medium. It just so happens that software also has the side effect of making a computer do something. But when a programmer reads a program she is extracting a very different kind of meaning from that code than the computer does.
Because software is about creating behavioral models, every feature in the system can be seen as a separate behavior and every behavior should have some kind of an effect on the system. For example, you can receive some data, process it and change it in some way, then return the changed data. Or an object can simply change its own state or the state of another object in the system that can later be observed.
That’s important because without the ability to observe a change in the system we can’t verify that the software worked. And working with unverifiable software is a drag. I advise against it.
Instead, think small and build small, testable behaviors that are independently verifiable. If you do, you will be able to experience true agility. You will be able to automate product verification and thereby drastically reduce the time and cost of bringing software products to market. And isn’t that the Holy Grail of Agile?
It starts with thinking small and ends with building small.
Previous Post: « Domain Language
Next Post: Change Your Mind, Again »