What is Agile? And what are the Agile principles and the related value proposal?
Where does Agile come from?
Agile emerged as an alternative to traditional waterfall project in the domain of software development.
What is waterfall project management, also known as traditional project management?
The first formal description of the waterfall model is usually referred to as a 1970 article by Winston W. Royce. Royce. This paper stressed out, even at that time, the limits of this very sequential model.
In 1985, the United States Department of Defense documented this method in DOD-STD-2167A as their standards for working with software development contractors. They requested that “the contractor shall implement a software development cycle that includes the following six phases: Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing”.
This approach may be relevant for predictive projects, even when there are many tasks to deliver and many contributors. But it is jeopardized by projects where there is a big uncertainty and many things unknown like in software development. This is to address the need of software development projects that Agile is born.
The genealogy of Agile
You can track the ancestors of agility until the late 50s. But it is in the 90s that there was a true acceleration with many lightweight development methods some of them that you have probably heard about: rapid application development (RAD), the unified process (UP), extreme programming (XP) and the well known Scrum…
In 2001, 17 software development experts brainstormed to federate the principles of those methods and published the Agile Manifesto.
How the 4 Agile Values of the Manifesto address complexity and uncertainty around software development?
Individuals and interactions over processes and tools
Direct interaction between people is the most powerful way to interact and understand each other. When you have a complex topic to manage, you meet the person, you do not write a mail! Of course, there is still the need for tools and processes. But they are in support and are not the primary driver.
Working software over comprehensive documentation
What customers are working with is software, not the documentation. Actually a good software should be intuitive and should limit the need for documentation and training. But there is still the need for documentation. Especially when underlying business is complex. Documents are the way to capture knowledge as a long term collective memory once the software team and the customers have understood each other.
Customer collaboration over contract negotiation
What the software development team wants is meeting customers’ expectations. Not meeting the contract that is supposed to stand for the collection of what they have understood of the customers’ expectations. So after a functionality is built or after a development iteration is completed also called sprint, the customers can change their mind. This is a tricky point to manage for fixed price contact. We will review this in a later post. What replaces the contract is the backlog of the potential functionalities to deliver. What is fixed in Agile is capacity and time not scope. This backlog gets more mature as the software development team builds software and learns with the customers what they actually need.
Responding to change over following a plan
Still to meet better the customers’ needs, the software development team accepts change. And the team does not require the customers to know and to be sure about everything before starting the software development. Even if change is standard, there is still a long term vision, a roadmap of what is to be built. But it can change as the software development team builds and learns with the customers what they actually need.
What are the Agile principles and the related value proposal?
Empowerment of the software development team with close and live exchanges with the customers are the prerequisites for a motivated team, efficient in its collaboration with its customers.
Limit the work in progress to small pieces of software enable, at each iteration, or by the flow with the new developments:
– Ability to change quickly but still with a long term vision
– Maximize value and outcome (not output)
– Maximize learning and risk mitigation
Enforce by the flow quality and improvement:
– Functional Design and Technical excellence
– Continuously Improve
Deliver fast, small pieces of software:
– Fast value
– Fast feedback from the customers for collective learning
To summarize the value proposal of Agile:
– Increase the Value delivered to the business
– Reduce the Time to Market
– Increase the Quality of what is built and of the Product/Service in production
– Increase Innovation that is a composite of Time to Market and Value
What’s next? Learn more about Agile with the two main frameworks: Scrum and Kanban
Agile is about the principles but it does not explain how to implement them. To learn about the two main frameworks, review my posts on Scrum and Kanban. There are also plenty of other materials around Agile and Agile at Scale. Here is my post to have an introduction to Agile at Scale.