Our book about Valuable Agile Retrospectives has been published!
Retrospectives bring benefits to Agile teams, they help them to improve and deliver value to their customers and the company. This first article in the series Retrospective Benefits explores how you can benefit from retrospectives, by getting improvement actions that will be done by the agile team.
The opportunities that a team takes (for instance by doing retrospectives) to reflect upon how they use Scrum, and how they adapt their way of working is one of the success factors for using Scrum and getting benefits out of it. Retrospectives help Scrum Masters and the team to do short cycled improvements by observing how they work, and change the things that can be done better.
Actions by the team, for the team
In my retrospectives I look for improvement actions within the agile team, that’s actions that team members can do themselves. Team are self steering, which means that they have the power to change the way they work (their process). If they want to try a different way of working, it’s up to them to give feedback to each other, discuss what happened, to learn, and decide what to do. The team defines the actions that they want to do in a next sprint to solve issues that they had with the last sprint, to work more efficient or effective, or to deliver more business value to their customers. To put it stronger, they are the only ones who can change how they do their work, nobody else can change a self steering team!
Many of the findings in the retrospectives that I facilitate have to do with how people collaborate and communication, and with their soft skills. Yes, soft skills matter in IT and software developers and testers are human and can communicate, but just like everybody they sometimes have misunderstandings, were unclear about something, or didn’t hear things. There are different retrospective techniques that can be used to explore and create an understanding of communication and collaboration issues. Coaching and mentoring helps them to see where things went wrong, and to help teams to improve.
Involve the Product Owner
If there are issues that are for instance related to the backlog, sprint planning, or have to do with interaction with users, I recommend the team to invite the product owner in their retrospective, and if needed the customers of the team. Together they can discuss and explore the issues, and define actions to solve them and improve their collaboration.
Teams sometimes come up with actions where they want to change the way that they collaborate and communicate with current and future users. Often they also want that users change the way they interact with the team. I tell teams that it is up to the users the change their behavior if they discover that that would be more effective, and not for the team to decide. This doesn’t always make me a popular guy (which doesn’t worry, I have enough fans left which like me anyway ), but this is how it works. You cannot change people, people can only change themselves! Team members can agree how they will change, but not dictate what other people have to do. Most often change triggers change, so let the action start in the team, and watch how it influence the users. Have some patience, it usually works :-).
When I started with agile retrospectives, I had some discussion with colleagues on why we should do them. We were already doing project evaluations, so where do retrospectives differ, what would be the benefit of doing them? One of the main differences is that agile retrospectives focus on the team, and not on the organization. Most project evaluation investigate what happened in the project, and will come up with changes that should be done either in the organization, or in future projects, in stead of defining actions for the project that is being investigated, or the project team. Which is logical, given that most project evaluation is done at the end of the project; there’s not much that can be changed in the project anymore.
To have the actions from a project evaluation done, a hand-over is needed from the project team that did the evaluation to another project team or people responsible in the organization for improvement. In an agile retrospective, there is no hand-over: The team members will analyze what happened, define the actions, and do them. This is much more effective, and also faster and cheaper :-).
Actions by the team, a retrospective benefits
Agile retrospectives help to uncover better ways to do process improvement, since they focus on the people and not on the organization. Team member define their own actions in the retrospective, and do them in the next sprint. By doing that they are becoming Agile and Lean. The journey, where teams learn and improve continuously is more important then the destination.