One of the challenges of an Agile Coach, or anyone in a management or leadership role is establishing what I have seen referred to as the “zone of acceptance” for individual team members.
The Zone of Acceptance is a term for the tasks an individual sees as something they are prepared to do as part of their job. This can relate to tasks, overtime, meeting attendance and more.
In a traditional model where work is explicitly assigned, this took the form of a team member saying “that’s not my job” when asked to do something on the periphery of their role. E.g. being asked to write documentation or attend a meeting outside core hours. This is a confrontation that can be handled directly, the team member can be coached to broaden the scope of their ‘zone of acceptance’ and have it explained that sometimes responsibilities extend beyond core hours or core responsibilities.
However, when you move to agile it becomes much harder to deal with.
As an aside, in my house I will sometimes come home to find the kitchen bin full or overflowing, if I ask why it has been left like that my wife with very matter of fact reply – That’s your job. I don’t doubt that it is, but it is a hard line, if I want to challenge it I can, the responsibility is clear. But conversely my behaviour in a different situation is far harder to manage. My wife may ask me to change our daughter’s nappy (or diaper as my wife calls it), I will generally willingly comply, but I very rarely volunteer. I would never say it is not my job, but by subtly avoiding doing it I am implicitly saying so. She can ask on a regular basis but that in itself undermines the equality and self-organising nature of marriage. The reality is that she is not asking me to take responsibility, nor is she demanding assistance, but my help is appreciated. What I need is to broaden my ‘zone of acceptance’ and to be more proactive in my support.
The same becomes true in a Scrum team, if I were to hear someone say ‘that’s not my job’ or “I’ll hand that to a tester” or similar comments, they can be challenged. But far more common is seeing the team members forming natural silos for work, an often agreed line in the sand where work is divided and not challenged. They will avoid tasks they are not interested in or don’t see as their role, find excuses for working on tasks they see as theirs and in some extreme cases work on something outside the Sprint to avoid picking up a task that doesn’t fall into their zone of acceptance. This behaviour may not even be visible, a Scrum team can actually be very productive forming mini-silos, but that doesn’t make it right.
I see the role of a Scrum Master to challenge these silos, to encourage team members to broaden their zone of acceptance, and to get the team to inwardly think that it is their responsibility to get involved in Story writing, and coding and testing and be active in meetings, to volunteer to write documentation and present the Sprint Review, and to challenge those that don’t.
“But I’m a tester I don’t know how to code” – is a common argument. My response – “So what!” a lot of coders I know would benefit very much from having a tester on their shoulder asking if they had considered this case or that case, challenging the use of TDD and actively engaging in what and why things are being coded even if they don’t understand the code itself. And perhaps more controversially the opposite is true, having a developer sit on the shoulder of a tester and see what and how and why certain tests are performed can help improve the way a developer writes code. I think we can make passable testers of most developers and vice versa, teams should want to challenge boundaries.
By this I am by no means suggesting that we create a team of jack of all trades – I am actually very much against that, expertise should be encouraged and my view is that testing and development are very different skills and expertise in either should be valued. But my view is that the comparison of skills needed for a sprint will often form a huge amount of overlap. If a product or sprint is a puzzle, chances are that there are a few parts that require specialist ‘Blue’ or expertise in ‘Red’ skills but the majority of the work is shades of ‘purple’ something that does not require expertise in either.
But now what? We understand the problem, we know it is hard to spot and hard to challenge, so how do we expand the zone of acceptance?
The first step is nearly always acknowledging there is a problem. Discuss it with the team – maybe as part of a retrospective and see if they recognise it as a problem. Let the team find ways to solve the problem. Once they see themselves as a team it becomes easier as they will be seeking ways to help each other rather than for the easy way out.
One team I work with identified this themselves and their solution was to put a sign on their task board that said: “Have I done this before?” And another sign that said “Is this on the critical path?”
The idea was that when selecting a task to do the team member would stop and think: First whether they were taking a task that someone else could take and learn that task – or maybe they could pair and teach someone else; and secondly is this the next best task for the sprint or am I taking an easy option? It is a written reminder and a challenge, and a challenge I’d encourage the other team members to make.
This barely touches the surface of this particular problem, and I’ll no doubt come back to it, but there should be a desire by the individuals on a team to (sensibly) broaden their zone of acceptance, for the focus to shift from what is the next best(or easiest) task for me to what is the next best task for the team. And more significantly for this to be supported and encouraged by the team; the Scrum Master and the organisation.
John Yorke 