Over the past few months I have heard myself say the words “I’m not an agile-ist but ….” an awful lot. I then continue to talk about some of the principles that I believe underpin our ability to deliver value through technology. These principles include:
- Focusing on delivering small quick projects because all the evidence suggests we can deliver small quick projects effectively while we struggle to deliver large complex projects.
- Delivering through iterations as new ideas and innovation emerge over time, through the interaction of people rather than from some belief in breakthrough thinking and one off changes.
- Ensuring change is led by the team, or as close to the team as possible, rather than imposed from leadership because people don’t resist change, they resist being changed.
- Facilitating collaborative working and prioritization to understand what we will deliver now and what needs to be delayed until later.
Most of my clients agree with these fundamental principles and the agile fans among the groups smile and enthusiastically tell me it all sounds pretty agile to them. And it is. While not a direct lift from the agile Manifesto they are pretty consistent with its philosophy. I subscribe to these principles and believe them to be fundamentally true and my experience is that teams who live these principles achieve substantial improvement in performance and deliver superior value to their organization through the smart use of technology.
So if I believe in these principles why do I say I’m not much of an agile-ist? I say that because while I believe in “agile” principles I am very ambivalent about methodologies, including agile methodologies, and an outright critic of those that believe methodologies are the panacea to IT’s ills. I just don’t think it’s so. Whether it’s Scrum, Kanban, SAFe Prince2, PMI, ITIL, COBIT, Lean, 6 Sigma, Lean 6 Sigma or one of the many I haven’t listed, take your pick. It’s not that they are wrong, indeed the opposite is largely true, they have great lessons and guidance. It’s just that delivering value from technology is not about following the “recipe book”.
Please don’t take anything I have just said as a pitch for ignoring methodologies. They have their place and provide great value when used well. There are two excellent uses for methodologies. The first is as a guide to a practitioner who is trying to work out what to do or how to solve a problem. The key is in the word guide, even experts need support and help sometimes and methodologies play an important role as a “guide to the wise” but should never be seen as a rule book for the fanatic.
The second is to provide a common language for a team so that when I say ABC you hear ABC and interpret that the same way that I meant it. Miscommunication is a common issue and when it occurs it undermines effective action. Methodology helps to prevent this by providing a common language and enhances the ability to get to a solution and therefore value quickly. Every team needs a common language but it doesn’t really matter what that language is, you just need your team to be fluent in the same language.
If your preferred language is based on an agile methodology then great, invest in it and move forward. If however your preferred language is a waterfall methodology then great, invest in it and move forward. The point is that it is not the language you choose that makes the difference, it’s the mindset that you bring that makes the difference. To put it another way, mindset is independent of methodology and if you focus on an agile mindset the actual methodology you use is almost incidental. On the other hand, if the methodology or process becomes more important than mindset, you will end up developing bureaucratic and rule-bound operations. To adapt an old saying a “fool with a methodology is still a fool”.
A recent study commissioned by HPE’s Digital Research Team on the effectiveness of DevOps teams reinforces this. The study sought to validate the relationship between value delivery and DevOps maturity. What they found however was that “…. those with the least mature DevOps implementations were seeing the most success. While that sounds like a paradox, it’s the approach the teams took that matters.” They go on the say that “…. the informal DevOps leader segment appears to place culture, sharing, and collaboration above tools and techniques” and “DevOps success may not be directly linked so much to process maturity and standardization as it is to a mindset of exploring, experimentation and continuous learning.” (emphasis added).
The conclusion, when it comes to IT team effectiveness and value, mindset beats methodology hands down. So, if you want to be successful at delivering value from technology for your organization consider the following:
- Focus on the principles of agility and bake those principles into all decisions that you take. If you consciously bring those principles to bear on every decision within the team then over time you will create, embed and maintain an agile mindset.
- Invest in your chosen methodology so that you can create a common way of operating and a common way of talking to each other. However, ensure you use this methodology as a guide to action and not as a rule book or process map.
- When the methodology and the principles conflict, choose principles every time.
First published on www.itchronicles.com