When 'General Agile' Isn't Enough - Why Scrum Wins in the Enterprise


Each week, I find myself using Jenga, Hasbro's wooden building block game, as an analogy for introducing agile into the enterprise. Few topics are more hotly debated throughout the software development community than how to apply the simple values of agile to big business. Many approaches favor knocking down the entire Jenga tower to start from scratch with an entirely new foundation of values and practices. Others opt for the comfort of traditional management processes, with some agile practices — like pair programming and stand-up meetings — sprinkled on top.


The reality is that most enterprise customers are proud of their overall structure and starting over isn't an option. So a game of agile Jenga is required to make it work. There are people out there who know how to build bigger, better towers and can identify the right pieces to move, doing so with a light touch. Unskilled players can topple the tower by removing one wrong piece or by moving the right pieces too roughly. Yes, there are plenty of case studies documenting successful agile transformations, but there is little consensus in the agile community about how to create a framework for the enterprise that doesn’t sacrifice agile values. But the answer already exists: Scrum combined with smart agile engineering practices.

Enterprise customers want a framework that is structured enough to lean on when development is chaotic, but also based on agile principles. After all, the Manifesto for Agile Software Development outlines vital principles, but it doesn't provide a framework for actually completing work. Therefore, many organizations have interpreted the principles as antithetical to structure, allowing chaos to reign in what they call a {sidebar id=1} "generalized agile implementation." Others have attempted to integrate popular management frameworks such as ITIL, Cobit, and CMMI with agile principles in order to introduce agile concepts in a less disruptive way, but the result is often waterfall-ish.

The key to striking a balance that is neither anarchistic nor traditional lies in our ability to break from the assembly line mentality, in which a product's quality is perceived to be dependent only on the quality of its individual parts. Traditional business process experts seem to be addicted to compartmentalizing processes into functional disciplines, which often unfold as a sequential chain that moves through specification, design, build, integration, and testing to shipment. To create teams that excel at those activities, we look for professionals who are experts at their functional disciplines. There is an assumption that if each individual contributor is the best, the end product will also be the best. On the flip side, some general agilistas believe that churning out extremely high quality product increments will guarantee success because a high quality product is all they need. Whether a company is extremely traditional or extremely agile, it still relies on the idea that high quality parts inevitably create a high quality end product.

I argue that if we focus first on the high quality vision or direction of the product, the necessary requirements, architecture, engineering practices, and staff requirements will materialize. Unfortunately, traditional development methodologies and processes tend to focus on getting the inputs right first, while generalized agile emphasizes micro-outputs rather than organizational success. If neither traditional nor generalized agile answers how to organize teams of 50 to 500 developers in a way that puts vision first, how do we ensure the organizational Jenga tower doesn't have to be entirely dismantled, yet allow enterprises to maintain some of their existing structure? And secondly, how can we do that while maintaining a focus on agile values?

In order to remain relevant, agile must shed its myopic view of engineering needs and software quality as ends in themselves. Instead, agile needs to address software quality, engineering efficacy, and the output of product in a way that supports the needs of the business. In other words, agile processes should emerge from the drive to create business value. The only framework I can identify that accomplishes this without violating the values of the Manifesto or stepping on the autonomy of engineers is Scrum.

Scrum asks that Product Owners (POs) articulate, as specifically as possible, their

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.