A fundamental aspect of Agile and scrum are self-organising teams. It sounds fairly self-evident, but what does that even mean? As it happens, Richard Hackman is the go-to guy in this arena, and he’s got some things to say about team organisation. Unfortunately, as with many of Agile’s precepts, the guidance is particularly vague. Although the founders were apparently familiar with the work of Hackman, they chose a term not in his framework. Mike Cohn supports the notion that self-organising equates to self-managing, so I’ll take that as the direction to take.
According to Hackman, there is a spectrum from command-and-control, manager-led teams to autonomous, self-governing teams. Sandwiched between are self-managing teams and self-designing teams.
Manager-led Teams
I think it’s safe to posit that we are all familiar with manager-led teams. In my experience, most Agile teams are in practice manager-led teams on a short leash, but we’ll get to that once we define the other categories. Reflecting on Hackman’s matrix, the manager sets the overall team direction, designs the team and its organisational context, and manages and monitors work processes and progress. The team is left to execute the tasks at hand.
Self-Managing Teams
If we are to take Mike Cohn at face value, this is where Agile sits. Management still sets the overall direction of the team and its goals, but it also designs the team and its organisational context. This translates into choosing the team size and its members. The team is still responsible for execution, but it gains the ability to monitor and manage its work processes. Let’s come back to this after we look at the last two categories.
Self-Designing Teams
In the case of self-designing teams, besides being responsible for executing whatever tasks and managing the processes, these teams get to choose who is on the team and how to organise it. Management still provides overall direction.
Self-Governing Teams
Self-governing teams are not likely to exist within an organisation. These are likely to be the organisation iteslf, as they have full autonomy of everything including the charter and direction of the team. This might be a group of founders who can decide that they want to manufacture typewriters instead of buggy whips whilst having the power to choose other team members and its operating model. In the end, they may devolve back into a command-and-control model, but that’s beyond the scope of this piece.
Self-Organising Teams
Let’s return to self-managing teams. First, let’s disavow ourselves that this team is solely responsible for monitoring and managing work processes and progress. What otherwise proclaimed self-organising team doesn’t have some management breathing down their neck with instruction to go faster, produce more, and what have you? So I find this one to be a bit disingenuous.
Controlling the process feels a bit wonky, too. What this effectively means is that the team can choose to be scrum or Kanban. In fact, they can choose to do traditional waterfall to deliver their remit. And there’s an issue of scope as well. Agile gives the team the authority or permission to be self-organising. If they choose to do something other than Agile—if they even have the leeway to choose scrum or Kanban—does that mean they lose that authority? It feels like a traditional set theory challenge. Let’s see what Kurt Gödel has to say about the matter.
Closing
What is your experience with self-organising teams? Do you have the latitude suggested by Hackman, or are you being cheated? In my experience, this latitude is not granted. The process is dictated from on high. However, I have been on teams with the authority to vote team members off the island and seek a replacement. This is taking some authority from the adjacent right side of the matrix and ceding some to the left.
In the end, I have not found Agile teams to be materially self-organising. A training article suggests that it’s a process, not a destination. Because of course it is. Zeno’s paradox 101.