I love the notion of self-organising teams, the belief that if left alone the team will pull together and solve the problem at hand. I also love the notion that a team doesn’t need named roles and that a team should be multi-skilled and can and will do any and all tasks necessary to deliver the work. As a model this does work, I have seen some great teams that can and do achieve this. But I don’t think this is the norm. There are certain foundations necessary for this model to work and for far too many teams they don’t have the necessary pre-requisites.
The team must have (or have readily available access to) all the skills.
The first is to have ALL the necessary skills on the team. Which may sound obvious, but when arranging and staffing teams we will generally ensure that a couple of the core skills are present and overlook or underestimate the importance of other skills. Or some of the other necessary skills are a lot less tangible and quantifiable, ‘softer’ skills, so we trivialise or undervalue them, when actually those less defined skills are likely to be the ones that mean the difference between getting by and excelling.
I doubt many question the claim that a software developer is a specialist skill, many people can have a go at coding but most serious products require a deeper level of understanding of the code than a casual understanding. I personally believe that the role of QA is similar, many can do the basics and run test cases, but a QA is a specialist skill and those gifted at it possess a perception that few developers even grasp let alone can mimic, they see a problem differently, a Dev tends to see a solution, a QA will see how it might fail.
Similarly with design, few Devs could design their way our of a paper bag, interfaces designed by engineers must give designers nightmares. I have seen engineer designs where every function of the system is displayed on one page giving a casual software tool the appearance of a complex flight control interface. That’s not to say that some Devs don’t have design skills, but generally they are lacking. And then there is Product Ownership – the term for a collection of tasks and skills that I feel is generally drastically underestimated and a skill set that is rare in your typical Dev. In my opinion it is potentially more specialized than that of a developer or QA, and is rarer to find on a typical team composed of Devs and QAs. (Named roles or otherwise)
Drawing the expected value out of a customer or stakeholder and verbalising it, is a skill, translating that into a story can be time consuming and painful, but when done right the Devs can fly and the stakeholders are happy. When done badly the developers churn and the stakeholders grow frustrated. Product Ownership is the vanguard of Agile software development. Being able to articulate a clear vision, and present unambiguous goals and priorities, to write stories that express the value of the work without imposing a solution on the Devs can mean the difference between a goo and a great product.
To do all this requires someone that can communicate effectively with the customer and stakeholders and then transfer that information clearly and effectively to the team, to ensure that the customer is clear on priorities and is happy with the progress requires soft skills that are not at all common. This is an extremely difficult set of skills to master. To simply assume that a team will inherently possess the skills necessary to fulfil this role amongst themselves is inviting disaster. To assume that the customer is clear on their intent or direction and can express that need to developers who may not possess the experience or will to probe and challenge to identify the true need is simply inviting disaster. Product ownership skills and experience is not an automatic side effect of being a Dev – far from it.
The team must be motivated to do any of the necessary tasks.
And secondly there is Human Nature. This may be seen as a generalization and it is a generalization that I have been trying for years to break, and to be fair there are some team members that do manage to evolve beyond their labels and become more cross-functional team members. Many will take on tasks relating to DevOps or DBA or even some of the other core skills on a team such as Design and QA but, BUT…
What I find more often than not is that if people are left to their own devices: Devs want to code, QAs want to test, Designers want to design and NOBODY wants to do documentation, administration, or talk to stakeholders or to integrate other people’s code. Maybe an over generalisation, but not too far off the mark.
The result..
And of course the whole point of self-organising teams is that they ARE left to their own devices. So we have a bunch of self-organising teams that have a mix of being unable or unwilling to do all of the tasks necessary to deliver the product. Obviously some do muddle through and when push comes to shove they will step up and get the job done. But many just don’t want to and will either leave it to others meaning that the more ‘Agile’ team members get all the crap jobs, or more commonly I seem teams finding ways to stay busy to avoid doing the tasks they don’t like or facing the problems the team would have if they actually confronted them.
In the book the Lord of the Flies, there is a goal – a signal fire, but the boys become busy and preoccupied with the more interesting tasks and having fun, thus neglecting the fire.
I see non-urgent (and not prioritized) features getting worked on, scope creeps all the time. The ‘build process’ becomes gold plated, and the team starts a whole bunch of ‘spikes’ that take far longer than should be expected. Everyone is ‘busy’ but no one is delivering value (nobody is tending the fire). All because the team is subtly, maybe subconsciously avoiding tasks they don’t like or don’t feel they are able to do. This may sound harsh, but I have seen this behaviour far more often that I would care to count.
So do I advocate self-organized teams? Do I advocate named roles in teams?
In my experience Product Ownership requires skill and dedication. Assuming a team possesses it simply as an after thought or assuming it is a secondary role is very damaging. For a newly formed team/project someone skilled in Product Ownership should be primarily focused on that.(Not necessarily in a named role, but certainly specifically assigned the responsibility). But that assumes there is someone on the team who possesses those skills.
It should be part of the responsibilities of that role to spread that knowledge and share those skills to avoid creating a silo – (why not pair? the way you would a Dev role?) Please note I am not saying this is essential, but I am saying that it can vastly increase the effectiveness of a team. and fears of a bottleneck are unfounded, a focal point and a single filter may actually be a benefit rather than a hinderance.
In a similar vein I think that in the early days of a team of a project a flow manager/coach/Scrum Master type role can help a team form and become effective far quicker. They encourage the team to be aware of the less desirable tasks and to emphasise the importance and value of getting them done rather than focusing on less important tasks. Helping the team understand the difference between the feeling of being busy and actually delivering value to the stakeholders/customer.
Understanding the difference between a necessity of having someone in a role and the benefit a team derives from having someone in a role are often confused and muddled and that is something I intend to return to in a future post.
Summary
I do believe teams can be self-organising and I do believe that named roles can sometimes lead to unnecessary siloing – but that is not a certainty and that goal should not dwarf the desire for an effective team. I don’t believe that throwing a team together and taking away titles will magically make a self-organising team. Self management is a learned skill like any other and takes time to learn and to perfect.
I also don’t believe that taking away named roles removes the need for specialist skills. Saying we don’t want a named QA or Dev or PO doesn’t mean you don’t need those skills on the team.
Understanding which skills are needed is vital for an effective team, whether it is self-organised or not. But even with the necessary skills the team still needs to understand the direction (vision) and be motivated to reach it.
John Yorke 