When learning about the Agile Framework, it is important to understand where it started. The Agile Manifesto was created in 2001 by a group of software developers (Agile Alliance, n.d.).
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
(Agile Alliance, n.d)
Once word got out about this new way of doing software development, it did not take long to translate for general business use. One of the benefits for business is that an adopting an agile mindset enables the breakdown of organizational silos that impede business productivity (Rigby, Sutherland, & Takeuchi, 2016). In a word, agile fosters innovation. Agile allows organizations to ignore sunk costs that marry them to failing projects, and move onto more profitable, greener pastures. To properly use agile concepts in your business, it is important to remember that this is not a static set of rules. By design, agile is dynamic, and change is not only acceptable, but actively sought. Adopting agile means adopting a new mindset. Let’s look at some of the concepts outlined in the manifesto.
Individuals and Interactions, over Processes and Tools
This enables emphasizing relationships over rigid policies and procedures. Focusing on the human element fosters trust, and enables communication. This provides opportunities to learn and grow, and limits mistrust and unhealthy competition as people work together toward a shared goal.
Working Software over Comprehensive Documentation
This is more challenging to separate from software design, but there are still applications for general business purposes. Traditional “waterfall” project management requires extensive documentation and upfront planning. This is particularly useful in some fields such as construction, where there are basic steps required that don’t change much over time. A house needs a foundation, walls, plumbing, a roof, and such, though the various designs may change from one building to the next. Knowledge work is much less structured. Knowledge workers solve unique problems in unique ways. There is not always a best practice to follow. In this case, advanced planning would be an impediment to progress, rather than a useful set of guard rails to keep the project on track. Making decisions closer to real time rather than up front enables knowledge workers to select the right tool for the job once more information is available.
Customer Collaboration over Contract Negotiation
This concept is also about trust. Working with external organizations can be risky, which is why lawyers painstakingly set out the parameters for a transaction up front. Changing contracts already in progress can be extremely challenging. This concept suggests that you want to build a foundation of trust that goes beyond the terms of the contract. By choosing to work with people or organizations you already trust, some leeway may be given to improve a project’s outcome. Waiting for the lawyers to hash out new terms for even minor changes is not very productive. This is not to say it is unnecessary. It is simply easier to work in a positive and constructive environment where both the customer and the supplier or other party benefit.
Responding to Change over Following a Plan
This concept enables flexibility when circumstances change. It is okay to change a plan in progress to meet unexpected requirements. Rigidly sticking to a plan without allowing flexibility to adapt is a recipe for disaster. The High Reliability Organization (HRO) framework provides many examples of how sticking to the plan resulted in catastrophic failure, loss of life, irreparable harm to people and property, or all of the above. The HRO framework is increasingly being applied to smaller incidents, where failure is not as catastrophic, yet the outcomes are negative. Shipping a product that will ultimately be recalled for safety or quality purposes can be expensive. Allowing for changes as flaws are discovered is much cheaper in the long run – and in some cases is also safer.
This brief interpretation of the Agile Manifesto is meant to be an introduction to the basic agile mindset. We will continue to review how to incorporate agile processes into your organization and build upon this foundation. To learn more about the Agile Manifesto, you can visit the Agile Alliance website.
References
Agile Alliance (n.d.). Agile Manifesto for Software Development. https://www.agilealliance.org/agile101/the-agile-manifesto/
Sutherland, J., Rigby, D. K., & Takeuchi, H. (2017, March 21). Embracing Agile. https://hbr.org/2016/05/embracing-agile.