We do Scrum but…
Scrum – We don’t deliver a working increment every Sprint
Are you serious? — episode 3
This is one of the principles of the Agile Manifesto for Software Development:
Working software is the primary measure of progress. — AM
Think about what this means.
OK, let’s now look at Scrum. Many organizations use Scrum. In all kinds of shape and form. Pivotal for Scrum is the following:
“The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.” — SG
This is completely in line with the quoted principle of the Agile Manifesto. Still, despite of this, you see many invented practices like:
A Hardening Sprint is an additional Sprint to finalize an item before it gets deployed. You can think about activities like regression testing, User Acceptance Testing, additional reviews, finalizing external interface issues. How sure are you that the “hardening” will take only one Sprint?
Sprint Zero entails everything that is deemed required to start a project or to start working on a feature. You want to be well prepared. Things you generally do in a Sprint Zero are:
- creating a product backlog
- creating a release plan
- creating the architectural design
- building the architecture (often under the misused name of Architecture Runway)
There is a contradiction in a Sprint Zero. It is often used by companies with insufficiently informed leaders, trainers or coaches and where the ”Waterfall“ routine is predominant.
Sprints for different phases of the project
This is about Sprints for Requirements Gathering, Design, Development, Test, Deployment. Scrummerfall. A team works in Sprints to tackle different phases of a project. It is a Waterfall/Traditional Project Methodology initiative making use of the Scrum structure and events.
Seriously, this is NOT what Scrum is about!
All of the practices above include one or more Sprints that don’t deliver a potentially releasable increment. This goes against what Scrum is built upon: empiricism.
“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” — SG
Empiricism is considered to be the best way to create complex products. The product (and thus its architecture) emerges.
“In complex environments, what will happen is unknown.” — SG
“Only what has already happened may be used for forward-looking decision making”. – SG
You should have a “Done” iteration as a result of the work within the Sprint. You wish to inspect the value of the iteration and adapt if required. It is the art of taking small steps, showing what you built (transparency), inspect and adapt.
A sprint may well be 80% design or architecture, as long as there is something of a working product delivered. A designer may be working on a holistic image, but should be careful with sharing it because it can create the wrong expectations.
Now back to the practices described above.
A Hardening Sprint is a sign that the team doesn’t have everything it needs to create a potentially releasable product.
Teams that are in this situation can take the opportunity to inspect how the Definition of Done can be extended to be able to create a potentially useful version of working product. They can then take measures to adapt, like making sure that the capabilities required are also taken within the team.
A Sprint Zero ignores the whole notion of empiricism. It leans towards Big Design Upfront (BDUF) assuming that many things are known upfront. It neglects that Scrum is meant to develop, deliver and sustain complex products. For an example how you can extend your Definition of Done see my post about our yourney to Devops:
We do Scrum and… — episode 4medium.com
I wish to specifically mention the misuse of the term “Architecture Runway”. Many confuse it with “Building all the hardware that is expected to be required”, neglecting that through empiricism the product including the hardware emerges (organic growth). If you wish to focus your first Sprint(s) primarily on building up hardware, include the complete team in the work. And also deliver a working product, however small it is. Plus: remain focused on the fact that you build the hardware for the existing and upcoming features only. That is, if you wish to use Scrum’s full potential.
Scrummerfall is not leaning towards BDUF. It IS BDUF. Scrum is not suitable for this way of working. Everything that can be said about Sprint Zero applies to Scrummerfall. And more. The obvious issue with this approach is that only after a number of Sprints you receive feedback on the value of the product. What if the response is negative? Months of work down the drain? No transparency results into no opportunity to inspect and therefore no opportunity to adapt.
Scrum is a framework for developing, delivering, and sustaining complex products. — SG
Are you working with complex products? Does this mean that you have a lot of uncertainty? Then Scrum is a great framework for you! Make sure that every Sprint you create a useable and potentially releasable product Increment.
Are your products simple? Is your environment stable? Will your product hardly change in time? Are the requested increments straightforward and clearly understood by the team and all the stakeholders? Maybe Scrum is not suited for you. Or any Agile way of working for that matter. However, I highly doubt there are that many software environments with this characteristic.
For more on empiricism and the first pillar — transparency, this piece of Sjoerd Nijland is highly recommended:
A deeper understanding on… What a word: “Empiricism”. To tell you the truth, I knew little about what this word meant…medium.com
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
My twitter profile is https://twitter.com/WJAgeling
Join us on Slack!
We have run a Serious Scrum channel on Slack. You’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts. If you are interested in publishing in Serious Scrum you can connect with us there to make it happen.
Thank you for taking your time to read seriously.