Definitions matter. They matter because they frame how we think about the concepts they define. In turn, how we think about concepts affects how we engage with and apply them. Definitions also help us communicate by allowing us to agree on the meaning of things. A clear, concise definition of a concept helps crystalize in our minds what we may otherwise perceive as a disorganized collection of ideas and facts.
A Definition of Agile
No official definition for Agile exists. Instead, Agilists have a set of tenets and principles guiding how they work. As long as work practices foster agility and do not run counter to Agile tenets and principles, they are considered Agile.
As Agile thought leaders and practitioners develop and share new ways of working, the most successful concepts and practices eventually become part of an informal canon of Agile best practices. No formal body exists to regulate or promote this innovation and knowledge sharing. Rather than a methodology, Agile is a community that shares norms, values, conventions, and, to some degree, identity.
This lack of a prescriptive definition for Agile is powerful. It provides practitioners a great deal of latitude in creating Agile approaches best aligned to their unique business or mission context. It gives people permission to try widely-adopted practices, modify them, or reject them based on their own experience applying them.
However, such latitude also brings differences of opinion over what is or is not Agile. Without a formal definition, answers to the question, “What is Agile?” often devolve into Scrum jargon-filled word salad or attempts to define Agile by what it is not, namely Waterfall-based systems development.
Another problem with the standard approach to defining Agile is that it relies too much on the two foundational principles of Agile: The Agile Manifesto and the 12 Principles of Agile. While a deep understanding of the two is essential for anyone attempting to work in an Agile way, they were written from the perspective of software developers who build IT systems. While adoption of Agile practices is growing in many industries outside of IT, the IT-centric focus of most Agile literature and instruction often leaves practitioners outside of IT unsure as to how to apply them within their own context.
Taking into account the limitations in how Agile is typically defined, while adhering to the Agile Manifesto and the 12 Principles of Agile, Agile Cheetah proposes the following definition of Agile:
Developing Complex Systems and Solutions
Agile development approaches are particularly well-suited for developing complex technical and non-technical systems and solutions of all kinds. Software solutions, in particular, are inherently complex because they can be developed and modified in an infinite number of ways. Software tends to grow in complexity as we add new functionality to address new requirements.
Traditional project management attempts to cope with this complexity through predictive planning while Agile takes an adaptive planning approach. Rather than attempting to identify and plan for all project tasks and milestones prior to project start, Agile planning breaks up the planning horizon into increments. This allows us to adapt plans when circumstances change, which they invariably do.
Adaptive planning is most appropriate when we lack enough certainty about business or mission requirements, solution approaches, or technology options to formulate a predictive plan. This is typically the case for most non-trivial software development projects. Agile’s iterative and incremental development and delivery model supports, and is supported by, adaptive planning.
Agile Teams Self-Organize
High-performing teams are crucial to tackling complex projects and the best Agile teams are high-performing teams. They are self-organized and capable and empowered to plan their own work and to collaborate effectively among themselves and with other teams, project sponsors, stakeholders, customers, and end users. This team-level independence, coupled with effective organizational and project governance, affords the flexibility necessary to thrive in less-structured, more uncertain environments. We give up administrative command-and-control bureaucracy, in favor of project flexibility and speed while keeping effective control over projects.
Delivering Increments of Value, Iteratively
Agile teams deliver value iteratively and incrementally. Every increment of value Agile teams deliver provides real business or mission value. Therefore, technical Agile teams are primarily feature-based as opposed to component-based. The traditional project management focus on delivering system components prevents system validation until all components are integrated into the completed system.
This is important because the longer we wait to deliver useful capability to customers and end users, the later it will be before they can validate assumptions behind what we develop. Finding out that the solution is not what is needed or wanted at the end of a project is an unacceptable, yet common, occurrence in systems development. The faster and more frequently teams release functionality, the more opportunities we gain to incorporate what we learn into solutions as they are developed.
Agile Teams are Guided by Collaboration
What Agile teams create is determined through collaboration. Rather than deciding on a solution approach at the beginning and developing it with little to no input from sponsors, stakeholders, customers, and end users, those parties are actively engaged in defining requirements and validating system increments throughout development. This allows us to control scope by limiting what is built to what we know is currently needed and only to the necessary level of complexity. Achieving this level of collaboration requires Agile teams to work transparently by making information about their progress and the nature of what they develop openly and easily accessible. This way of working affords plenty of opportunities to inspect and adapt emerging solutions and team processes and practices.
Conclusion
Our wish is for this definition to help Agilists at all levels of experience explain what Agile is without resorting to talking about a particular flavor of Agile (Scrum, XP, Kanban, etc.) or engaging in comparisons between Agile and Waterfall. We expect our definition to simplify discussions about Agile across diverse audiences.
What do you think of our definition? How would you improve it? Do you have one you like better? Let us know by leaving a comment.
