There is no such thing, not really. There are popular agile methodologies, i.e. frameworks and pre-packaged life cycles that claim to provide varying levels of agility to organizations that use them, your mileage will vary. But there is no one agile methodology.
So if agile is not a concrete methodology does that mean it isn't useful, that agile is not practical? Not at all. while the reality is that there is no such thing as a standard agile methodology, we can easily define agile in concrete terms.
A common definition, one many people use in industry often use is to refer to Agile as the the collection of practices, principles, and concepts that were inspired by the Agile Manifesto, a body of knowledge that lays out a team-centric, iterative approach to delivering value using customer feedback and continuous experimentation.
Agile is best defined as a set of values and principles, as a body of knowledge that is based on those values and principles, and most importantly as a community of practitioners who are passionate about changing the way we work, moving out of the dark ages of industrial era thinking and towards a more progressive mindset.
A common definition, one many people use in industry often use is to refer to Agile as the the collection of practices, principles, and concepts that were inspired by the Agile Manifesto, a body of knowledge that lays out a team-centric, iterative approach to delivering value using customer feedback and continuous experimentation.
Thus defined Agile comes in many flavors and methodologies—for instance, scrum, Kanban, SAFe, and Extreme Programming—and while they differ in their specifics, they are all based on a standard set of principles.
A more straightforward definition of Agile is that Agile is a strategy to help organizations that face increasing market uncertainty by forming self-managing teams that have the autonomy to decide how value is created for their customers, enabling those teams to achieve their outcomes through intimate, direct, and frequent market contact.
We can also define Agile as a mindset, a collection of things we value, beliefs we hold, and the behavior's we can observe. ' beliefs and behavior's about our people, customers, and work. I am very liberally riffing on concepts found in the book, The Agile Mindset by Gil Broza. The result has significantly impacted how I discuss Agile thinking with others. It will have an equally positive impact on you as well. The outcome is a description of an agile mindset that is fit for purpose in our context.
As we agree on what agile means, we can perform the vital work of defining our organizational identity, establishing our context, and growing the structure required to enable agility.
It is not about agile vs. waterfall. It's about humanistic vs. industrial.
If we take a look at the history of organizations and their supporting management systems, it becomes clear that the vast majority of organizations are based on a model that became popular over a 100 years ago.
Most organizations manage through centralized control, authority, deep nested hierarchy, standards to be followed, scaling through bureaucracy, armies of managers because that was how organizations functioned during the industrial revolution.
Waterfall development is an example of industrial management thinking applied to software delivery and project delivery in general. Waterfall asks us to plan the entire project up front regardless of how big that project is. In waterfall we design everything before we build our solution, we build the entire solution before we test it, and we test everything before it goes out to market. Work is handed off across specialists. The way we work is prescribed by people who don't do the work, and governed by people who are often separate from the workers as well.
Arm Your Leaders and Teams to Thrive
Waterfall development is an example of industrial management thinking applied to software delivery and project delivery in general. Waterfall asks us to plan the entire project up front regardless of how big that project is. In waterfall we design everything before we build our solution, we build the entire solution before we test it, and we test everything before it goes out to market. Work is handed off across specialists. The way we work is prescribed by people who don't do the work, and governed by people who are often separate from the workers as well.
The problem with this big batch, command and control approach is that we are no longer in the industrial era. We are in the era of complexity. Product cycles are short, markets are diverse, and accelerated change is the only constant. To thrive in an environment of rapid uncertainty, we cant wait for a bunch of bosses to make descisions, we need the people who are on the ground doing the work to be able to make the key decisions. We need those people to work closely with their users and get feedback as fast as possible.
We need those people to operate with a sense of ownership. We need people to feel safe to experiment, trusted to be authentic in their opinion. We need intense collaboration, and we teamwork. Humanistic management approached emphasize values, principles and practices that promote a working environment based on establishing and operating autonomous teams that are motivated to deliver exceptional value and making the world a better place. Agile is an example of humanistic management, and provides practices that in many cases are diametrically opposed to waterfall and other traditional approaches. Agile is designed for the modern era of volatility and uncertainty.
As stated, one is working in an agile way by working in a team of a diverse set of individuals in a way that maximizes transparency and collaboration.
When that team can establish market intimacy through frequent feedback and co-creation with real users and other market actors, and when that team is granted the autonomy to constantly experiment, iterate, learn and adjust what they work on and how they work.
Agile does not mean scrum, SAFe or any other fixed method.
These are (somewhat problematic) examples of agile methodologies which get just as much wrong as they do right when it comes to increasing agility.
Strictly speaking, there is no such thing as an agile project lifecycle.
That is because the idea of a project is only necessary when your organization is made up of disparate functional departments that require a project to glue everyone together to an outcome.
While organizations starting down the agile road may start by agilifying their projects, it is better to think of agile as the act of standing up a persistent, stable and self-organizing team responsible for the set of outcomes or overarching mission. In this sense, a project is not required to bring people together to deliver.
Rather, we have an investment and the will to bring a team together to bring that investment to bear.
Agile does have a value life cycle. While this value life cycle will be described differently depending on who you ask, the context, etc., we can infer some steps and states that are reasonable in many cases: