If you’re familiar with the Scrum framework, you’ll know that it’s an agile approach to project management that helps software teams worldwide tackle increasingly complex projects.
Despite the common perception that it’s inherently linked to software development, Scrum is actually a philosophy of work, a way of thinking about and breaking down tasks that focuses on adaptability and quick turnovers. It’s mostly utilized by development teams, hence the association with software development, but the framework itself can be utilized by any kind of corporate team, irrespective of type of service or product.
A misperception at such a basic level hints at a deeper misinterpretation of Scrum terms. Terms like “commitment”, “product”, and “velocity” mean very specific things in the context of a Scrum team. The regular misconstrual of these and other terms by upper-level management and other important stakeholders threatens to undermine the efficiencies that come with the Scrum framework.
Unlock the future of intelligent applications with our cutting-edge Generative AI integration services!
Describing the Problem | An Example
A Scrum Master will work with the Product Owner and the development team to flesh out and decide on goals for the upcoming sprint. By effectively decomposing broad strokes product goals into smaller goals, they’ll lay out a general plan for the month-long sprint, a plan that will grow more detailed once work commences and the team becomes more aware of their circumstances, as well as the task at hand.
Once the planning phase is concluded, you could picture the Scrum Master meeting with executives or management to touch base on short or long-term development goals. Over the course of this meeting, the Scrum Master will attempt to describe the focus of the sprint to the stakeholders. If prompted or pestered, the Scrum Master will also posit potential milestones that may be achieved by the end of the sprint. The keyword here is “may”.
As the sprint commences and work carries on, the Scrum Master may meet with management several more times to update them on the team’s progress and likely give them progressively more detailed descriptions of the task and how the team is or will, tackle it. Management will demand results, and in the absence of these results, pressure the SM or the team to deliver them. They’ll want answers; why was the “commitment” from the SM not achieved?
Why this is a problem in Scrum
The example above outlines a typical interaction between management and Scrum team. It also showcases the usual disconnect between upper-level expectations and team-level planning.
Scrum was imagined as a way to cope with extremely complex, sprawling projects with flexible requirements and changing deliverables. And by all accounts, it has succeeded in doing so; Scrum has helped improve the velocity of delivery, quality, and adaptability that a traditional waterfall or spiral model couldn’t even hope to achieve. But its greatest achievement, by and large, has been its ability to cater to assignments at scale, where almost all traditional software development models fail.
Scrum does this by adopting an adaptive approach that sees project deliverables from the outside looking in. It gradually develops a deeper understanding of a project as time wears on. The first and perhaps most critical part of this process, and thus any individual sprint, is a “discovery phase”, during which developers develop this deeper understanding. “Work” during this phase doesn’t count directly towards a deliverable product, but it does provide the foundation for a potential product that’ll be completed in the future.
For much of management, “work” like this doesn’t count as work at all. So an ambitiously planned sprint at an earlier stage in a project just translates to man-hours wasted on this discovery phase. Scrum Masters have two options in the face of criticism of this nature, neither of which are preferable: Either find a way to connect development goals to established KPIs or break tasks down to an unnecessarily granular level so that developers can meet more goals per day, and maintain an illusion of progress.
SERVICE DISABLED VETERAN OWNED SMALL BUSINESS (SDVOSB)
Both of these processes threaten to undermine the values behind the Scrum framework. Scrum focuses on maximizing value for stakeholders in a complex software (or other types of) project. Attempting to describe this “value” in terms of outdated KPIs that don’t even apply in a complex environment is counterintuitive at best. The alternative is to break down a task into so many milestones that even slight progress seems monumental. So instead of working towards delivering value, your Scrum team’s time is spent coming up with buzzwords that justify the work they’ve been doing.
This leads to another misconstrued indicator of value coming into play: unfair and misleading comparisons. If there are two scrum teams, Team A and Team B, and Team B completes twice as many tasks as Team A on any given day, it is judged as twice as efficient. This is incorrect. Because of the way Scrum works and the way teams define and work towards their goals in the face of the uncertainties of a complex environment, progress simply can’t be compared based on the number of backlog items two teams are clearing in a day. This is one of the most critical ways in which management can misjudge team velocity; if Team B is breaking down a task into thrice as many milestones and reporting twice as many milestones in a day, it’s still the slower of the two teams, despite how things seem.
Small Disadvantaged Business
Small Disadvantaged Business (SDB) provides access to specialized skills and capabilities contributing to improved competitiveness and efficiency.
There’s a need for better, evidence-based metrics through which software development teams demonstrate the value of their work. And the metrics themselves are already out there; there’s just a need to move towards more widespread adaptation so that teams can work unfettered by the failings of traditional corporate bureaucracy.
Further blogs within this Failure to Launch: Why Agile Fails category.