Ever find that at retrospectives, the team are talking about things that happen outside of the team that affect them?
I once worked with a team, for whom, retrospective after retrospective, the problems the team wanted to highlight or talk about were how other people/teams/the organisation were causing the problems they faced. Of course, because all these problems were due to ‘external’ factors’, there appeared to be very little we could do as a team. This situation occurred time and time again turned into a vicious circle for the team.
Spheres of Influence
Around that time, I came across the concept of spheres of influence. ‘Spheres of influence’ was a term originally used by empires and imperialistic countries to talk about areas of the world they controlled and influenced. While that is still occuring today, the term is used a lot more commonly to explain similar concepts.
So, looking at the picture, we can see three zones.
The Sphere of Control is where things that we are in control of reside.For example, doing peer reviews of code we write as a team. The Sphere of Influence is where we have more things that we may not have control over, but which we have the ability to influence and have a say in. The organisation’s coding standards and build procedures may be an example of this. The third and outermost zone is everything else in the world. It’s stuff we have no control over and cannot influence. Earthquakes, meteors hitting the planet, teams in other business units, that kind of stuff.
Coming back to retrospectives, if you find yourself or your team in a tailspin around all the things that are outside your control and having a significant impact as the focal points of the conversations, it might be time to take a break from it. Refocus the team and yourself around areas of improvement that are either in your control or those which you may be able to influence. Get positive movement on those pieces and build positive momentum within that team. This will help the team get out of a rut, prevent feelings of frustration and helplessness to seep in and make the team feel more empowered.
What happens to all the things outside our control?
My response to that was to use the Sprint Review. In the Scrum Guide the second key element of the sprint review is
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;https://scrumguides.org/scrum-guide.html#events-review
The development team discusses what problems they ran into, and how they were solved. Here, maybe the team discuss how these problems were not being solved because they were outside the team’s sphere of control and influence. One would expect that within the group of stakeholders that are present at the team’s review, the problems happen to be in their sphere of influence and control. The review will highlight the impact of these problems, and hopefully these stakeholders can help resolve the issues experienced by the team.
Assuming you have a retrospective board full of post-it notes that represented the problems faced by the team.
On a second board or on a table, draw the spheres of influence map. Explain the map and the meanings to the team, and ask them to start placing all the post-it notes into one of the three different zones on the map.
It will allow you to focus the conversation with the team on the items in their control. You may even get insights on what can be done for the items that are within the team’s sphere of influence. For those items outside the influence of the team, maybe it’s time to bring those problems to the agile leaders in the organisation.