Team - Skills vs Roles
It is a silo problem
When we structure our teams based on roles not skills we strike a bunch of problems that are related to the anti-patterns roles seem to invoke.
Team members will perform the data tasks to be done as part of their role and then hand the work to the next role in the data value chain. These hand-offs cause multiple problems, we lose context, we encounter delays, things get lost in translation, in fact things often get lost all together.
If a person who undertakes the role is not available at the same time the work is ready to be done, then the work has to wait until somebody in that role is available. Heaven forbid if somebody else tried to do that role and “step on a person’s toes”.
Roles result in a set of constraints for the data work that role can undertake. The person given that role is unable to grow outside that role, they must wait until they are given another role. This constrains their ability to learn other skills, have variety in the work they do and generally grow as individuals.
Skills vs Roles
Skills are learnt, roles are given.
Skills are the things we have learned, things we have knowledge, understanding and experience in doing.
Roles are an artificial construct within an organisational hierarchy or a way of working, they provide a boundary of what tasks should supposedly be done by a person.
When we use the term roles we can associate that term with many things, depending on our experience across the agile, product and data domains.
We can associate roles with agile roles, following Scrum centric patterns. The scrum guide gives a strong description of the Scrum Master, Product Owner and Developer roles.
We can associate roles with data roles, following the typical way of working data teams operate under. We will hear of roles such as Business Analyst, Data Modeler, Data Engineer, Tester etc.
We can associate roles with product roles, following product management centric patterns. We will hear of roles such as UX researcher, UI designer, Product Manager and Developer.
As we scale to more than one pod/squad/team we start to see increased role specialisation. Additional roles appear within the teams or additional roles appear to coordinate and support work across multiple teams.
If we look at the Scrum of Scrum patterns for scaling, we will hear of roles such as Chief Product Officer and Scrum of Scrum Master.
The patterns Spotify published (the so called “Spotify Model”) many years ago for scaling squads, describes roles to support the scaling. We hear of groups of people such as Squads, Tribes, Chapters and Guilds. We hear of roles such as Product Owner, Agile Coach, Tribe Lead, Chapter Lead, Guild Co-ordinator.
If we look at the UnFix patterns for scaling teams we hear of teams of people forming into Crews, such as Value Stream Crew, Platform Crew, Capability Crew and Facilitation Crew. Each Crew provides a role within the Way of Working.
When we use the term skills we can associate the term with the understanding and experience a team member has to get a data task done.
We can associate the term with skills from the agile domain, following the principles outlined in the Agile Manifesto. Skills such as adapting to change, being able to decompose work down into small deliverables, the ability to work with others, the ability to iterate the work we do.
We can associate the term with skills from the data domain, following the typical way of working data teams operate under. We will hear of skills such as facilitation, engineering/development, testing, writing documentation.
We can associate the term with skills from the product domain, following product management centric patterns. We will hear of skills such as the ability to conduct market research.
<<<Need to refine the agile and product skills, to get better examples. If anybody has a good set of example skills for these domains send them my way ;-0>>>
Self-sufficient teams are often referred to as Cross-Functional teams.
One of the patterns in an AgileData Way of Working is to ensure that the pod/squad/team have all the skills they require to be able to get the work done, by themselves, without needing the help of anybody outside their team. We want to minimise any dependencies, handoffs and delays that come with relying on another pod/squad/team to get the work done.
We also want the team members to be dedicated to the team and dedicated to the work the team is doing. We don’t want team members to be part time on the team, and then part time on another team, or allocated to other work or roles outside the work the team needs to get done. We know that being able to focus is a core capability for a high performing team and constant focus and task switching is an anti-pattern which negatively impacts a teams performance in multiple ways.
We want the pod/squads/teams to be self-sufficient, able to get the work done with no external dependencies.
Self sufficient is different to self managing or self selecting. Self managing teams have “the authority to design, plan, and execute their tasks and to monitor and manage their work process and progress” [Hackman]. Self selecting is a set of patterns that allow the pod/squad/teams to disband and reform on a regular basis.
To enable a team to become self-sufficient we want to focus on the skills the AgileData team needs to get the data tasks done. It is one of the first priorities when we are starting off with a new AgileData Way of Working. Without ensuring the team has all the skills they need, we are increasing the amount of friction that will occur when the team starts to adopt an AgileData Way of Working. The team will constantly hit roadblocks as they try to get a data task done but find they do not have adequate skills within the pod/squad/team to do so.
One pattern we can use to achieve this is to focus on the skills needed by the people delivering the work, to deliver that work. Then we focus on supplementary roles outside of the team that are needed to support the team to do that work. Lastly as we scale the pods/squads/teams we focus on the additional supporting roles needed to support the scaling.
A special note on scaling
An important pattern when scaling is that we should have identified all the skills needed in a team to get the data tasks done, and ensured we have competency in those skills before we start to scale the teams. We should not be introducing new skills into the teams as we scale, if we do we are typically trying to scale too fast. We need a core foundation in the way we work and the skills needed to deliver that work before we try and scale.
So let's first look at the skills an AgileData pod/squad/team need and then we can look at the supplementary roles that are needed to support them.
Within the delivery squads/pods/teams we need a set of core skills within the team. The skills are dependent on which agile, product and data patterns we are adopting.
For an AgileData Way of Working we strive to have teams that have the breadth and depth of skills needed to complete all the required tasks to deliver something end to end. A self-sufficient team so to speak, where the team is not reliant on any other teams.
This is regardless of whether we have adopted iteration based (Scrum centric) patterns or flow based (Lean centric) patterns. Regardless whether we are adopting a research first based approach or a Minimum Viable Information Product approach. A self-sufficient team has immense power to get the data work done.
Skills for the data domain
Based on the data teams we have worked with over the years, the following skills are the most commonly required by an AgileData team.
These skills are defined at a high level rather than at a deep technical level.
First we want to focus on breaking down the isolated team topologies we get when every team member has a dedicated role.
A common example in a traditional way of working is to see a dedicated role for testing or Quality Assurance (QA). We want to move that from being a dedicated role to a set of skills that multiple team members have.
Once we have a self-sufficient team, we can then focus on increasing the team members' technical skills, for example their ability to write SQL or Python code.
We use the T-Skills pattern to identify where we have a good crossover of skills across the AgileData team and where we have gaps we need to fill. We can fill the gaps by either expanding the skills of team members over time or adding a new person to the team with the missing skills.
T-shaped is a term that describes the breadth and depth of skills an individual has acquired. The term T-shaped is widely credited as being coined by David Guest in his article “The hunt is on for the Renaissance Man of computing” published in 1991 in the UK newspaper the The Independent.
The T-Skills pattern is based, as you might have guessed, on the letter T. The horizontal top bar of the T represents the breadth of skills needed in a team for the team to be self-sufficient. The vertical bar of the T represents the depth of these skills. We strive to have teams that have both the breadth and the depth of skills needed to complete all the required tasks to deliver something end to end.
T-Skilled teams are often referred to as Cross-Functional teams.
The idea behind T-Skills is to ensure that the team have all the skills they require to be able to get the work done, by themselves, without needing the help of anybody outside their team. Effectively all the skills they need to do the end-to-end process from idea to delivery.
We know that each time the team has to stop and wait for somebody outside the team to do a task, then the complexity of that work increases.
This is due to the fact that they will need to communicate the work to be done to the other team, in a way that another person can understand the context of the work. They will then need to wait until that person finds time to prioritise and do the task, before the team member can carry on and complete their data tasks to be done.
You may hear other terms used for the idea of mapping out a team's skills using a shape to be able to quickly identify where the skills are covered and where they are lacking. Names such as tree skills, or paint drip skills.
The first thing we need to do is to map out the skills needed in the teams to do the process end to end. These skills will be dependent on the domain the team is working in. While there is some crossover of skills between the software and data engineering domains, for example the skill of developing code, there are also enough unique challenges between these two domains that provide a slightly different lens on how we would describe the skills required.
T-Skills for the data domain (Breadth)
We have already outlined the core skills required for a self-sufficient data team/pod /squad in a previous section. We can now create a diagram to visualises these skills together in a T-Skills.
<<<Link to T -Skills template download >>>
As you can see we are displaying the skills as vertical bars next to each other. These skills are the most common skills we see as we have worked across multiple data and analytics teams, but they are not an exhaustive list. If you feel your team needs additional skills, or the language you use for the skills is different then iterate the diagram to fit your own Way of Working.
Skills Maturity (Depth)
When working with a new data and analytics team we start off by having them gauge their data skills maturity. The goal is to identify the skills where the team has a high level of maturity and the areas where they have a low level of maturity and therefore have some risk in that area.
In the past we would call this their level of mastery and would use a scale something like novice, apprentice, journeyman and master. But as terminology changes throughout the world I suggest we should be using different terms.
The five levels we use in the AgileData Way of Working to gauge the individuals and teams level of skill maturity are:
The person is starting to learn that particular skill.
The person has a good understanding and experience of the skill and utilises the skill on a regular basis.
Demonstrates significant expertise, can recognise patterns within the skill, and can adapt their actions based on the specific context.
The person has a deep understanding and experience in the skill. They can solve challenges by creating new approaches and patterns within that skill area.
Someone who can teach and mentor others to do the work, like they do. They can teach or mentor another person to gain an expert level of maturity in that skill
Individual skill mapping
We ask each team member to use these maturity levels to self select their level of maturity in these skills.
The higher the level of maturity in a particular skill, the deeper they colour in that skills column.
For example, here is my current level of T-Skills.
As you can see my T is skewed towards the left.
At this stage we typically get asked the question “Won’t the team members lie or misrepresent their level of skills”. The answer is no, we provide more context to that answer in the Frequently Answered Questions section of this Chapter.
Skills depth not role depth
We are looking for the team members to map out their skill maturity in each of the skills, not for the role they used to perform under their old ways of working. We would expect to see individuals with a number of skills where they are Novices, as they are skills they have yet to focus on increasing their maturity in, or they are skills they have no interest in and no plans to gain a high level of maturity of.
Often people feel that to be at an expert level in the team, they need to be at an expert level across all the skills. The old role way of thinking is hard to unlearn and break.
We will often see a common set of T-Skills for a person who has had a traditional role in an organisation. We provide these examples as a way of giving more context on the T-Skills diagram.
Business Analysts commonly have their T skewed to the left.
Data Engineers, Developers etc commonly have their skills strong in the middle of the T.
Testers commonly have their T skewed to the right. You will also see testers who have come from a development background have a strong centre to their T, where as a tester who has come from an analyst background will have a strong left and right (inverse Mohawk)
Cross functional team mapping
Once the team members have mapped out their individual skills onto the T-Skills template we then overlay the templates to give a holistic view across the team.
We are doing this to identify two things:
Where we have overlaps in skills across the team
Where we have gaps in the skills across the team
Having multiple team members who have the same set of skills is a great thing for an AgileData team.
It allows for redundancy across the team. If a team member has taken time off (planned or unplanned) there is a second person with the skills needed to get the data tasks done.
Overlapping skills also allows the team to perform tasks in parallel if they need to, rather than having a bottleneck in their Way of Working due to only one person having the skills needed to get a data task done.
An example of this we commonly see is in testing skills. In the old Ways of Working it is common to see a team that performed the testing / QA after the development team had finished. When the team starts their journey to an AgileData Way of Working they bring these testing tasks into their Definition of Done, but still have a single person in the team with the skills and accountability to do the testing work. We want to move to a pattern where multiple people have the skills to do the testing tasks, ideally the developers themselves
Another common example is requirements gathering. In the old Ways of Working it is common to see a team of Business Analyst’s who time slice their availability across multiple teams or projects. They define the requirements up front and then move onto the next team to ensure they provide the requirements “just in time”. The problem is once they have documented the requirements they are no longer available to the AgileData team to clarify or iterate the requirements as the team starts to work on delivering them. We want to move to a pattern where multiple people have the skills to facilitate, gather and iterate requirements as and when required.
When we look at the skills overlap across an AgileData team we will see different levels of depth within those skills. For example we will see people who have come from a traditional testing role with skills at an expert or coach level. We will also see people who have come from a traditional business analyst or developer role who have a novice or practitioner level of testing skills.
There is a tendency for teams to wait until the most skilled person is available to do the data tasks, but this causes bottlenecks in their Way of Working, and we should aim to reduce or remove bottlenecks wherever possible. While the novice level person may take longer to get the data task done compared to the expert, if the expert level person is busy on another data task then having the novice working on the outstanding tasks will still result in the work being done earlier than waiting for the expert to become free. The other benefit of this pattern is that the novice gets additional experience in that task, which is great, after all most people can increase their skills by doing.
As well as confirming we have overlap in skills across the AgileData team, the other thing we need to identify is where we have gaps.
If we are coming from a traditional Way of Working where people had roles and those roles were grouped together into separate teams or centres of excellence, we find when the AgileData team is initially formed some of those roles/teams are still maintained separately.
We will typically see the roles who performed data tasks at the beginning of the data value chain process or the end of the process being retained in separate teams rather than the roles who did the data work in the middle of the process.
For example we will see the merger of the people who engineer the data, the people who engineer the data platform and the people who create the last mile consumable output such as reports or dashboards into the AgileData team.
We will often see the Business Analyst, Testing, Analytics(or Data Science) and Support roles stay in separate teams.
Our goal is to have self-sufficient teams that can do the data work required to take something from an idea or problem to the final consumable Information Product. This means the skills provided by the Business Analyst, Testing, Analytics (or Data Science) and Support roles need to be available within the team.
One of the challenges in moving from the Roles pattern to the Skills pattern is it makes it harder to identify gaps. It is common to see a person who creates the consumable output, for example a Dashboard, have strong facilitation skills. But they have never worked in the role of a Business Analyst.
Overlapping the T-Skills diagram will quickly identify where we have a skill set completely missing, for example no facilitation or testing capability.
It will also indicate where a Role has not been transitioned into the team and is still siloed. We see this by looking at each of the Skills depth and seeing if we have a person with Expert or Coach level in each skill. If we don’t then it’s likely <<>>>
Add people, upskill or try it and see if it works.
One of the benefits of the Skills over Roles pattern is it provides a path for personal growth for people within the AgileData team.
In traditional ways of working a person often has to change roles, teams or organisations to achieve personal or career growth. Or they have to move from a “doing” role to a “managing” role to achieve that growth. Often people we have worked with want to achieve growth but have no desire to move organisations out teams, they love where they work and who they work with. They have no interest in managing teams of people, they really enjoy the work they do and want to keep doing it.
The T-Skills pattern allows team members to identify the options to either increase the breadth of their skills or the depth of their skills.
This is the most common path we see team members take to grow their capability. They will be at a Novice or Practitioner level and want to grow to become an Expert.
<<<. New skills >>>
Expert vs Coach
<<< new set of soft skills, not just an increase. Teach >>>
Your organisations may need to rethink the way you reward people for growing when adopting a skills based pattern.
In traditional Ways of Working it is common for people to be rewarded when they change roles. The change of role is the trigger for an increase in remuneration or other benefits. You will need to adapt this Way of Working to be triggered when there is a change of skills not a change of roles. This Way of Working is typically managed by another team, a team with the title of Human Resources or similar. Do not underestimate the effort required to make this change to your organisations Way of Working, in our experience the Human Resources team is often one of the teams that is least open to a new Way of Working. And even if they are open to changing the way people in the organisation are rewarded for growth, any changes relating to money tend to take a long time to make.
Outside the core delivery squads/pods/teams we need supporting roles depending on which agile patterns we are adopting.
The Scrum Coach is a supporting role.
If you are using agile patterns other than Scrum centric patterns then I still recommend you have a supporting role similar to this.
<<<find out what’s it called in lean>>>
The Agile coach is a supporting role.
<<Scrum Coach vs Agile Coach>>>
<<<some people say experience, I say patterns they know. Its ok to just be.a Scrum Coach (link to podcast)
Information Product Owner
The Information Product Owner is a supporting role.
<<< sometimes its a permanent role in the team and then I would move it to a team member and a set fo skills>>>
Information Product Leader
This role is often called Product Manager.
Agile Ways of Working are hard, moonlighting teams members make it harder
One of the hardest things to do in agile is to deliver using part time team members where delivering as part of the team is not the team members only day job.
Moonlighting Scrum Coach or Product Owner
If you are using Scrum centric agile patterns, when your Scrum Coach or Product Owner have been assigned to the team but told to do it in “their spare time” it is almost impossible.
I liken it to moonlighting or running a second job, they are involved but not committed.
This is the point where every Agile Coach reuses the Chicken and the Pig cartoon from ImplementingScrum.com, so as not to buck the trend ….
In the beginning, an AgileData team has to form and storm. If the AgileData team have never worked together before or even worse not been in an agile team before, then it will take time for them to create a self organising team and to define, agree and adopt their AgileData Way of Working.
This is a critical time. It is the most important time for the Scrum Coach to be present, as and when required.
The Scrum Coach is critical in advising the team on how to experiment. They are also critical in helping via retrospectives and constant feedback on how to identify and focus on the next areas that will be improved. Without this assistance, the team will often go around and around in ad-hoc circles trying a hundred and one different patterns, but never proving if those patterns are making things go faster or slower.
One of the many AgileData challenges is that a Scrum Coach is often only a part-time member of the team. When an AgileData team is mature and self organising then the Scrum Coach is only really needed part time to run the agile ceremonies and provide feedback. Typically I will see a Scrum Coach being engaged for 50% of each week to undertake this role.
When the team is new, this should be 100% for the first 3 to 6 sprints (9 to 18 weeks) which is the average amount of time it takes an agile team to form. Often I see the Scrum Coach engaged 50% at this time. If the Scrum Coach and the AgileData team are experienced, then this can often work, but it isn’t ideal.
However, if the Scrum Coach is trying to do the coaching role as a side hustle to their other job, it is almost impossible for them to be around at just the right time in those 9 to 18 weeks to help steer the AgileData team in the right direction. And by steer, I mean helping them identify areas of improvement they should concentrate on themselves, rather than telling them exactly what and how to do things.
In my experience, if you have a full time team, you need a full time Scrum Coach, at least to begin with.
Another thing to watch out for is when you have a part-time Scrum Coach who is also trying to manage another Scrum Team, often for another customer (in the cases where you have a contracted Scrum Coach rather than a permanent one). This will often result in the Scrum Coach not being available to work with the AgileData team at critical points.
You are probably running a hybrid remote AgileData team these days. You're Scrum Coach might use slack to try and keep up to date with what is happening, pop in and out of video conversations, or they might “pop in” for just the ceremonies and then disappear. They might even do a few regular days each week and miss some other days on a regular basis.
But without being present when required (virtually or physically), they are going to lose the subtleties that come with personal interaction. A good Scrum Coach is a guru in picking up on these subtleties and help the AgileData team increase their maturity based on these observations. When the Scrum Coach is not around the AgileData team will typically just flounder.
Even worse is when the Scrum Coach is more of a dictator than a servant leader. In this scenario, the Scrum Coach will tell the team what actions to take next without really understanding what has happened in the last Iteration, what worked and what didn’t. It is one of the worse form of guessing.
If your Scrum Coach isn’t there when the AgileTeam is, I suggest you get them to turn up or get a new Scrum Coach.
Frequently Asked Questions
Won’t team members over inflate their T-Skills?
In our experience most people underplay their level of skills more often than they will over inflate them.
The team dynamic has the positive effect of self regulation, it helps keep each team member honest about their level of skills. If a team member does over inflate their level of skills, another team member will typically call it out.
We often see the opposite, where the team members will underplay their level of skill, as they compare themselves to another team member who has more experience in that set of skills. In this scenario the other team members again tend to call it out and help the person understand how skilled they really are.
There needs to be a safe cultural environment for this self regulation to happen. A safe cultural environment is critical for all AgileData team behaviour and patterns, not just the T-Skills mapping.
Can I have part time members in the pod/squad/team?
Ideally you want the team members dedicated to the pod/squad/team full time. We know that having part time team members brings extra challenges to the team.
The team will have to optimise the work being done around the availability of the part time team member, especially if the team does not have coverage for the skills or skill depth the part time member provides.
The team will also have to schedule any team ceremonies they utilise to ensure they happen when the part time team member is available.
Lastly there will often be situations where the part time team members other work will become a priority and their availability will be less than normal for a period of time. The team will have to re-optimise their work to deal with this change. Often the team is given little notice of this change of availability, its is a last minute change, and this will impact their ability to deliver what they said they would deliver, when they said they would deliver it as they have planned to have that person and those skills available.
Can I have part time people in the supporting roles?
There is less impact in the supporting roles being part time, compared to a pod/squad/team member.
The main impact is that the team may not get the immediate direction they need when they need a decision to be made. This will result in either the team slowing down to wait for that direction, or making a trade off decision themselves. There is a risk that any decision they make may be overridden by the supporting role after the fact and this will result in rework.
If a person in a supporting role is only available part time, you should aim for consistency on when that person is available so the team can plan around that availability. For example a Product Owner who is only available 50% of their time, try and make sure that they are always available in the first half of each day, so the team can plan when to get feedback from them.