So the definition of done of a Scrum team is sick and you, dear agile coach, are intervening on the team to get them to fix it. Easy, isn’t it? Either you tackle the issue during a retrospective or on in ad-hoc discussion, point out the symptoms, ask the team how they plan to fix it, let them define the goals and a plan to achieve them. Sure easy, if you have the team within reach!
As part of my coaching activities I sometimes have ScrumMasters and Product Owners as customers that come to me individually: one ScrumMaster came to me telling me the definition of done in his team was obviously not working since several sprints. Major symptom was a high number of stories coming back into the backlog in the form of bug reports.
He addressed the problem during the retrospectives, but the team either ignored him or proposed solutions that did not address the root cause of the problem. There was no conflict among them, in fact the team spirit was fairly high, but still my client was not able to „move“ the team in the direction he deemed useful. On the contrary, they ended up layering more processes on the top of the previous ones, adding overhead and effectively decreasing the average velocity.
I had no jurisdiction on the team. In fact, they did not even know about me at all. I needed to trigger a change in the system’s behaviour: what could I do?
The experience made in family therapy by the likes of Virginia Satir, Steve de Shazer and the Milwaukee’s Brief Family Therapy Center is that, in fact, you don’t need to have the actual subject showing the symptoms present in a therapy or coaching session in order to inspire changes in a system, it is sufficient to search for differences – new behavioural options that have the chance of breaking the spiral of cause-effects that brought the system to such a dysfunctional situation. So there I go…
Through the standard set of systemic questions I could not expose a relevant difference to work on. In fact, we worked on those topics a few times already. So I decided to use a systemic constellation instead.
A systemic constellation is a tool to create a view of the system – i.e. the people involved in the specific situation but also goals, impediments and any actual or abstract entity that might be relevant in the discussion – by using representatives – i.e. either objects or people. In this case, not having additional people available, we used my objects, in particular my coaching army:
The client is responsible for putting the representatives in the position his perception suggests, thus creating the so-called problem scenario:
In this situation the representatives are asked appreciatively about their perceptions. In case the representatives are objects, as was the case in this example, the client is asked to put himself into the role of the representative and talk in its stead. This allows for a quick and efficient exploration of the point of views of all the relevant parts of the system, generating an insight that would be otherwise very difficult to gather.
From there, the coach, together with the client and – if they are persons and not objects – the representatives, transforms the represented system into a solution scenario, a situation where the problem is solved. The whole process is strictly solution-focused in order to let the client describe a solution that is compatible with the system’s constraints.
It took almost two hours to reach this scenario:
What happened there? As an observer of such a constellation it is difficult to appreciate the full details of what the client perceived through this exercise, especially not knowing personally the members of the team. My reading of the situation is that the ScrumMaster was a bit too obsessively trying to make the team change the definition of done and, through this, the established testing habits. As a result the team unconsciously blocked his efforts, though remaining very nice and friendly with the ScrumMaster. So while there was no explicit conflict to be detected, the system shunned the ScrumMaster’s opinions.
Using the things he learned during the session the ScrumMaster changed something in his approach to the team, mostly a different way to interact with them and being in general more supportive in all the Scrum Team’s activities. This caused the team to become more receptive to the ScrumMaster’s suggestions and, within a few days from the constellation work, brought the team to accept the idea of the definition of done not working properly. At the next retrospective the subject was finally on the agenda and changes were planned. Three 2-week sprints later the team is still improving its regression test system – technical root cause for the problems – and the amount of stories returning back is diminishing. At the same time they are removing from their processes all the useless procedures they added and the velocity is improving.