Stacia Viscardi

Scrum is a seemingly simple creation that tells us how to run Sprints, create burn-down charts, and define “Done,” among other things. You’ll recall reading about Scrum phrases like, “Scrum is easy on the surface but difficult to implement.” That is because, on the surface, the Scrum façade is simple, like a perfectly lined-up row of bricks. Dig a little deeper, however, and find the gnarly, twisted roots of managing complex and chaotic situations, the cornerstone of people and motivation, and remnants of Lean foundations. They are like ancient aqueducts running under a modern street. Scrum is ultimately a balcony from which we may view reality, whatever it might be, so that people can make higher-quality decisions based on a newer and improved version of that reality.

I tweeted some time ago that “Scrum is a system integration test to see if it’s possible for an organization to deliver value in a Sprint. That test reveals the system’s failures, or impediments, that we then must go and fix.” These “bugs”—bumps in the road, impediments—hold the key to what constrains an organization’s ability to deliver what really matters: functionality to make its users, customers, and/or market happy.

All of a sudden, you go and implement Scrum, this exposer of reality, this big test, and it’s no surprise that you encounter some backlash. Just like in waterfall projects, developers are reluctant to hand over code to the testers after the dreaded “code freeze” milestone. Teams and organizations are reluctant to learn what they may discover when they hand over the reality of the situation to the transparency of this test called a Sprint.

Practicing Scrum is also made difficult by its impact on the decision-making structure in an organization. Now, a Product Owner owns the what and the why, the Development Team owns the how and the how fast of delivery, and a Scrum Master is the facilitator and the “revealer of impediments.” These roles and simple mechanisms were created so that complex projects could be conquered one Sprint at a time and to “make software development a profession again,” wherein people could be trusted and respected and thus could explore solutions and ultimately feel proud of their work. Scrum is a framework that was created with people in mind, first and foremost. This is inherent in its five values and is often difficult for traditionally minded managers to grasp when they falsely believe in methodology as the “breaker of chains.”

This is why I say it’s not really about Scrum. It’s about using a framework to discover what was not known before. So, get started and adapt to what is revealed to you. Use the boundaries of prioritization, time-boxing, and roles to help the team and organization understand what is discovered. People’s fear of failure and the unknown sometimes makes it difficult to do the right thing. An organization doesn’t readily embrace its failures, and it is my hope that, over time, by using Scrum or any empirical method, they’ll improve at doing so as an essential part of a journey of discovery.