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.

Roles

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.

Skills

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

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.

AgileData Skills

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.

• Stakeholder Management
• Facilitation
• Requirements
• Architecture
• Data Modeling
• Development
• Testing
• Documentation
• Release

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.

T-Skills

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

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 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:

• Novice
• Practitioner
• Adept
• Expert
• Coach

Novice

The person is starting to learn that particular skill.

Practitioner

The person has a good understanding and experience of the skill and utilises the skill on a regular basis.

Adept

Demonstrates significant expertise, can recognise patterns within the skill, and can adapt their actions based on the specific context.

Expert

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.

Coach

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.

Common T’s

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 Analyst

Business Analysts commonly have their T skewed to the left.

Data Engineer

Data Engineers, Developers etc commonly have their skills strong in the middle of the T.

Tester

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:

1. Where we have overlaps in skills across the team
2. Where we have gaps in the skills across the team

Skills Overlap

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.

Skill Gaps

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.

Personal Growth

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.

Increase Depth

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.

<<<.  >>>

Increase Breadth

<<<. New skills >>>

Expert vs Coach

<<< new set of soft skills, not just an increase.  Teach >>>

Rewarding Growth

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.

AgileData Roles

Outside the core delivery squads/pods/teams we need supporting roles depending on which agile patterns we are adopting.

Scrum Coach

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>>>

Agile Coach

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.

<<.  >>>