There’s a tendency in the product management and product development communities to conflate Agile practices and Agile philosophy, and this poses a real danger to successful adoption, implementation, and deriving value from Agile transitions. This is well-evidenced when you watch how quickly and easily organizations conflate “doing Scrum” with “being Agile”. While this is a difficult behavior to break, it’s fundamental to making the cultural and process transitions necessary to derive value from such approaches.
I’m going to pick on Scrum a little bit here, mostly because it’s the most obvious offender. Some of this has to do with a lack of understanding of the underlying philosophy. Some of this has to do with poor coaching and training that focus on certification in Scrum over Agile principles. And some of it is just intellectual laziness on the part of people who are considering how to become more agile in approach and see a “silver bullet” in the defined methodology that Scrum provides.
This is in no way intended to imply that Scrum is “bad” — in fact, it is my go-to recommendation for teams beginning their Agile transformation. It provides an excellent foundation of good Agile practices in an easy-to-digest framework that can be generally applied to solve many business problems. However, it’s this very prescriptive nature that plays against it when organizations adopt it blindly, and without taking time to understand the philosophy that underpins the practice.
Agile as originally presented was intended to provide a philosophical approach to improving software development — one that was based on central tenets of trust, customer centricity, and iterative work efforts. This is clearly reflected in the Manifesto for Agile Software Development and in the twelve related Principles. Agile does not provide a framework or methodology for practicing these tenets, however — that is left to specific practices (Scrum, XP, Kanban, etc).
But someone fully practicing the philosophy of Agile knows that methodologies are a starting point — that the needs of the team outweigh the need of the methods (“people and interactions over processes and tools”). They understand that the goals of product development are to meet customer needs, not just business objectives (“customer collaboration over contract negotiation”). They get that we must embrace the unknown and drive it out through experimentation (“responding to change over following a plan”).
Those who are truly agile understand that blindly following a methodology is the antithesis of agility. Methodology is a starting point from which an Agile team will adapt and adopt in order to continuously improve.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.