Sometimes the best way to understand the present is to take a trip to the past. In 2001, a group of 17 people got together in Snowbird, Utah to uncover “better ways of developing software by doing it and helping others do it.”  From that two-day session emerged the “Manifesto for Agile Software Development” (www.agilemanifesto.org). The manifesto highlights 12 principles that the group agreed upon that focus on people over processes, continuous improvement and continuous delivery, welcoming changes, self-organization, and high productivity.  

Every agile practitioner should agree on the fundamentals of this manifesto; I definitely do. I’m not here to criticize the principles and ideas of the manifesto, I want to point out the misconception that it is called “The Agile Manifesto.” To reiterate it is called the “Manifesto for Agile Software Development.” Fundamentally, these concepts were developed to solve problems in software development and based on a few of the principles, I’m sure that you can quickly understand the problems occurring in software development. A few examples:  

Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale. 

__________________________ 

Working software is the primary measure of progress. 

__________________________ 

Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.  

The processes that this Agile Alliance brought with them to the two-day session were none other than the processes that we all have come to know and love: Scrum, Extreme Programming, Adaptive Software Development and others. Jim Highsmith ended his post on the manifesto by saying “We hope that our work together as the Agile Alliance helps others in our profession to think about software development, methodologies, and organizations, in new– more agile – ways. If so, we’ve accomplished our goals.”  

The foundation by which many agile practitioners live was created for software development. At some point, agile became an industry. Consulting and training firms have built empires training and evangelizing the various agile processes and have spun up an entire industry around these concepts. The word ‘agile’ has become a proper noun in a business setting, with many treating it as a religion that they base their entire career on without stopping for a moment and asking what problems they are solving for. You’ve probably heard it before; “we’re agile” or “we’ve adopted agile.” Congratulations, you are able to, by definition, move quickly and easily.  

There is no question that most of these concepts have changed the dynamic of software development. An issue arises when you try to fit a square peg into a round hole. Translating agile project management concepts into a business setting requires more than just saying that it works. Agile project management purists fail because they force routines, ceremonies, and processes without analyzing the necessity of the aforementioned items to the team. Does this team really benefit from having a daily standup? Does this team really need to conduct demos? Does this team really need to use the Fibonacci Sequence to calculate relative sizing (look it up if you don’t believe me).  

The script for agile project management often works for software development but falls flat on its face when applying the script to a non-software development team. This is where the move from classical music to jazz music kicks in.