In the software development industry and beyond, the term "agile" is everywhere. But, much like the "organic" food craze, the rise of agile has also been accompanied by considerable head-scratching. What does it mean to be agile? Certainly, not all of the organizations boasting of agile practices can actually be agile? Unfortunately, there isn't a concise definition to encompass the myriad meanings packed into the term. In fact, the definition of agile is so loose that it hardly helps in assessing which organizations are using practices that are truly agile and which are just calling traditional methods by a new name. In part, agile's fuzzy definition has to do with the fact that it is, by definition, an umbrella term: Scrum, XP, DSDM, Crystal and other agile methods have emerged as subsets of the broader "agile." But, even then, those subsets seldom include the concrete processes a team needs when adopting a new management paradigm. In that sense, the term agile has become bankrupt of meaning: It serves more as a marketing buzz word than a defined set of processes. Because organizations require those processes-as a kind of roadmap to management success-Scrum has become the most popular of the agile management methods. But before further discussing how Scrum and its iterative, incremental approach to project management have appealed to teams and organizations alike, it's worth first considering where it came from.
If you follow Scrum's roots, they lead back to the Agile Manifesto and its break from traditional waterfall management, even to the Lean Manufacturing practices pioneered by Honda and Toyota in the early 1980s. But dig a little deeper and Scrum's family tree extends all the way to complex adaptive systems theory: a theory of evolutionary biology that tells us, when species are threatened or move closer to chaos, they adapt in order to survive. Most software developers would likely describe the work they do as chaotic-at least in relation to conventional engineering practices (i.e. bridge building). Scrum's fixed, repeatable work cadences, called Sprints, address this chaos by creating isolated periods of stability during which developers can focus on their goals. In that sense, Scrum provides the right balance of security-in the framework's principles and processes-in the midst of an unpredictable development environment. When you consider that Scrum challenges teams to always be growing and improving, it makes sense that it has emerged as the most popular agile management method.
Granted, that's a high-minded explanation of what makes Scrum so effective. Certainly, managers desperate for a better way to navigate the complexities of today's business world are satisfied with the results: frequent communication and high-impact collaboration that delivers products on time and under budget. One of the most important ways Scrum facilitates this communication and collaboration is through the "Daily Scrum," which actually builds an exchange of ideas and information into the process itself. As part of Scrum's iterative work cycle, team members meet every day to report on their progress since the previous day's meeting, what they'll be working on until the next day's meeting, and, finally, any impediments that obstruct their progress. It's a simple meeting with a simple purpose: To get people talking to each other and working toward the same goals.
That might sound like a modest goal, but communication is the key to highly performing teams. When information is shared, everyone knows who is contributing what and if impediments must be resolved to achieve success. Additionally, this level of engagement among team members builds bonds and creates a sense of shared responsibility. When that occurs, individuals begin to reorient their approach to work from personal heroics to the communal gratification of participating in a functional team. Then add Scrum's Sprint Planning and review meetings, which punctuate the beginning and ending of each Sprint and give the Product Owner a time to articulate vision and assess the team's work. These meetings make sure that it isn't just team members who are talking to each other, but that communication is also taking place between Product Owner and team. It's those formalized points of communication that allow Scrum teams to deeply understand the goals of the Sprint and the software they're developing, resulting in the delivery of a product customers truly want.
From an organizational perspective, Scrum is an attractive option because it is a lightweight framework that drives business value, without burdening team members with prescriptive engineering practices. For organizations about to adopt agile management processes, many approaches recommend starting with a clean slate. That's a sizeable challenge. It means ditching everything familiar to employees and re-building its culture from scratch. Given that organizations typically spend years developing their infrastructure-from values and culture to job titles and processes-razing what they've built for a fresh start simply isn't an option. But the Scrum framework is lightweight, which means it contains only a handful of roles, rules, meetings, and artifacts. In short, Scrum acts like a management wrapper, which can be carefully draped over an organization's existing structure with