2025 Public Training Schedule
June 23 26, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
July 22 – 25, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
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) 2025 To Be Agile
- January 25, 2017
- Collaborate
As an Agile developer, I often start projects without a clear sense of exactly what I’m building. This used to be very difficult for me. I wanted to start with a complete specification for what I was to build, but today I know that it’s more efficient and effective to discover exactly what needs to be built just in time.
But this sometimes leaves me with a set of unknowns in my critical path, like boulders blocking the road in front of me, that have to be addressed before I can move forward. These unknowns can be anything from how an API behaves to finding a framework that does things I need to have done.
But that’s okay. When I find an unknown in my critical path, I simply spike on it.
Spiking is when one or more team members focus on answering one or more questions within a given time box. The goal is to answer the questions before the allotted time expires. If I can’t answer the questions then I’ll try to answer at least part of the questions and formulate a plan and timeline for answering the remaining critical parts.
I find that spiking on unknowns is an invaluable practice during iterative development. It’s easy to get lost in the weeds, especially when you’re doing research. Having a defined goal within a fixed period of time can be very helpful. When the time expires, I check in and see how close I’ve come to answering my questions. If I got satisfactory answers, then I move on. If I still need to do more research I will set up another spike.
Spiking on unknowns ensures that I don’t get lost for any length of time. I can always step back and reevaluate. Sometimes 80% of the resolution is sufficient and I don’t have to go for a total solution. Using time boxes to check in and evaluate my progress has become a useful practice that I have extended to many areas of my life.
If you hang around my office for any length of time, you’ll probably notice a Pomodoro timer going off every twenty-five minutes. Every time the timer goes off I stretch but I also check in with myself and ask myself three questions: “What have I learned? Where am I stuck? What am I going to try next?”
Unknowns are only scary if they catch you off guard. Spiking on unknowns is a way to prepare and address issues before they come up. Generally my spikes are anywhere from a few minutes to a few hours but I have spiked for several days in the past. I try to keep my spikes as short as possible because this gives me more opportunities to check in and evaluate my progress.
The key to a successful spike is to have the right questions to research and enough time to get good answers.
Previous Post: « Buddy Programming
Next Post: Podcast on The Agile Uprising »