As hard as it is for a nerd to admit, words matter. One of the challenges of talking to clients about methodology is that two of the most important words have different meanings to IT and the wider organization.
First is the word agile itself. The authors of the Agile Manifesto did a great job of picking a term with universal appeal. Who would want to be less agile? Nobody arrives at work wanting to make development less responsive. The problem with this is that often when the business wants IT to be more agile, development will assume that they are being told to adopt an agile methodology. Most business leaders are not looking for IT to DO agile, they are looking for IT to BE agile. Scrum, Kanban, and XP are just implementation details.
The second word is Lean. When the business wants IT to adopt lean principles, they at least understand some of the agile goals. Lean principles of small batch sizes, shorter cycle times and reducing waste are a pretty good fit with MVP, continuous deployment, and collaborative development. The problem is that when the business asks IT to be lean, IT often assumes that they are being told to implement the Lean/Kanban methodology. The reality is that all of the agile methodologies are techniques to apply lean principles to software development.
When the business asks for lean or agile, they are asking you to be more responsive to their changing needs. This desire for responsiveness can be a great way to start the conversation about how your relationship with the business will need to change. It is really hard to be responsive to a business while following a detailed yearly plan.
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.
Comments are closed