A good Scrum team needs to be prepared for any given sprint to be the last one on the project. Think of this sprint as if it were the last one ever…
Of course, a sudden announcement that the current sprint is the last would certainly cause a reaction, since people are so involved in the project/product that they usually want to keep working on it and see more things come to life. But there shouldn’t be any laments like “bummer, that framework we were working on is all for nothing,” or “we had everything ready for new demands that aren’t even going to happen.”
If you hear these laments, it’s a sign of BDUF (Big Design Up Front).
AVOID BDUF
With agile methods, we aim to avoid BDUF because we believe in emergent design. It’s true that the big architectural decisions are made at the beginning: languages, service-orientation or not, web or app, etc. But the details need to be worked out later on, as the project progresses and needs to arise.
Avoiding BDUF has several advantages:
- Delivering ahead of schedule, focusing on the business
- Greater knowledge of the context to be able to make architectural decisions
- Shorter feedback cycle between creation and use
- Lower risk of creating something that will never be used (does that ring any bells?)
- Focus on the result
Prioritization is everything
In each sprint planning meeting, the teams should ask themselves:
“If this were the last sprint ever, what would we deliver?”
It wouldn’t make sense to deliver a library, a POC (Proof of Concept), a data access layer or a detailed design of a product that’s not yet functional. We have to deliver something that adds value! So then, when will we create a library or a new data access layer?
This should happen progressively – as in, such a library or layer would be developed as and when it became necessary. What if we want to make a big architectural change to the project? Do it in a slow transition – we talked about this in another post:  “New System Version!”
Good prioritization must be based primarily on business decisions. It’s the team’s responsibility to create a coherent emergent design (refactoring should be encouraged to maintain internal quality), but that is geared towards business results.
Orientation towards Business Results
Many of our clients have embraced agility: an iterative process, continuous improvement, visual management and so on. However, we still see examples of efforts that aren’t results-oriented, such as creating a framework that after almost a year is still not visible to the business, designs that aren’t tested in practice for months, etc.
So: P.O., team, ScrumMaster, and leaders in general, remember to ask yourselves at each planning stage:
“If this were the last sprint ever, what would we deliver?”
