Scaled Single Sprint ScrumTM
Scrum is hard and tedious! It’s like groundhog day for software projects! Ever noticed that scrum does the same thing over and over again? Plannings, retrospectives, dailies, backlog refinements… Each sprint we do the same thing! Especially for long running projects this becomes boring. Programmers follow the Don’t repeat yourself paradigm, so why we do differently in processes? There has to be room to optimize, right? There is a solution to it: Scaled Single Sprint Scrum - It’s like scrum but totally different!
Scaled Single Sprint ScrumTM
The essence of Scaled Single Sprint ScrumTM is to take all the good things that scrum offers and combine it to the maximum effect. By doing all the meetings needed at the beginning of a project, the coding-time the programmers get is much more improved. Especially later in the project, when deadlines run tight. Doing all the necessary planning and scoping early on also mitigates the risk of having to change requirements when the project is already underway. Since the plan is done up front, this leaves more time to write requirements and design documents. - A good thing!
Such a “Scaled Sprint” usually can be cut into four phases - Requirements, Design, Implementation and Testing Verification - as shown below.
“Maintenance” is not a phase, but can be considered a second “Scaled Sprint”. True to the agile mindset it can be decided after the end of the first “Scaled Sprint” if a second “Maintenance” Sprint will happen.
Image courtesy of Wikipedia
But just making the sprint longer is of course not enough. Instead of tracking the requirements as fragmented post-it notes (absurdly called stories), putting them into a single large document helps the programmer to find the requirements easier. The reduced environmental and financial impact is an additional benefit. It is well known that software developers take pride in how much concurrent information they can hold in their heads, so having a large requirements document is not a hindrance to them. On contraire!, it will most likely help to motivate them through the extra challenge it holds. Having lots of cross-references and the occasional contradicting requirement only adds to the challenge for your programmers. Personal Mastery of large documents is on the forefront of the core values of Scaled Single Sprint ScrumTM!
While the programmers are reading and memorizing the requirements, have your architect draw up a design for the software. If no dedicated architect is on hand, hiring an external company to do it will further streamline the project timeline. In about half the cases the requirements document is good enough anyway, so the architecture falls into place automatically later. It’s the agile way of “emerging architecture”, so this should not be a problem.
Expert tip: As the programmers do not have that much to do during the first two phases, sending them on holiday during that time might be a good idea. They will need their full energy when it goes to coding.
The third phase of Scaled Single Sprint Scrum is the implementation. Here the programmers finally get their uninterrupted coding time. Feel free to empower the teams by encouraging them to increase their focus-time by working in the evenings and on weekends. In Agile DevelopmentTM commitment is everything! Self motivation is another key factor for successful agile development, so isolating the team from any outside communication will help them with their motivation. It is a truly wonderful sight to see a team of coders growing so motivated that they barley get home to sleep in order to match the deadline.
A truly motivated and empowered programmerImage courtesy of pixaby
Customer collaboration through testing verification
Once the end of the “Large Sprint” occurs, it is testing verification time! True to the aspect of “cross functionality” all the programmers should stop coding here and focusing full time on testing. No excuses here. Be a T-Shaped employee and agile or be gone! T-Shaped stands of course for “Testing-Shaped”, a fancy way of saying that everybody should be fit to test the software for their own mistakes.
Experience shows that the implementation phase of a “Large Sprint” usually takes longer than anticipated, so cutting the verification phase short is the agile way to go. Focusing on “customer collaboration over contract negotiation” from the agile manifesto helps, as the customers should be reminded to collaborate by doing their share of testing verification.
Expert tip: During the “verification” phase is a good point to sell the customer the “Maintenance” sprint.
Scaled Single Sprint ScrumTM - The train to success
By rigorously applying the Scaled Single Sprint ScrumTM methodology even large projects are a breeze to do. Should your program be extra large and require even more effort, be sure to check out the Speeded-up Scaled Single Sprint frameworkTM.
Expert tip: Please check the date of publishing of this article if you really think of applying this method in your team!