Why Stakeholders Need To Be Involved In Scrum

Scrum is a procedure for producing software. It allows companies to respond quickly to change and leverage the unique skillsets of their employees to rapidly develop good solutions. While Scrum is designed to achieve agility, its implementation requires a high degree of rigidity to execute well. In this sense it is a process like any other; a set of rules that allows everyone involved to know what happens next, who they should go to with problems, and how to communicate effectively.

Companies who like the idea of being agile, but do not like the rigid process of Scrum, often cherry-pick their favorite parts out of the process and try to tack them on to whatever they’re already doing. When their projects grind to a halt and people point fingers, the process is often a convenient target. In that case it should be; writing good software is like baking. If you’re halfway through making lasagna and decide you’d like cake instead you don’t start tossing sugar on top of the cheese. The same is true in software development. It’s better to have good lasagna or good cake then a sticky inedible mess. If you’re going to follow a recipe for software development you have to fully commit to it, all of it, and support it as an organization to be successful.

One of the most common pitfalls for companies trying to implement an agile Scrum process is a lack of stakeholder participation. Having a customer advocate (or the customer themselves) in the room during the project is a critical driver at the heart of Scrum. When the stakeholders are too busy or disinterested to participate, the vision of what the customer wants and the actuality of what the programmers build begins to diverge.

The Scrum process is a collaborative one. It is built on the assumption that the stakeholders will be involved in the decisions driving the creative process. Requirements should not be thrown over the wall to the developers from the business side, or handled by the developers as needed.  Building a requirements backlog should be a process in which the business and technical tribes come together to develop a shared understanding of the needs of the client. If the business side is involved and invested in advancing and informing the process of writing good software, then everyone benefits from reduced churn and improved forecasting clarity.

To succeed in the modern business environment, software companies have to stay agile to respond to evolving customer requirements. The traditional business segmentation that works with blueprints and assembly lines will not work with software development. Organizations need to truly buy into the agile tenant, “customer collaboration over contract negotiation” [Agile Manifesto, http://agilemanifesto.org/], and start allowing their customers to control the work done on their behalf.