Gartner Blog Network


Agile: Separating Practices from Philosophy

by Clifton Gilley  |  May 21, 2020  |  Submit a Comment

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.

Additional Resources

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

Category: product-development-2  product-leadership-2  

Clifton Gilley
Sr Director Analyst
1 year at Gartner
21 years IT Industry

Clifton Gilley is an analyst with Gartner's Tech Product Manager team within the Technology and Service Providers research unit. Mr. Gilley's research deals with product management across various technology domains, with a special focus on digital product management and Agile product design and development principles. He joined Gartner in 2018. Read Full Bio




Leave a Reply

Your email address will not be published. Required fields are marked *

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.