You have completed a few Sprint cycles in the past 5 months, in your project execution to deliver a project or a product. Your features are almost 50% complete. You have yet another 5 sprints to go. Your sprint cycles are of 1 month each. The team is at the peak of its performance. However you realize there are still a few hiccups when it comes down to the sprint closure date, where each team feels pressurized due to the dependencies they have on the other teams.
You may think of certain assumptions when we talk of Agile Scrum.
The Sprints are ideally of 2 weeks duration.
Product Management is 1 Sprint ahead.
Development is in the current sprint.
Functional and Automation QA is 1 sprint behind.
This is usually true for a 2 week Sprint. But these assumptions might not be applicable to all scenarios.
There are projects that run on 4 weeks (1 month) sprints, where the deliverables are significant. It is unpractical to have the product owner to be ahead by a month, while the QA cannot afford to stay behind the Sprint by 1 month. It is imperative to have all the three key areas to be in the same sprint. With a slight difference that the product owner is a couple of weeks ahead, while the QA is catching up with the Automation, System, Accessibility and Internationalization Testing in the first 2 weeks; while waiting for Development team to deliver the features in the 3rd week of the Sprint to have sufficient time to test the features going in that Sprint.
However, as it happens in all projects, things don’t go as planned. There are multiple iterations while finalizing the flow or the User Interfaces because the customer had different ideas about a particular feature. (Here again, you cannot prevent the customer from intervening during the course of the Sprint). Though certain stories can move to the next Sprint. There are a couple of features that the customer is really interested to see in the demo. Development team puts in all the efforts to deliver the story on time. Still it causes delay in providing the features to the QA team.
QA team chokes in testing the features but manages to deliver it just before the demo. You, as a scrum master are continuously tracking the plethora of activities happening all around you. The team is glad that they could make it. But still there is room for improvement. But this improvement in not in terms of the typical scrum areas that we hear of. You have got an issue of having ‘mini-waterfalls’ in your sprints.
The solution to such a problem is not as simple as changing the sprint cycles drastically or moving the scope to next sprints. What needs to be worked on is how the team can collaborate more effectively.
Here, though the product owner cannot help the changes coming in from the customer, he/she can work closely with the scrum master to ensure that high priority features are addressed earlier for the customer. The business owner cannot eliminate the iterations completely using a magic wand, but can minimize the iterations by working in collaboration with the customer.
Meanwhile, it does well with the development team to closely be in touch with the product owner. The team could also benefit by collaborating the development and testing effort either by pairing up and incrementally testing the features that are code checked-in piece by piece by the developer OR by being aware of the changes that are being incorporated in the features by the developer.
In order for all this to work, it needs collaboration across the teams. This does not mean that the collaboration was missing earlier. It only means fine tuning certain traits between the scrum master, product owner, the developers and the QA team… and the scrum master can facilitate this, so that things work out better for the whole team and for the overall delivery of the product or project.