In an ideal world agile teams are working with one product owner or customer. As a cross-disciplinary team they self-organize their work and reflect at the end of the iteration with an agile retrospective where they decide as a team what they want to improve in the next iteration.
But there are also teams which have more than one customer, maybe even multiple product owners. Due to that all the team members are often not working together on a daily base. Depending on the customers, team members might use different processes and have specific acceptance criteria and Definitions of Done. Is it useful for such teams to do a retrospective together? How can they define actions that will be beneficial for the complete team?
Question on doing Retrospectives
Question. I’m in a team where eight developers have different customers and semi-different processes. Yet..(1/2)
Some things we share (build env., Kanban board). How to get to actions in a retrospective that benefit all?
First, I think this is a great question! I have also had several teams in similar situations. Some teams even had team members working in multiple projects where each project had different stakeholders. Under such circumstances it’s hard to become a team, and even harder to find effective ways for teams to to improve themselves.
Finding retrospective actions that benefit all
An agile retrospective, or sprint retrospective as Scrum calls it, is a practice used by teams to reflect on their way of working and to continuously become better in what they do. One purpose of the retrospective meeting is to agree upon the improvement actions that teams will do in their next iteration.
A great question as the one above deserves great answers. As a service to our readers I tweeted 5 suggestions that can be used to do valuable agile retrospectives with teams that have multiple customers:
- Focus on problems that multiple team members have to find actions that team members can do together to solve the problems.
- Explore the strengths of the individual team members and find ways that they can help each other in the daily work using these strengths.
- Use a (family) constellation exercise to see how team members and stakeholder co-operate (also one of the retrospective exercises mentioned in Getting Business Value out of Agile Retrospectives).
- After the team has done some retrospectives, do a Retrospective of Retrospectives to share learnings between team members.
- Give everybody team member a copy of our book, and ask them which exercise they want to do 🙂
(I agree, the 5th suggestion is not really a suggestion. If you use it, then you are obliged to help the teams when doing retrospectives or arrange for somebody who helps them 🙂 ).
When you do retrospectives in a team working with multiple customers then common problems may become visible: problems that most (or all) team members have. Chances are big that some of the causes of these problems are outside the team, having to do with the organizational structure, policies, management styles or culture. Team stability might also be an issue if many stakeholders are involved. It could be useful to do a 5 times why retrospective to created a shared understanding of the root causes. And to define actions that would involve the team members and people supporting the team to collaboratively solve the problems.
Learn to do Valuable Agile Retrospectives
The suggestions mentioned above are described in our book about Valuable Agile Retrospectives. This book contains many exercises that you can use to facilitate retrospectives and advice for introducing and improving retrospectives.
There’s an online community for the readers of our book and you can also subscribe yourself to the Valuable Agile Retrospectives mailing list to stay up to date on new retrospective exercises, experiences with retrospectives, and advice on how can do them.
Do you have a question about retrospectives? All you have to do is ask your agile retrospective question :-).