During my experience working with multiple agile teams over the last few years, I have observed that many of them are waterfalling their Sprints. The worst part is that they are often not even aware of it as an issue and associated impact.
So, what is waterfalling the Sprint – When the team start a Sprint with set days for design and solution followed by specified days for development and finally few hours/days for the QA, each phase planned consecutively. Within the Sprint, items and phases of the work are planned as discrete siloed tasks and steps.
Why is waterfalling the Sprint a problem – Because it is more than likely that there will be some last-minute changes, issues, dependencies etc. leaving it to the last minute for validation, regression, delivery tasks etc., which makes it almost impossible to get the stories completed within the Sprint. This means most of the stories are not fully tested, let alone being rolled out to the production environment. Remaining items not completed as part of ‘definition of done’ will roll over to the next Sprint, becoming a loop where the team is bouncing between starting new tasks and fixing newly discovered defects in old items that team thought were done already.
Some of the common root causes are:
Lack of backlog refinement – This means teams commit to product backlog items that does not meet the agreed ‘definition of ready’ criteria. Then, team spend lot of time during the Sprint to finalise and understand the outstanding tasks which should have been done as part of the ‘definition of ready’ process.
Stories Are Not Decomposed – This happens when stories are not sliced correctly. Ideally, story should be broken down in such a way that it can be developed, tested and deployed independently.
The Team Is Working in Silos –Agile scrum teams are meant to be cross-functional, with the team being accountable for all aspects of the ‘how’ within a Sprint.
Focusing on output instead of outcome –Stories do not have any business value if ‘definition of done’ criteria is not met and can not be released to the customer.
How to avoid Waterfalling the Sprint –
Sprint Planning and ‘definition of ready’ – Any stories considered for the Sprint should meet the ‘definition of ready’ criteria which may include decomposition of the story, acceptance criteria, three amigo session, architectural solution understood & agreed.
Cut off period – It is worth agreeing a cut off time to freeze build work for items not started already and in case of in-progress items, not to merge the code to the main branch, let’s say two days prior to the Sprint end date. This would allow remaining activities like testing, validation, regression, business acceptance etc. to complete in accordance with agreed ‘definition of done’ criteria. I would only recommend this as a short-term solution until team adopt new ways of working and start delivering the stories or items every couple of days as this pattern itself can be termed as an anti-pattern. Obvious question may be asked as to what the developers will do in those last couple of days. They could start reviewing, working on the stories planned for the next Sprint as per backlog priority. They could even start build work in the local environment without compromising the current Sprint commitment and outcome.
Focus on finishing backlog items – This behaviour reinforces that the team collectively take ownership for all of the work within the Sprint be it pair programming, swarming behaviours etc. and focus on what matters most is ‘done items’ within the Sprint, not being busy. Ultimately, as per Agile Manifesto “Working Software is the primary measure of progress.”
Remember, it’s not all about implementing different Agile frameworks. It is important to assess if the framework and ways of working are helping teams and organisations to achieve tangible business outcomes like more innovation, predictability, transparency, mindset and trust culture.
