Cross-functionality is one of the most difficult steps in an Agile transformation. Resistance comes from many different points such as team members who are afraid of opening their silos, managers who lose their head-counting power or a hiring market that promotes extreme specialisation.
Particularly, in myToys IT, we don’t only work on hiring the best individual talent. We are a team-centered IT department that cultivates self-managing independent teams. Thus, cross-functionality is a key part of our view.
If all of this rings a bell to you, take a look at Mike Cohn’s great article which explains the impact of the problem on work allocation. As Mike concludes, it is perfectly acceptable to have specialists on an agile team.
Don’t forget local optimisation
As in many other cases in knowledge work, we don’t see the tangible result of our decisions. However, specialisation implies other effects that I would like to illustrate using this funny short scene:
As you can observe, our lovely wrapping specialists are part of a wider team that at least includes kitchen specialists behind the door. The shared objective of both groups is to serve wrapped chocolates and they will be rewarded by the market because of it. It doesn’t matter which group performs better, at the end of the day both will be evaluated as a single team.
We can conclude that the factory’s senior management already thought about it. Thus, they hired a yelling manager to control the whole process and optimise it accordingly. The only problem is that our lovely wrapping specialists are cheating her. In fact, we don’t know if even the kitchen specialists are behaving honestly or they are pressured by our “very optimised” wrapping specialists.
Which would be the next solution given by the senior management? Would they add an extra step in the production line assuring that nobody cheats? Would they hire a new manager to yell the yelling manager? Both?
What if the problem doesn’t have anything to do with cheating?
What if the problem is the wall?
Let’s go back to “software manufacturing”. Apart from the fact that cheating making software is much easier (it is called technical debt), or that a yelling manager will never be surrounded by the talent every software company need, the scenario should be familiar to many of you.
The industry has already learnt that physical walls must be destroyed. We have collocated teams, open offices and crystal doors. However, knowledge can’t be seen, it only can be understood and multi-skilled team members break walls.
Do you remember that planning session when your QA/Backend/Frontend specialists were deadly bored playing with the smartphone? What about that frustrating retrospective when nobody was improving anything? Do you miss a non-yelling project manager optimising the team work? Well, you already have your Scrum Master. 😉
All of them might be symptoms of walls in your team. Self-organization and continuous improvement happen when everybody in the team can at least understand the given problems.
Alternatives to including pure specialists into the team
LeSS uses Travelers to mitigate the lack of technical specialisation in feature teams. This same concept can be used with external consultants hired just for knowledge transfer. Be careful, the experts shouldn’t work directly on the product, they must focus on new skills development.
- Thanks to Jurgen De Smet for his awesome LeSS training. A huge part of the article is based on it.
- Do you wonder why I used a Fresco from the US Capitol to illustrate in my previous article. It was an Easter egg. Cincinnatus, who is the farmer in the picture, was the first Roman dictator. Look at the legend, it seems that emergent leadership wasn’t invented by Google. 😉