Cross Functional Doesn’t Mean (just) Work Allocation

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.

Yes, and… 


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.

Notes

Share

2 Gedanken zu „Cross Functional Doesn’t Mean (just) Work Allocation

  1. Thanks for sharing your learnings and glad the LeSS training did its magic. Something else that might be of interest to you in this matter could be the „4 levels of skill matrix“ as a technique to make skills a bit more transparant and keep them linked to intrinsic motivation of each individual.

    1. Thanks for the „4 levels of skill matrix“. What great botton-up approach to a skills matrix! It is a pity that many times skills matrix are used to make decisions without going to the Gemba.

Schreibe einen Kommentar