“NO user stories were completed this sprint as we ran out of time!!!” Sound familiar?
The most common reason for user stories not getting completed during a sprint is that the “testing team did not have enough time to complete the testing” or the “Dev teams gave the QA teams very short time to test everything”.
Waterfall Hangover!!!
Waterfall Hangover is the mindset of individuals and teams that revert back to the waterfall process during a Sprint or a Scrum project.
What’s is described above is a classical case of waterfall hangover, where you end up creating mini waterfalls in your sprint. Waterfall is like a relay race where one team passes the work on to the next and the next till the project is delivered. A lot of teams take the “waterfall hangover” into a sprint and work in silos of development teams and test teams. In this scenario the development team barely gives the test teams enough time to test. Least to say this causes a lot of stress, work overload, bad quality and a failed sprint.
Other impacts of the waterfall hangover
« Silo’ed teams (Us vs. Them)
« Lower quality as test teams cut corners to try and make the “Sprint Date” milestone
« No cross training and exacerbating the silos
« Scrum Master becomes a pseudo project managers
« Sprint Planning is not done as a team but is done in silos, or the team lead does the planning for the team
« Stand up meeting morphs into a status meetings
« Since the teams are not leveraging the basic tenets of Scrum and not working as one team that can “swarm” to get the highest priority user stories done first
There are a couple of ways to deal with this Issue.
1: Team/Organization new to Scrum and moving from Waterfall to Scrum
« Start with cross training as soon as possible, use pair programing, formal training and getting an SME to work with the team
« DO NOT start working on all user stories in parallel but work in priority
« Start with the completing the highest priority user stories first and then working down the list to the lowest priority user story in the Sprint Backlog
« As soon as the Development has done working on the first user story they can hand it over to test, so that the work load for test is now balanced and the team is team work is optimized
« In this scenario the test team members may have some “spare” time in the beginning of the sprint, they can use this time to cross train leveraging pair programming, writing automated test cases, automated regression testing etc.
« Though this process still creates a mini-water fall within your sprint but the test teams are overloaded towards the end of the sprint
2: Team with an intermediate understanding of Scrum and is partially cross trained
« The team should keep on working on cross training
« The team should start “swarming” to get the highest priority user stories done first
« The team should start getting away from the mini waterfall process and start working towards continuous integrating and testing
3: The team is hyper-productive and understands the principles of a scrum
« This is the stage that most teams aspire to achieve
« They should be leveraging the principles of Scrum which will include the following
« Team swarming to get the highest user story done first and then go down the priority list of user stories in the Sprint Backlog
« Leverage and integrate continuous integration,testing,regression and deployment
The corner stone for the success for this to happen would be the following:
« The organization support and patience for the teams to get to this point
« It takes time to create and nurture high performing teams
« Transparency within the team on skill set and abilities
« Individuals taking ownership on learning new skills so that they help the team succeed
« Having an open discussion either during the retrospective or some other forum on how to deliver a better product faster and isolate areas of improvement for both the team and the organization
Waterfall Hangover is a very common pitfall for most teams, this happens because our ‘organizational process immunity’ kicks-in and we go back to what we know and understand best.
Retrospective
What I listed above are some of the steps you can take to achieve higher success rate within your sprints. One you take these steps it important to follow it up with inspecting how the experiment went and then based on the results adapt/refine/alter you way forward. It is imperative that you do the inspect and adapt cycle on the process efficacy as well.
A team could also have a prioritized list of actions that they need to take to become a better team. Each sprint the team could take one of these items and try and
introduce it in the team and the review the impact at the retrospective. This “process/team improvement Backlog” can be deployed into the team incrementally.
If you liked this article join our mailing list for more such articles or attend one of our upcoming classes.
Know anyone interested in becoming a Certified Scrum Master ?