Ingredient #2: Minimize the Solution
W. Edwards Deming said, “Slow is smooth and smooth is fast.” Theoretically speaking, Deming is pointing out that practicing slowly (until you achieve precision) will lead to speed. In the case of sprints, the quote also nicely describes the importance of accurate estimations and accountability in delivering on a commitment; regardless of how fast the work is done.
Most clients express their need as software that is “better and delivered faster.” This is not an unreasonable expression. However, we ask if it is “quality and timeliness of delivery” that they look for instead.
The subtlety here is that while working with our stakeholders and end users, we find that assuming high quality, a valuable outcome, delivered at the right time is good enough.
This simple agreement is powerful because it allows us to meet our stakeholders’ objectives, while also implementing a solution that results in higher quality. Higher quality is possible because the goal is no longer speed, which, as we know, is the enemy of quality.
The second key ingredient is to minimize the solution by knowing your code.
Knowing the code is not easy, especially walking into an organization with a legacy platform. However, knowing the code is important nonetheless. The secret to predictably delivering in a timely way is to find the smallest solution that ALSO hits the value proposition of the story.
When asked to provide a solutions roadmap that outlines what we will deliver each sprint, we always ask for a discovery sprint. During the discovery sprint, and depending on the needs of the client, we typically perform one of three exercises to familiarize ourselves with the code:
- Defect fixing
- Test case automation
- Integrated prototyping
The discovery sprint is important to us because we can isolate problem areas and uncover ways to work with the code more efficiently. We look for different types of technical debt, such as overly complicated code, anti-patterns, tight couplings, dependency proliferation, poor code commentary, and the amount of unit test coverage. When you know the pitfalls in the code you are changing; you minimize the ultimate solution.