Team roles — not what they used to be!
Roles in an agile team — necessary but tricky to get right!
In the 1950s work was apparently simple….
…you had a particular role in a given department and you had a manager. Your manager defined your role (defining your role being part of their role), and you fulfilled that role to your best abilities. I wasn’t working in the 50’s so I can’t validate this from personal experience, but I have a hunch that given that work was done in the 50’s by human beings I doubt that things were this simple in practice. But at least it was simple in theory! You had a ‘north star’ — your role, as expressed in your job description.
Then along came the Agile movement, and in 2001 the Agile Manifesto:
Build projects around motivated individuals. Give them the environment and support they need,and trust them to get the job done.
Principles behind the Agile Manifesto — Principle 5
The best architectures, requirements, and designs emerge from self organizing teams
Principles behind the Agile Manifesto — Principle 11
Agile ways of working and the associated push towards team empowerment and collaboration has had implications both for teams and for company structure, with matrix style authority structures becoming commonplace in technology companies, departments and teams.
On balance I believe this has been positive but having multiple overlapping roles has in some cases had an unwanted side-effect. Confusion.
A common example I come across is confusion, delay and indecision over technical design. Ideally an informed consensus would emerge and often this does happen. In some cases though, as you would expect in an industry where there are very few “right” answers — just different approaches — consensus cannot be obtained in a reasonable time. In this case who can serve as a tie breaker and make the final call on the technical design of a feature? The team working on the feature? The senior developer? The consulting architect? The development manager? The architecture practice lead? Or perhaps we need the CTO to decide?
As a manager or a coach there is also a tricky balance to be achieved when it comes to roles. If you put too little focus on roles this can breed confusion and frustration. Too much focus can lead to unnecessary energy being put into discussions around ‘who’s job this is’ at the expense of getting the job done.
Also, teams are at different levels of maturity, higher performing teams, with a higher level of trust tend to operate with more overlap when it comes to roles, with different team members stepping in as the situation requires. Less mature teams need more clarity.
What do we make of all of this? Gosh, roles in an agile team are necessary but tricky to get right.
Roles as hats
Increasingly in companies embracing agility a role is seen as a hat that is worn by the wearer. A set of responsibilities that are taken on (‘worn’ to use the hat analogy) by a particular person or people, for a particular period of time. Thus some positions — and Agile Coach is a good example — could be described as multi-role jobs. This decoupling of Job Description and Role is helping many companies find a way through the spider’s web of overlapping priorities present in every company.
For a framework fully embracing the ‘roles as hats’ way of thinking, check out the holacracy constitution (see Article I: Energizing Roles)
What are the best roles to have in an agile team?
Lets take a look at what some of the major frameworks and some of the thought leaders in this area have to say about roles in an agile team:
Scrum
The Scrum Guide calls out three roles; a Product Owner, a self-organizing Development Team and a Scrum Master
The Product Owner is responsible for maximizing the value of the product, and the Scrum Master is responsible for promoting and supporting Scrum and the delivery team is responsible for, well, delivering.
Kanban Method
David Anderson’s Kanban Method does not formally define roles but does call out two ‘emerging roles’ — the Service Delivery Manager, responsible for the flow of work, and the Service Request Manager, and states of this role that “The goal is to re-position the role of product owner as a risk manager and facilitator”
Disciplined Agile Delivery (DAD)
In addition to the team performing the work, DAD calls out four core roles:
- Stakeholder. Someone who is materially impacted by the outcome of the solution
- Team Lead. Also a servant leader, and an agile coach.
- Product Owner. The one voice of the customer
- Architecture Owner. The person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.
Ahmed Sidky
Ahmed Sidky Head of Business Agility at Riot Games and President of ICAgile wrote a great article on the roles that were put in place at Riot games.
Team roles at riot games (taken directly from the above blog) are:
- Team Captain — leading the overall effort
- Product Lead — leading product strategies and resonance with audience
- Delivery Lead — leading delivery and execution
- Craft Lead — leading on technical direction in a specific craft area
So … what are the best roles to have in an agile team?
From the research I’ve done and my experience and observations here is my take on the best roles for an agile team. My thinking is emerging on this, so a few quick disclaimers before I get into it:
- As I mentioned above, this is a complex area, I may change my mind on these 😊 Or I may find that there is no value in calling out ‘standard’ roles as there are in fact no ‘standard’ roles.
- These are roles as hats. So a role in this context is an area that needs to be covered. Whether one person fulfills the role, or more than one, or even the whole team is I believe, case by case / team by team. The important thing is that there is a clear understanding of how decisions will be reached in these areas.
- A role holder is not necessarily the sole decision maker — for example the role holder may defer to another or to the team consensus on a particular decision. They do though, as needed have the final say.
- Role names are my best attempt — your mileage may vary.
- These roles exclude the technical team actually doing the work. Describing a pattern for how many developers, QA consultants, test engineers etc etc are needed, and how to name these roles is definitely case by case / team by team / company by company.
OK that’s more than enough disclaimers! - here’s my current best foot forward on the roles needed in an agile team:
Product Lead. If the team was a company this role would map to the CEO role. Responsible for holding and articulating an unfolding vision for the desired outcome. Typical job titles of people fulfilling this role are Product Manager and Product Owner. See Marty Cagen’s post for a great explanation of this role.
Tech lead If a team was a company this role would map to the CTO role. Responsible for holding and articulating an unfolding technology vision for the team. Typical job titles of people who fulfill this role are architect, senior developer, development manager.
Process Lead If a team was a company this role would map to the role of management. Responsible for holding and articulating a vision for an effective and continually improving set of team processes. Typical job titles of people who you will find holding this role are agile coach, scrum master, iteration manager and the wide variety of ‘agile coach’ equivalents (Delivery coach, Kaizen coach, Ways of Working coach and so on)
Process Lead?
It is this last role, that of Process Lead that is the least widely accepted in the industry. Indeed many agile coaches will see process as just another area to coach the team in. If this is your stance as an agile coach, I say good on you! Its a perfectly valid position to take. The question I would pose to you would be:
“In your team or teams, which role is accountable for designing, implementing, improving and sustaining quality team processes?”
The standard answer to this question is ‘the team’. To me, from experience, this is a non-answer. ‘The team’ could be the answer to all ‘who’s role is it…?’ questions when you think about it. Of course we want to work collaboratively — the benefit of a role is that it facilitates timely and quality decision making. Without a process lead role team processes will almost always stagnate and gradually decline. My point is that a process lead role is needed within a high performing team, and this role is a natural fit for a team coach / team facilitator.
Let’s keep talking about this as a community.
Roles. Not what they used to be!
