Thanks to Chad Beier and Jeff Buboltz, Professional Scrum Trainers from their newly formed joint venture, Wisconsin Agility, I have tons of new fodder for my blog. They presented a fun and energizing Milwaukee SPIN session that inspired me to brainstorm all the ways Scrum Teams may NOT be practicing agile (aka they’ll agile-ish).
In this new blog series, I’ll explore many of the ideas identified and elaborate on the problems that could result from these issues (and, of course, ways to remedy them).
First on the docket is what happens when you don’t have a fully cross-functional Scrum Team. This easily emerged as one of the top takeaways, and as a seasoned Agile Coach, I have unfortunately seen this situation far too often.
Here are some negative consequences that could result in not having all the skills you need to have embedded within your Scrum Team:
Having to wait for a Specialized Skill outside the Team
Problem
The number one problem I often see is having only one person in an organization with a particular skill set. It may be because the skill is antiquated, there are only a certain number of licenses for a software system due to cost, or there’s institutional knowledge that lives in that person’s head (and no one else’s). Usually, because there is only one person in this position, they become a shared resource rather than dedicated to a specific team.
Solution
Unfortunately, there isn’t an ideal fix to this problem, given the facts of reality. So, what could you do to address this issue? I see several possibilities:
- Cross-train other people on the specific skill, so no one person becomes an immediate bottleneck. This other person may not be as proficient, but if it’s good enough to get the job done, then it could work.
- Pony up the money to obtain additional licenses to limited-access software. No one person should hold all the keys to the castle anyway – make sure there is redundancy in every function within your organization; otherwise, you open yourself up to serious risk.
- Rotate the specialist on different Scrum Teams each Sprint. If more than one team needs the same unique skillset, then dedicate the specialist to one team for a Sprint, another for the next, and so on. That way, the person can focus on one team’s work at a time.
- Split the specialist’s time evenly between multiple teams, dedicating specific days of each Sprint to one team. The idea is to minimize context-switching as much as possible and set expectations on the person’s timing and availability.
- My best recommendation for this issue is to add a new, full-time, dedicated person to the team with the correct skill set, thereby creating a fully cross-functional team. It might require effort to find, train, and invest in the extra person, but it will increase your success dramatically.
Never getting an Increment Done within a Sprint
Problem
When you don’t have a fully cross-functional Scrum Team, how likely do you think it is that they’ll consistently deliver quality, “done” increments at the end of each Sprint? My answer is: it’s doubtful. Because the team doesn’t possess all the necessary skills, there are gaps in their knowledge and experience that, without, it’s simply impossible to deliver.
Solution
I would conduct a root-cause analysis as part of the Scrum Team’s Sprint Retrospective to try and determine why the team cannot get their work items over the finish line. Typically, this will uncover missing skills or activities that need to take place, which the team has overlooked or neglected. To fix this problem, once you have identified the deficits, find ways to address them. It could be training, re-sequencing work to avoid dependencies, pair programming, peer reviews, etc.
TIP: you might also want to revisit your Definition of Done and revise it if there’s no way you’re ever going to resolve the issues preventing you from reaching your Sprint Goal.
Frustrated and Demoralized Team
Problem
When you never complete the planned work, and it carries Sprint over Sprint, it’s highly demoralizing to a Scrum Team. No one likes to reach the end of an iteration only to discover that the team didn’t deliver, and the culprit is often a lack of all the skills on the team to get to a “done” state. It’s no fun to look at your Sprint Board and not have much finished work. Try as you might, if skills are missing from the team, it may never be possible to complete all the planned work.
Solution
To improve team morale and motivation, the Scrum Team must be fully self-sufficient, so adding a new team member with the requisite skills, cross-training, providing more skills development, or adding an Agile Coach would help. A competent Agile Coach can guide the team to recognize their deficits and help them devise a plan to resolve them. In turn, this engenders small successes and growing confidence rather than a feeling of constant defeat.
Angry or Disappointed Customers and Stakeholders
Problem
When your Scrum Team doesn’t deliver as planned, customers and stakeholders tend to get a bit upset, even if they understand the reasons for the delays. Telling them that you don’t have all the skills to complete the work will not make them happy – they honestly don’t care about or understand how the job gets done, only that it does.
Solution
They say honesty is always the best policy, but don’t be overly negative. As a Scrum Team, look for creative ways to fill the gaps in skills and knowledge. Also, ask your customers and stakeholders to be patient, as while the Scrum Framework is easy to understand, it is difficult to master. Part of that is ensuring you have the right mixture of cross-functional skills.
Lack of Trust in the Team
Problem
In addition to having venomous customers and stakeholders, those same people will lose trust in the team if they are continually disappointed. Once you lose this engagement, it’s enormously challenging to get it back, and not having the ability to deliver on the Scrum Team‘s commitments will continue to generate negative sentiment.
Solution
When you lose trust, it’s hard to get back – it takes longer than building trust in the first place. To regain that feeling, the Scrum Team should only bite small pieces of work that they know they have all the skills to complete within a Sprint. If there are specialist dependencies, sequence the tasks around that person so the team can be confident that they finish what they plan to do during a Sprint.
Forced re-sequencing of the Product Backlog
Problem
If your Scrum Team lacks all the necessary cross-functional skills to complete a “done” increment, your Product Owner may have to re-sequence the items in the Product Backlog due to the skills constraint. This likely means that the team is choosing things that are NOT the most valuable or the highest priority.
Solution
Either build out a fully cross-functional team or, if you’re unable to, work in advance with the required specialists to schedule their time when you need it. That way, your Product Owner doesn’t have to be concerned with technical constraints and can focus on ensuring that the right things get prioritized.
Final Thoughts
There’s no substitute for having a fully cross-functional Scum Team; if any skills are missing, you will suffer most, if not all, of the problems discussed in this blog. Your best bet is to build a solid business case and get everyone you need on your team. If that’s impossible, you can try the workarounds suggested here, but I don’t guarantee you’ll succeed.
How about you? Have you seen these problems result from lacking the necessary cross-functional skills on your Scrum Team? Did you run into any other issues because of this? What were they? How did you deal with them? I’d be curious to know, so please let me know in the comments below!