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 vision of the product to development teams. There is an underlying assumption that the PO represents the interests of the organization at large because he or she is solely responsible for determining what direction development output will take. The PO is also responsible for prioritizing requirements that result in increments of potentially releasable product at the end of every sprint. Collectively, the PO and team members are responsible for authoring requirements that reflect both the business interests and technical interests of the organization. The team is responsible for executing on the requirements or stories to yield the highest quality product possible, while communicating concerns about quality to the PO. The tension between what the business wants and what the team can do is what makes Scrum such an effective vehicle for high quality production.
So where does engineering fit into this mix? Scrum also asks that a PO communicate prioritized business needs, so that the team can focus on technical output. Despite the illusion that stakeholders and project managers in traditional projects provide detailed business requirements to teams, the reality is that teams are often left to interpret requirements documents without detailed input. The result is that business decisions are made by software developers who may lack the necessary business acumen. The flip side is that project managers, sometimes with no technical expertise, end up interjecting themselves into technical decisions. Scrum provides for defined roles in which POs are exclusively responsible for business decisions, teams are specifically responsible for technical decisions, and ScrumMasters watch the process to make sure those lines are not blurred, trespassed, or ignored. This division of decision-making authority creates the right tension to result in quality output with real business value. Although a team with great Scrum business processes can generate business value, a team that employs both the Scrum framework for management and agile engineering practices -- such as test-driven development, continuous integration, merciless refactoring, and pair programming -- can create higher quality output that answers business needs, faster.
Agile engineering without Scrum's structured framework can be chaotic and tends to succeed for small organizations, in which business domain knowledge can be readily shared. Agile engineering, when coupled with the framework of traditional management processes, compromises agile’s values, forcing teams into a system that requires functional divisions and big, speculative planning up front. Agile engineering with Scrum allows agile values to spread across the organization, imbuing business practices with an unrelenting focus on people, quality, and output, rather than input-driven decision making.
As we seek to shift organizational Jenga pieces around the tower to change everything from foundational principles to engineering practices, we need glue to hold the enterprise together. Scrum is that glue, especially for medium and larger sized enterprises. In practice, it improves employee morale and retention, giving responsibilities to those who can competently handle them. It creates trust within and outside of teams by reducing unnecessary bureaucracy and builds awareness of business objectives by incorporating product vision into each requirement.
If agile is to evolve from a set of smart technical practices best suited for small teams into the best possible management framework for organizations of any size, it needs a wrapper that pulls together covers everything from vision to tactics without impeding developers to do the work they love. Scrum is that wrapper: a set of guiding principles and practices that empower professionals to develop products that make everyone in the organization proud.
About the Author
Katie Playfair is a CSM and Director of Client Services at Danube Technologies, Inc. (www.danube.com). As such, she works closely with the five Certified Scrum Trainers, strategic partners, and client service representatives who comprise Danube's ScrumCORETM team, coordinating hundreds of public and private Scrum training sessions worldwide. She is committed to finding the right combination of Scrum services for achieving successful Scrum outcomes, excellence in service and solid ROI. She can be reached at [email protected] or visit www.danube.com.
