Here’s one of my big problems with some agile software developers and Scrum in particular — deliver potentially shippable software at the end of every sprint. That mantra puts a lot of pressure on the team to build, build, build. Planning? Designing? There’s no time for those. They need to build something that’s potentially shippable!
No they don’t! Some people are taking the words potentially shippable too literally. The Product Owner and the team always decide what to “ship” — or not.
What ever happened to prototyping? There are times when you need to hack some code to try an idea, experiment with an algorithm, or simply test a new system capability. It might work. It might not. Either way, you win because you’ve learned something and the end product will be better for it.
Don’t treat all sprints the same.
Differentiate between the early sprints in a project and the later ones. Late in the game, stable deliveries are important. As the software nears completion (approaches “doneness“), the users come to expect a level of sophistication and reliability. That’s not the time to be experimenting or doing anything that risks breaking or delaying the final build.
The early sprints are different. The early sprints are a feeding ground for hackers. Try something new. Experiment with an algorithm. Test a new library. Change an approach. If they can’t experiment early in the project, when will there be time to prototype new thinking?
Get the stakeholders and end users involved in trying something new. Their feedback is important in determining if a new approach is viable. It’s all a matter of setting appropriate expectations for every sprint deliverable.
Delivering potentially shippable software at the end of every sprint is an enviable goal. It just not always achievable or even necessary. Apply good judgment when deciding what to deliver and how to deliver it.