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
- April 13, 2022
- Build in Small Batches
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set here. The next seven blog posts are expanded versions from “Seven Strategies for Splitting Stories”. You can find the original post here.
At the risk of waxing Rumsfeldian, “There are knowns and unknowns.”
The second reason that I find stories are big, aside from being composed of compound stories, is that stories are complex. Complex stories are complex because they have elements that are unknown. So, a complex story has known elements and unknown elements, typically.
An unknown element could be not knowing exactly what the customer or user wants from the story or it may be that we know what they want but we don’t know yet how to implement it.
One of the biggest things that developers who are used to traditional Waterfall requirements must get used to when they’re doing Agile is going into coding without knowing all of the requirements. Agile does this intentionally because it’s more effective and efficient to figure out many requirements as were working through them in the development process rather than trying to do it upfront in a planning process. This is far more efficient, but it does mean that we’re going into iteration with unknowns, which we’ll have to figure out in the middle of the iteration.
I have a whole range of techniques for managing unknowns during an iteration, as well as ways of encapsulating them so they don’t bite me when I’m not expecting it. When I’m confronted with something that I need to know, then typically I’ll stop what I’m doing and figure it out. I often do this in tiny iterations that last anywhere from a few minutes to a few hours.
In my own personal tiny iteration, I will identify the questions I want to address and give it a time limit for when I’ll check in to see how much progress I made. The time limit might be 20 minutes, or it may be a couple of hours. When that time limit is reached, I’ll reevaluate and see if I’ve addressed any of the questions that I had or if I have new questions that need to be addressed, or if I resolved the issue and can just move on.
There are several reasons for not wanting to figure out everything up front before I start coding. I noticed that a lot of the issues that I thought were important while I was planning turnout two either be unimportant or get resolved on their own so that by the time I get into the coding phase they have resolved themselves. Since many issues turn out to be like this, I find that a lot of the things that I thought would be important issues for me turned out to be things that I don’t have to worry about.
Conversely, however, several things that I hadn’t even considered turn out to be quite important while I’m coding, and since I’m not wasting my time on guessing what they are upfront then I have time to address the important ones when they come up.
Previous Post: « Break Compound Stories Down into Components
Next Post: Iterate on Unknowns Until They are Understood »