Update: I got some comments regarding this post that made me realise I was a victim of bias when writing it. It might seem I am arguing for an isolation of the developers. Absolutely not: anybody who heard me on the topic knows I am an advocate of direct communication between developers and stakeholders. This is, in fact, one of the core ideas of agility, and it has a crucial impact on motivation, quality of the outcome, people’s happiness, purpose and many other aspects related to that social activity called product development. I take that for a fundamental assumption of an effective modern product development, agile or not.
The point of this post is that while, on the one hand, we need open collaboration, it is essential for the team to be able to self-organise their way to success. For example, the Scrum Guide (2020 edition, end of page 8) is very clear here: “No one else tells them how to turn Product Backlog items into Increments of value”.
So, while the “what to do” is the subject of interaction with all relevant stakeholders (in all possible interpretations of “relevant”!), the “how to do it”, including the technical and the process decisions during the Sprint, is where I suggest the team should be the only responsible for what happens in the sprint.
One might argue that, yes, the team can go on with their own sprint. We just observe. The problem is that in human systems, there is no such thing as a neutral observer. Every “observer” influences and is influenced by the system being observed. Here are some interesting readings for the eager learners: https://link.springer.com/chapter/10.1007/978-0-387-35941-0_2 and https://wisdomtrove.com/the-observer-effect-the-observed-cannot-exist-independently-of-the-observer-quotes/. Verbal and non-verbal remarks, as well as the simple act of being there, do have an impact on how the team works and their capability of self-managing. Furthermore, stakeholders are not neutral observers – it’s already in their name: they have stakes in that development! – which makes observers even more part of the system and, as such, influences the developers.
So, interact on the “what”, don’t look at the “how”, and just enjoy the result…
Here’s the original post, to be read with the previous comment in mind…
======
Otto von Bismarck is often credited with the sentence “Laws are Like Sausages. Better Not to See Them Being Made”, though the quote might really be from John Godfrey Saxe (https://quoteinvestigator.com/2010/07/08/laws-sausages/). While he might have been cynical when expressing this concept, I see it from a slightly different perspective: there is a process in producing a sausage and creating a law that might be messy and not nice to watch, but, in a sense, the result is what counts: it is a good law? Is it a tasty sausage? If they are, then we might improve the process, but we should still celebrate the result if good or hate it if bad. In the context of an agile team, this is highly relevant: I see very often, almost daily, managers who look into what the team does daily, as if the developers need constant surveillance and… you guessed it, control!
This behaviour has, obviously, a huge impact on the Team’s life. Here are three things to consider:
1. Autonomy and Competence
In the context of the Self-Determination Theory, Deci and Ryan have found that people need Autonomy, Competence and Relatedness to be motivated. A manager permanently looking over their shoulders will definitely make them feel less autonomous.
If the “watchdogs“ tend to impose their opinions or even impose decisions on the team, then the feeling of being Competent will suffer. And this happens, in my experience, even when the managers are friendly and collaborative: it’s not about the style. It’s about the interaction itself.
My suggestion to managers of agile teams is to be available, be open and receptive to their needs, but let them work.
2. Accountability as Motivator
The whole team should be accountable for the results. If somebody, be it a manager or any other stakeholder, constantly look into the sprint’s activities, they are bound to have an impact on the team’s life.
Some examples:
- Product Owners constantly changing priorities
- Stakeholders asking the developers for something different and, usually, very urgent
- Architects, analysts and many other roles tell the team what to do without being committed to the sprint.
These behaviours reduce the team’s accountability, hence de-committing the people from the work.
3. The importance of owning a goal
The team’s original commitment at the beginning of the sprint becomes less important and relevant with more external influences. Slowly but steadily, reaching the Sprint Goal is not a priority anymore.
So, my suggestion to all stakeholders of a Scrum Team is to stay out of the way and let the team work. Consider the Sprint as a black box. Look at the result, not at what happens inside. The more you stay out, the better!
The only exception is the Product Owner: while part of the Scrum Team, from the perspective of considering the Sprint as a black box, I recommend they behave as any other stakeholder: stay out of the way. But be genuinely available in case the Team needs you!
Revising the quote…
To express all this more compactly, I came up with my own updated version of Otto Bismark’s (or John Godfrey Saxe) quote:
”Laws and Sprints are Like Sausages. Better Not to See Them Being Made”. 🙂