It’s not all that uncommon to be in the middle of rolling out agile practices to an organization and to have newly “self-managing” teams start asking questions about the effectiveness of going ahead with a feature (user story, product backlog item) when all of the details aren’t completely known. Generally you here one or both of the following questions:
- “It doesn’t make sense to write something one way today just to have to rewrite it tomorrow when the customer clarifies what they want or asks for something else. Isn’t it better to write it RIGHT the first time?”, and
- “Why should be start building something when the customer doesn’t yet completely know what they want?”
Both questions are really good ones to ask and NEED to be asked by an agile development team on it’s way to mature self-management. In this blog post, we’ll deal with the first one: “Isn’t it better to write our code RIGHT the first time?”
This question typically comes from the experience developers have when they find themselves re-writing code they just finished building one or two iterations (Sprints) ago.
As is often the case, I recommend looking at the problem from two perspectives: mitigation (how to reduce the impact) and financial (what’s a good business decision).
- Mitigation —
- While it’s not advisable to slice and size more than 2 Sprints ahead (because things change and you could end up wasting your time), there’s nothing wrong with looking three or more Sprints ahead to get an understanding of what’s coming.
- Pair Programming – definitely can help here. One coder driving and one coder navigating can open up the possibilities for unexpected improvements to code today that can be beneficial tomorrow.
- Coding and Design standards — sometimes just attacking similar problems in similar manners with consistently well written code can make a big difference. It’s also possible that SPI and ESB are good patterns, but not the right patterns as being applied. Perhaps there are a few more. Also telling — how many other developers can you talk to about this that are knowledgable of patterns and how to use them? If the number is small, there’s probably a bigger problem that needs to be addressed.
- Financial —
- It’s a lot harder to see when you’re stuck in the middle or rewriting code, but there also a cost factor to include. If we spend more time earlier in refinement or sprint planning, are we guaranteed to a) identify cases where we change what we are doing today to take into account what we need to do, b) discover an obvious solution that resolves both what we need to do and what we might have to do, c) be able to implement the “better” solution less expensively by knowing up front , and d) not have changes in the Product Backlog that reverses our decision because of a de-prioritization or rewriting of a backlog item.
- The unfortunate thing about problems like this is that we have to approach all problems as if there might be a better way, even though only a small portion of them might actually yield savings by “doing it better the first time.”
- Start identifying specific cases where something you did in one sprint had to be significantly rewritten two or three sprints later.
- Start getting more developers thinking about this problem and also, specifically identifying cases.
- With the other developers, begin researching and identifying patterns that are reasonably easy to implement and will solve the common cases.
- When those common cases resurface, implement the agreed upon pattern and then discuss.
- Create and implement coding standards, implement code review and enforce the standard (change it when necessary)
- Increase internal learning on this topic.
- Begin to implement pair programming as a rule (i.e. most coding is done as a pair).
- Read “Clean Code” by Bob Martin and “The Art of Agile Development” by James Shore.