Successful distributed agile projects can be attributed to supportive sponsors who understand the nuances of software projects and collaborative teams that define and refine a methodology that suits their project context. Sometimes stakeholders perceive agile as the remedy or silver bullet and expect the best results. This blog is on what to expect from the first Sprint of any distributed agile project.
Interestingly, the first Sprint of any project is as memorable and exciting as the first stage performance of a music band. Music bands make sure that there is someone who works with the team, coordinates, facilitates and sometime coaches on need basis. They make sure that the right infrastructure is in place. They use state-of-the-art instruments and tools that they are conversant with. They include songs that are popular and they select songs that can be played with ease and have fun. They do not introduce extra songs at the last minute. Also, they do not introduce new artists in their team once they freeze their plan. Above all, they get strong support and encouragement from sponsors.
Distributed agile teams need to plan for one or two collocated Sprints during the initial stages. This is one of the critical success factors called ‘Setting up the Base Camp‘. Obviously, every team needs a Scrum Master. Also, agile teams need to make sure that engineers have the right infrastructure and tools.
The Product Owner and Scrum Master need to collaborate with project team in selecting architecturally significant user stories as well as user stories that can demonstrate one or two popular features in the first Sprint of agile development. Also, it is good to include stories that the team can implement with ease. At the same time, it is good to stay away from complex users stories that can derail the first Sprint. Scrum teams can never afford to include new stories after Sprint planning is over. This is pertinent to the first Sprint as well as subsequent Sprints. As the Scrum team progresses over the first few Sprints it can refine the policy to handle scope changes.
It is a good practice to form the team before starting the first Sprint and keep going. Any change in team composition during the Sprint can impact deliverables.
Finally, Scrum teams, like any project teams, require strong support from project sponsors. A right mix of appreciation and constructive feedback is required to ensure positive reinforcement among team members. In Scrum teams, the rhythm of delivering working code sets in over the first three or four iterations. This is when team members need to apply continuous improvements and fine tune the way they create software.
So, expecting the best results in your first Sprint is optimistic as well as ideal whereas the willingness to accept mixed outcomes and supporting your team in progressing over the first three or four iterations is essential.
Music bands have the privilege of rehearsing several times to deliver a high quality performance. Scrum teams have the privilege of doing adequate testing within the Sprint to ensure quality. Music bands that top the list are the ones who make the right impact on their debut. Scrum teams that perform successfully are the ones who inspect and adapt as they move on.
We trust engineers who come together as a team to deliver their best in the first iteration or Sprint. Iterations progress as the team inspects and adapts. We have seen this happening in several projects! So, it is imperative to be patient, appreciative, and responsive with constructive feedback and let the iterations progress.