Project development through sprints is done by a series of iterations that divide the work into tasks to be completed in short periods of time. Many Developers that are familiar with sprints recognise that this methodology helps to deliver a better quality software with fewer headaches.
But an Agile Sprint development is also prone to go wrong, and instead of reducing the headache it can create a major migraine! Then, how can we make sure that this methodology will help us develop the best products?
I have had the pleasure of experiencing development through sprints and fortunately things have been working out well. So, I’ve decided to stop for a while to reflect on why they do well when it could have been the other way, especially as a team when facing more challenging sprints.
The key to successful delivery.
In my perspective, there are two determinant factors to a successful sprint:
- Teamwork and collaboration
- Communication in the development team and with stakeholders.
And there are secrets to a healthy and efficient sprint development team:
A sprint is composed by several ceremonies during its execution which are essential meetings for planning and refinement as a team, and it’s a common mistake among Developers to mechanise their attitude towards these ceremonies and not take advantage of them, damaging not only their performance. but also the other members of the team.
Sprint planning for sprint quality.
Sprint planning meetings are essential to a good workload distribution during the sprint. Still, it’s important to bear in mind that as a team, some of those projections will be wrong. Improving the quality of sprint planning is an iterative work that will become more precise and correct over time.
This means that only after some sprints will the team realize their speed and delivery ability. It’s important to stress that planning is a major team responsibility. It’s the team that decides what is included in the sprint, not just the Product Owner.
The team should manage the PO expectations according to its capabilities, always stressing that if the sprint ends up in advance, the development of the following sprints will also start sooner.
Sprint is a priority.
You need to be aware that the delivery of the sprint is the top priority and that sometimes this will require more effort than expected. This should not be seen as something negative, rather than something you should always keep in mind.
The team’s availability and mutual help are essential; If we are aware of the sprint as a whole and not just the tasks that are assigned to us, this will come naturally, and the work flows better. Consequently, problems that were not foreseen are mitigated and avoid the “death” of the sprint.
Ideally, the sprint backlog doesn’t change. However, this can’t be a limitation for the team. If a higher priority issue suddenly comes up, the team must be available to talk to the PO and analyze the complexity of the item to fit it into the sprint, while deciding if the remaining backlog is to maintain or not.
Copyright from Pexels.
Dailies and burndown-chart.
To ensure that this awareness of the sprint as a whole exists, daily meetings are crucial. This means that the entire team must report on the status of their development, discussing current issues or concerns, but also situations where tasks were completed faster than estimated, making themselves available to help those who need it.
It is this type of communication that generates mutual help without compromising anyone’s work, and it is as simple as being aware that communication is as important as knowing how to develop.
Consulting the daily burndown-chart provides a visual interpretation of what I just described, giving us notion of the current state of the sprint. This can be the trigger for discussing possible solutions to maintain the sprint integrity.
The cherry on top: the Agile Retrospective.
This is one of the phases that team members most easily ignore because it doesn’t seem to make a difference in the quality of the sprint. However, from my perspective, the Sprint retrospective is one of the most important meetings.
As I mentioned above, if the sprint requires a different effort than expected, that should serve as a future example. It is in retrospective that communication is most valuable to the team.
Retrospectives are done at the end of the sprint. It is during this meeting that each team member should communicate:
- what went well, so that it can be replicated in the next sprint;
- what should be improved;
- and what must not be repeated.
The team should use this time to express what caused them the most difficulty during the Sprint, in order to plan practical solutions for the necessary refinement of the team’s work.
But the objective of the retrospective shouldn’t be to only mention everything that went wrong. The ability to identify what was the key element for something to go well or being successfully completed is equally important for the team’s awareness of its organization, attitude, and effectiveness.
If all the team members consider this quick meeting at the end of the sprint as an essential tool for their growth, not only do we move to the next sprint with the strength to continue, but we also avoid piling up frustrations that could compromise our dedication.
In short, I can definitely say that after a year and a half working through Sprints (and everything not always went well), the real secret to achieving success is to communicate. It’s being aware of the team as a whole and having the work done and dedicate our attention to the sprint.
But it’s also essential to trust the people you work with every day. Challenges will always be there, but iterations are not only about the project as much as the team and its dynamics.
Software Developer at Polarising
Contact us to know more about Agile Services.