Part 1: Unleash Your Scrum with Multi-Skilled Professionals — The History and Background
In the intricate world of Scrum, the distinction between success and failure is deeply rooted in the subtle yet powerful nuances of team dynamics and organizational culture. Adopting Scrum goes beyond merely implementing new processes; it demands a profound shift in mindset. This transition challenges and transforms the entrenched beliefs and practices that have long defined traditional organizational structures.
In the opening article of this series, we embarked on an exploration of multi-skilling as a pivotal element for unlocking the full potential of Scrum. To fully harness the power of Scrum, we must delve deeper than surface-level changes and understand the deep-seated practices and beliefs that shape our approach to teamwork.
As we continue this series, today's article turns the spotlight onto two critical sources that significantly impact the trajectory of Scrum transformations. These sources – historical legacies and the single-skilled mindset – often lead to the formation of teams composed of narrowly focused specialists, more aligned with specific steps in a production process than with the collaborative effort of a unified team striving towards a common product goal.
By identifying and consciously addressing these elements, we lay the groundwork for a true adoption of Scrum, aligning not just our practices but our underlying beliefs with the principles of Agility and collaborative innovation.
If you’re just joining me in this series, you might find it helpful to read the earlier parts for context:
Chapter 1
The Legacy That We Carry: How We Set Scrum Teams Up for Failure
Embarking on a Scrum journey rarely happens in a vacuum. More often than not, teams are embedded within an organizational framework molded by years—or even decades—of entrenched governance models, organizational structures, HR policies, and reward systems. These frameworks are the offshoots of long-standing mental models rooted in conventional management theories. Far from being neutral, these elements often clash with Scrum foundations and principles and can actively sabotage the success of newly-formed Scrum teams if not conscientiously addressed.
Traditionally, work structures have been matrix and project-centric, hinging on the notions of predictability, control and specialized silos. These can range from Design to Analysis, Backend to Frontend, Testing, Integration, and beyond. Accountability for project outcomes typically rests with a project manager, who brokers deals with functional line managers for resources. Workflow mimics an industrial assembly line; each functional unit hands off its completed portion of the work to the next down a linear sequence of gates. The last stop is usually an "integration and release manager," responsible for coalescing these disjointed efforts into a large singular package for client delivery.
In this model, line managers distribute tasks to specialists, juggling workloads to maximize 'resource utilization.' Here, the very busyness of team members masquerades as productivity. Individual task completion within stipulated timelines becomes the primary concern for developers. Autonomy is restricted; people operate within the confines of rigid specifications and often stringent directives. Under existing structures and HR policies, specialists are encouraged to excel solely within their narrow remit.
This extreme specialization emanates from prevailing mental models that equate narrow expertise with both efficiency and productivity. HR policies exacerbate this mindset by deploying individual performance metrics and infrequent evaluations disconnected from team dynamics. These evaluations often leverage extrinsic motivators like promotions, salary hikes, and rewards, sidelining collective accountability and intrinsic motivation. Line managers set individual objectives based on these metrics, reinforcing the 'just do your job' mental model and stripping developers of broader engagement and creative latitude.
As teams embrace Scrum, they find themselves fettered by archaic practices and the lingering mindset of local efficiencies and output over creativity and outcomes, both from their managers and within themselves. They are ensnared by legacy performance metrics that favor narrow specialization, maximum resource utilization, and individual triumphs over collective achievements.
This legacy acts as an invisible shackle. Without acknowledging these deeply ingrained barriers and a concerted drive to dismantle them—through reevaluating HR policies, introducing new performance measures, and comprehensive retraining—the transition to Scrum is fraught with failure. The new paradigm necessitates a shift from output-based to outcome-based performance and a reorientation from individual to collective responsibility.
Chapter 2
The Single-Skilled Mindset: The Unseen Baggage Developers Bring to Scrum Teams
When we step into a Scrum Team for the first time, it often feels like a familiar tune with a different name. Beyond the external adjustments—like new role titles and added artifacts—things remain largely the same. Designers stick to designing, analysts keep analyzing, backend developers focus on backend tasks, frontend developers tackle designs and data displays, and testers, well, they test. Everyone does their own thing, deeply entrenched in their comfort zone, often unbothered about what happens before or after their part in the process.
The path to where we end up with a team of single-skilled developers is longer and more winding than most realize—it traces back to the classroom. While our early educational experiences expose us to a diverse range of subjects, from day one in school, the education system emphasizes individual achievement: scoring top grades, outperforming peers in tests, and the like. Individual performance becomes deeply ingrained and associated with being successful.
As we progress, the learning path narrows. In higher education and professional training, there's a pronounced shift towards specialization. This transition, deeply rooted in industrial-era practices, aims to prepare individuals for specific roles in a more compartmentalized workforce, inadvertently leading to a prevalence of single-skilled professionals. Beginning with a broad approach, the education system gradually funnels students into narrow expertise, which carries over into the workplace and manifests as teams of single-skilled specialists.
Common narratives, as highlighted in Cesário Ramos and Ilia Pavlichenko's "Creating Agile Organizations," include:
“I've been learning [subject] for several years in a row. It is impossible to become a deep specialist in a short time.”
“You require a five-year university study to do this work. There's no way you can learn this with a two-week training and some pairing.”
Ingrained early on, such beliefs set the stage for a career-long belief in the supremacy of specialization.
Once in the workforce, developers often find themselves in environments that further entrench this single-skilled mentality. As mentioned, traditional organizations often equate busyness with productivity. The structure and incentives in these organizations corroborate this by rewarding individual expertise over team synergy and collaborative efficiency.
Further, Cesário and Ilya identify common statements perpetuating this view in the workplace:
“We will slow down a lot if we start helping each other and learn.”
“We don't have time for training. We've got actual work lined up.”
“Quality takes a hit if we start working outside our specializations.”
In today's tech landscape, specialization appears as a logical response to the plethora of tools and methodologies at our disposal. Take frontend developers as an example. They're expected to juggle multiple languages, frameworks, and paradigms from security to performance optimization. This vast scope can create a fear that diversifying one's skill set will dilute expertise in one's core area.
Thoughts like “If I diversify, I'll spread myself too thin” or “I might lose my frontend expertise if I dabble in backend development" become common. The underlying sentiment? “I can excel in one domain or be mediocre in multiple.”
Every developer, whether they realize it or not, carries a baggage of assumptions, conditioned behaviors, and apprehensions. While some level of specialization is necessary, it's crucial to recognize that these mental models—fostered by years of education and work experience—can serve as barriers to adopting the flexible, multi-skilled approach that Scrum encourages. Recognizing these barriers enables us to question their validity and eventually reshape our professional identities.
As we conclude today's exploration of the historical legacies, we stand on the brink of uncovering deeper systemic issues that often accompany attempts to adopt Scrum.
The next chapters in our series, 'Scrum Masquerade: More of the Same in a New Wrapper' and 'Navigating the New Reality: The Complex Landscape of a Fresh Scrum Team,' delve into the realities of Scrum implementation in many organizations. These chapters uncover how superficial changes often mask underlying traditional practices, and how the true transformation to Scrum presents a complex landscape that reshapes team dynamics and individual roles.
As we progress with our series, we will not only dissect these challenges but also explore in depth the practical strategies to dismantle these barriers. Stay with me on this journey, as I provide you with the tools and insights that can reshape your Scrum adoption, making it meaningful and capable of delivering the benefits you’ve been anticipating.
Continue exploring the nuances of multi-skilling in transforming our Scrum practices and elevating our teams to new heights of agility in the next parts of the series:
Part 3: Unleash Your Scrum with Multi-Skilled Professionals - Exploring The Single-Skilled Dynamics
References
- Cesário Oliveira Ramos, Ilia Pavlichenko. Creating Agile Organizations. A Systemic Approach (Addison-Wesley, 2023)