One of the larger challenges facing many agile teams is having the requisite skills to deliver the goods. And it’s an insidious problem because it’s hidden by the very nature of cross-functional teams.
When I coach agile teams, I usually emphasize a couple of things:
Becoming T-Shaped over time, and
Delivering as a Team.
I often exaggerate the responsibility by saying – the team needs to “suck it up” and work together to deliver on their shared goals. Everyone chipping in and helping each other out. There are no lone wolfs in an agile team and folks often need to do work that may be beyond their skill comfort zone.
But that has a prerequisite supposition…
That the team has been constructed with all of the requisite skills to execute the work that is coming at them via their backlog. And this is often not totally under the team’s control. Instead, it’s determined by how the leadership / management team has structured and staffed the teams. For example:
How have they staffed key skills?
How have the staffed cross functions, for example developers to tester ratios?
How have they staffed key roles like ScrumMaster and Product Owner?
How have they handled specialized skills? For example, shared architects, UX, BA’s, automation developers, etc.
How are they handling skill upgrades. For example, expecting the team to pick up new tools and/or frameworks almost instantaneously?
And how have they handled team focus? For example, are many folks multi-tasking across projects and teams? Or are they more focused on a single goal?
One the critical misunderstanding of an agile transformation is the management team’s responsibility to effectively set up their teams for success from a skillset / capabilities and a focused work perspective.
Key Person Dependencies
I have a close colleague who I’ve worked with for several years. His name is Lee Eason.
Lee has experienced the dissonance that poorly crafted team skills can create in agile contexts. And it’s not always poor leadership decisions that are solely driving it. Often –
The market may prove challenging to hire specific skill sets, so there are always gaps that need to be filled.
The business domain experience level may be so high that it takes some time for folks to “come up to speed” in the domain.
Attrition rates may be costing the organization critical skills – a brain drain if you will.
The history of the organization is that Subject Matter Experts spend little / no time sharing their experience.
But no matter the source, if teams aren’t skilled appropriately, it dramatically effects their efficiency and effectiveness.
Lee had coined a term for the level of shared and cohesive skills within a team. He talks about the level of key person dependencies. And he’s created a wonderful tool that seeks to capture KPD’s for organizations so that you can better understand (and improve) the skill levels and balance of your teams.
His company is Tekata and you can find more information on tool there. Lee has also written a nice overview of the problem as he sees it.
Wrapping Up
Lee is focusing on what I think are one of the next big things in the agile community.
First, KPD “management” is something that traditional software managers can really get their arms around as part of their new role in agile organizations. They can truly serve their teams by shining a light on their skills and helping to improve team member capabilities.
Second, it supports another trend in agile organizations. That is – a move back to the basics. Where there is a renewed focus on the agile team and giving them everything they need to successfully deliver on the promises of agility.
If you’re a leader in an agile organization, I’d encourage you to take a new look at your teams from a KPD perspective. And, if there is a need, start working hard in helping your teams to reduce their dependencies.
Stay agile my friends,
Bob.
Related Posts
Here are a few posts that further explore the notion of T-shaped people in agile team contexts -
by Mark Levison.