I've genuinely tried to extract the best from SCRUM, be it trying Scrum by the book, or mixing it with a sprinkle of Kanban. It is just not proving to me that it does what it says it does...
I know this topic is widely debated, and many other tech leaders share my views about SCRUM and 'Agile' in engineering teams. We've all been in that situation where stakeholders wake up one day and declare, "WE ARE BECOMING AGILE," imposing SCRUM as the go-to solution, convinced it's the ultimate path to agility.
Why SCRUM Doesn’t Mean You Are Agile
SCRUM is a project management framework designed to align with the Agile Manifesto, using two-week iterations, or “sprints,” and user stories to add structure. While it aims to facilitate agile practices, it often becomes more rigid than agile. Common issues include unfinished work, self-imposed deadlines, and fragmented tasks that don’t truly foster agility. Teams find themselves trapped in what feels like mini waterfalls every two weeks, constantly sprinting to meet arbitrary deadlines. This cycle creates a false sense of progress and undermines the flexibility and responsiveness that genuine agility requires.
In my research on maximizing efficiency in delivering sprint goals, I found that many simply roll over unfinished work to the next sprint. This practice feels like lying to ourselves with arbitrary boundaries.
The Perpetual Cycle of SCRUM
SCRUM's continuous cycle means business-driven engineering and status meetings are a permanent fixture. This leaves little room for activities that don’t fit into “user stories” or two-week sprints, like long-term architecture planning, research and development (R&D), and genuine product innovation. Engineers often feel like cogs in a machine, churning out features without the chance to engage in more meaningful and strategic work.
Surveillance Disguised as “Removing Impediments”
SCRUM is often promoted as a process for “removing impediments,” which sounds positive but can turn into a mechanism for “spotting slackers.” This surveillance requires individual engineers to provide detailed visibility into their work and productivity. While transparency is valuable, the one-sided demand for it can lead to a culture of distrust and resentment. Engineers feel watched and judged, fearing that any fluctuation in their performance will label them as “low performers.”
Dysfunctional Dynamics and Resentment
Imposing such a process and demanding transparency from workers breeds a sense of being stalked, creating resentment and potentially more underperformers. In contrast, when a group of high-performers tackles a specific and time-limited crisis, they willingly provide frequent status updates, understanding that the urgency of the situation, not their social status, necessitates these updates. This difference in mindset highlights a critical flaw in the one-size-fits-all application of SCRUM.
Typical SCRUM Pitfalls
Common engineer traps in SCRUM include:
Prioritizing ‘Done’: Metrics for tracking progress can lead developers to cut corners to complete tasks within the sprint, resulting in a false sense of productivity. Poorly implemented features can pass as “done” just as well as well-crafted ones.
Very Productive Individuals That Don’t Work as a Team: SCRUM can result in highly efficient developers but not necessarily a cohesive team. Without the right incentives, self-organization remains an unfulfilled goal.
Complicated Tasks Get Deprioritized: SCRUM encourages picking tasks that can be completed quickly, often neglecting complex problems that require deep thinking and innovation.
Features Over Robust Code: Quality suffers as the focus shifts to completing features rather than writing robust, maintainable code. Non-technical product owners may not evaluate the technical quality of the work.
No Time for Cross Pollinating or Exchange with Peers: When velocity is the primary measurement, teams have less time for consulting and exchanging ideas, crucial for team development and innovation.
New Bugs Have to Wait: Bugs found after a sprint are counted as new work, incentivizing developers to release flawed code that cannot be addressed within the current sprint.
Ticket-Driven Architecture: Developers working sequentially on tickets can lead to a messy architecture that mirrors the disjointed nature of the ticket system.
One Process to Rule Them All: SCRUM can overshadow all other processes, making it the only ritual that matters, which can break a well-functioning team.
Embracing True Agility: Insights from “Joy of Agility” and “Lean Startup”
To move beyond SCRUM's pitfalls and towards genuine agility, we can draw valuable lessons from the books “Joy of Agility: How to Solve Problems and Succeed Sooner” and “The Lean Startup.” Key takeaways include:
Focus on People, Not Processes: Agile is fundamentally about valuing individuals and interactions over processes and tools. Extreme Programming (XP) practices like pair programming and mob programming encourage collaboration, collective ownership, and continuous learning, fostering teamwork and shared responsibility.
Embrace Change: Agile teams should be flexible and responsive to change, not bogged down by rigid frameworks. Empower your teams to adapt their approaches based on feedback and evolving requirements.
Prioritize Customer Collaboration: Engage with your customers regularly to ensure their needs and feedback drive the development process. This collaboration fosters a sense of purpose and direction.
Deliver Incrementally: Aim for continuous delivery of valuable software. Small, frequent releases allow for quicker feedback and more opportunities to pivot as needed.
Cultivate a Culture of Trust and Autonomy: Trust your teams to self-organize and make decisions. Autonomy boosts morale and innovation, leading to higher-quality outcomes.
Reflect and Improve: Regularly reflect on your processes and outcomes to identify areas for improvement. This continuous improvement mindset is at the heart of true agility.
Learning from Lean Startup: Creating a Lean Environment
“The Lean Startup” by Eric Ries introduces principles that align closely with true agility. The lean approach focuses on creating a minimal viable product (MVP) and continuously iterating based on feedback. Principles include:
Build-Measure-Learn: Encourage teams to quickly build prototypes, measure their effectiveness, and learn from the results. This iterative cycle helps in rapidly addressing what works and discarding what doesn’t.
Validated Learning: Focus on learning what customers really want through direct experimentation and feedback. This minimizes waste and ensures efforts are directed towards creating value.
Pivot or Persevere: Based on feedback, teams should decide whether to pivot (change course) or persevere (continue on the same path). This decision-making process is crucial in staying agile and responsive to changing market demands.
Innovation Accounting: Use metrics that matter for tracking progress and learning. Traditional productivity metrics can often mislead; instead, focus on metrics that reflect true customer value and learning.
Conclusion
While SCRUM has its merits as a project management framework, it’s not a silver bullet for achieving agility. Imposing SCRUM without understanding its limitations can stifle the creativity and flexibility that true agility demands. By focusing on people, embracing change, fostering a culture of trust and collaboration, and integrating principles from Extreme Programming and Lean Startup, we can reclaim the joy of agility. Let’s move beyond the rigid confines of SCRUM and towards a more holistic and adaptive approach to software development, creating environments where teams can truly thrive and innovate.
Yours truly,
Adrian