Over the last decade, lots have been said and published about Agile/Scrum. Companies that have adapted to Scrum have reaped immense benefits by delivering value incrementally and iteratively. Having been an agile/scrum practitioner for over half a decade, I have always felt that there is an inherent inertial resistance from the development team to adapt to the Scrum and often, Scrum Masters (SMs) and Product Owners(POs) are more proactive in a scrum than the development team, and this defeats the principle of Scrum entirely.
Scrum Guide (2020 version) discusses the roles and responsibilities of the development team ahead of the scrum master and product owner, underlining the importance of the development team. The scrum guide uses two keywords to define the development team - self-organising and cross-functional. Scrum principles expect the development team to be self-organising and cross-functional, empowering the team to be responsible, transparent and courageous.
I have had opportunities to closely work with development teams across the globe in their pursuit of adopting Scrum. The development team show no problems embracing Scrum events (Planning, Sprint, Stand-up, Review and Retrospective) and Scrum artefacts (Product Backlogs, Sprint Backlogs and Sprint Goal) - they find it convenient to their quest for a structured, result-oriented development plan. They, however, find it extremely difficult and uncomfortable to adapt to the Scrum pillars (transparency, inspection and adaption) and Scrum values (Commitment, Focus, Openness, Respect, and Courage).
Based on my talks with development teams and observing them closely, here are some of the reasons why development teams don't absorb Scrum principles in full:
Siloed Team Composition: Traditionally, the development team is a siloed structure. A cross-functional development team can easily be interpreted as a team of front-developers, back-end developers, designers, Analysts, QA engineers or more. On top of this, there is a classification based on the roles - juniors, seniors, leaders etc. In such a segregated team, developers experience acceptance and performance pressures.
Lack of Agile understanding: Agile/Scrum principles are easy to understand but hard to follow. The development team needs to know Scrum in practice. Without a sense, the development will struggle to adopt the critical aspects of the Scrum way of life.
Inherent Inertia: If the developers have no previous Agile/Scrum practical understanding, they will resist changes, tend to become rigid and oppose any changes tooth to nail. Especially if the developer or a team has had success in traditional methods, Agile/Scrum might seem irrelevant and unnecessary.
Waterfall thinking: The organisation might have adopted Scrum in operations but still be thinking about the waterfall - Otherwise called "waterfall" inertia. The developers will inherit this subconsciously and believe that Scrum is nothing but a "waterfall in a sprint", and all the hindrances of a waterfall model start happening in a sprint.
Lack of Backing from the Management: Often, developers find that the reward for speaking up is being judged arrogant and insubordinate by the seniors and the management—this percolates into the organisation's culture. By not backing independent voices, management does an immense disservice to the cause of Scrum.
I will post possible solutions for these problems in my next post.
