For effective Scrumming, stories should have the desirable INVEST characteristics: They should be independent, negotiable, valuable, estimable, sized, and testable). We'll assume that the product owner is trained in Scrum and creates clean stories based on the subdivision of his requirements into independent features.
The problem, in my experience, is that teams struggle with adopting clean, incremental development practices because their design methods and existing structures are still not Agile; they design in layers instead of slices. A seemingly INVESTed story may not turn out to be so for the development team.
1. Seemingly INVESTed stories may not be so
Independent: The team that's used to layered architecture, or SOA (service-oriented architecture), would frequently insist on negotiating the complete interface. So the story has turned into a non-independent one:
The way we got around the issue was to not design the API completely but to finalize only the part needed for the current story. The rest of the API contained dummies at first. It worked beautifully.
Estimable: Story points are assigned on the basis of risk, effort, and complexity. If the code doesn't support incremental addition, the effort to fit new stories with already existing code will be nontrivial. In addition, the risk of breaking the existing code is very real.
Sized: If the story cannot be estimated with a good degree of confidence, it's probably not going to be sized right, which will throw the velocity and predictability into a spin.
2. Design and architecture topics should be a part of an Agile transformation
If the code base suffers from too much common coupling or content coupling, then it will prevent stories from having good INVEST characteristics. Agile is a change in culture and habits. The adoption process should focus on change in design habits also. There should be discussion about how to grow the interfaces/APIs incrementally, with only the framework established during the sprint.
3. Simple design ideas for incremental development
- Cohesion should be high and code coupling low.
- Solid principles take it a bit further and lay down how code needs to be designed.
- The prioritization of the product backlog should have input from the tech team on stories that may be required to make other stories testable.
The major point to remember is that refactoring is good. So it's OK to develop interfaces incrementally and just refactor when required. Trying to define perfect interfaces is far more expensive. It involves waiting, meetings, and approvals that delay the project while the billing meter is running.
During Sprint Zero, the team could pick up only a couple of stories but establish a framework that would enable incremental development of stories with INVEST properties.
A story truly needs to be a vertical slice of the software, even during development. It's important that we move away from legacy practices and come up with designs that can be incrementally enhanced and accept the easy addition of incremental new features.
As Agile coaches and ScrumMasters, we should engage the team to discuss design and architecture issues during transformation. It is very important for the team to realize that incremental addition of code and incremental design can work.
In Agile, most team members will develop a better sense of the overall goals and architecture. More often than not, they will make the right decisions about a design approach or technical issue. Scrum should use a posted model, where incremental design and incremental development can continue, while the decisions are posted for head architects or other powers for approval. It will be much cheaper to do the rework in the limited number of cases where change is recommended.