Dysfunction #1: “Cross-functional team”
In this series, I am going to reflect on what I have learned about Scrum and its large-scale adoption in a non-IT environment through my own revelations and indeed, failures, while working at a large UK-based company, rolling out its own flavour of Agile Transformation. Capital “A” and capital “T” intended.
Originally published at https://www.linkedin.com in October 2020.
I love people — not because helping them earns a portion of my bread and butter, no. I used to love them before that as well. People are amazing, creative, wacky, full of scars, fears and hidden drivers and motivations. I love people because they are just like me: a mystery waiting to be unravelled, appreciated and understood.
There is one thing, however, I love more than single individuals: a team of people. A good bunch of them. I’m absolutely thrilled when a diverse group of folk come together, each with their various backgrounds and baggage to serve one purpose and then somehow the whole thing explodes and becomes larger than the sum of its parts. It’s a wild thing — I get electrified whenever that happens.
I have felt this jolt when working with component teams where people have near identical skills and skill sets — where everyone speaks frontend or big data or search engine optimisation. But where the magic happens for me is at cross-functional teams: teams which consist of people from different functionalareas of an organisation; where people speak frontend, big data and SEO. Organisations have started to understand this as well, and are quick to set up cross-functional teams — Scrum also necessitates to have such a team as corner stone.
But is cross-functionality enough for Scrum to thrive? In Scrum, cross-functionality means all of the above, and then some. The framework is all about eliminating risks, and if you have a lottery factor (aka. bus factor) of 1, Scrum scrambles to address that too. This is presented quite succinctly when the Scrum guide discusses the five characteristics of the Development Team:
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
I emphasised the second part of that sentence for a reason — it is where the crux of the matter lies. People might have specialisations in a cross-functional team but as accountability belongs to the group as a whole, members had better rapidly start offloading these specialisations to their peers to decrease dependency on single individuals.
Not only do teams need to be cross-functional, they also need to be cross-skilled.
Unfortunately, in some cases this just doesn’t make sense from a personal or professional development perspective.
Just imagine a team that has ten functions or disciplines, and each of these need to get involved to deliver a piece of work. Each function is represented by a square in the figure above. If the dark green square indicates the skill you are proficient in, it is absolutely likely that you’ll be interested in learning more about what team mates in the light green and yellow squares do as it will add to your professional breadth. You might even want to know a trick or two about what’s happening in the orange squares. Moving further away from your main skill across the spectrum, however, it is increasingly unlikely that you’d be overly excited about the work going on there. Not only will it not interest you, it might not even broaden your skill set.
Additionally, if the skills of team members are so specific that only one person in a team of ten can pursue a certain discipline, another problem will emerge: you see, a large portion of Scrum fosters alignment. That’s the spirit of Scrum: alignment. This is what some of the meetings and artefacts are designed to promote, and some aspects of these events and artefacts will eventually break down.
After all, what’s the point of the daily scrum, if nobody can help unblock a team member when they face an impediment because no-one else in the team understands, say, data engineering? What is the point of the daily scrum if no one can pick up a team member’s work if they fall ill or win the lottery and can’t work any more?
Furthermore, what is the point of discussing estimates if a team member has no clue about the risks, uncertainties, dependencies and efforts that any one of the other nine team members has to face? And what would the other nine team members care whether the big data work I’m about to estimate is a 3 or a 13. It is me who would have to do the work after all and not them — so what do they know or care? It is not their concern.
As a consequence of not being able to estimate as a team, all velocity-based metrics will break down: teams won’t be able to properly forecast their deliverables, and the frequently used and abused burn-down chart will also become completely pointless. Also, in this world where a lottery factor of 1 is maintained and cross-skilling cannot occur, the product backlog will degrade to a list of personal to-do items and nothing more.
Due to the above, the dysfunctions introduced by not following the letter of Scrum will implicitly lead to the collapse of the spirit of Scrum. This, in turn, will seriously undermine the possible benefits offered by the framework, leaving behind a broken structure that cannot live up to the expectations.
And who gets to blame? Scrum gets to blame.
Originally published at https://www.linkedin.com.
