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