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.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.