Inarticulate ramblings of a management consultant

the day to day experiences of a consultant operating in weird and wonderful client situations

Agile – A change in methodology or something much deeper and altogether more challenging?

I’ve just spoken at an excellent conference on project management in KL. There were some truly interesting seminars on project recovery, risk, the danger of optimism in projects, and of course Agile. It is extraordinary what sort of reaction this topic generates amongst proven, seasoned project management professionals and the range was certainly on display at the conference. I saw everything there from fear and loathing, to contemptuous dismissal, to almost evangelical zeal and trust.

So, what is the issue here? Why does it generate such extreme emotions and reactions amongst my fellow PM professionals, most of whom are a pretty reasonable, grounded and intelligent group of people whose skills are without question and whose company I enjoy.

As far as I can see, there are a few reasons:

  1. As with all new concepts, the early adopters are driven, passionate and not afraid to claim that the new methodology is the solution to all ills. This plays badly with experienced PMs who probably feel that they’ve done most things, made most of the mistakes at some stage in one or other project. I’ve not met anyone who didn’t see some value in Agile…its the ‘snake oil’ sales routine which puts them off.
  2. Whilst most experienced PMs are used to, and to some extent, thrive on the challenge of change, one thing that they carry with them as a constant, is a way of doing things. I’m loathe to call it a methodology because it’s so much more than a framework or operating manual. There are certain activities or processes which we all have and feel ownership of that anchor us in the volatile and stressful world of a project. Whilst most PMs will claim to have an ‘open architecture’ approach to working with clients, “lets use what works in your environment”, I’m not sure its true. The thing about Agile is that in the eyes of the acolyte, there is no halfway house….you cannot be half pregnant with Agile! So adoption represents a big risk…and PMs manage risk but like all of us, don’t necessarily enjoy working with it and are fundamentally trained to be a pretty conservative bunch of folk.
  3. Finally, there is a huge amount of methodology related to people in Agile which instinctively makes sense…the concept of commitment, empowerment, autonomy, mutual obligation, the mature nature of the proposed relationship which in TA (Transactional Analysis) terms, one would classify as Adult; Adult. The problem is that it’s hard to do, in particular if an organisation operates in a hierarchical, or silo based manner outside of the project space. As has been proven over many years, the difference between good and excellent PMs are those communication, change, and people capabilities and making them aware of their limitations in this regard….well, lets just say, it provides yet another source of challenge at a deeply personal level.

From a personal perspective, I’ve absolutely no doubt that with time and the arrival of a new generation in the PM workspace, a form of Agile will become a key part of the landscape. As with all new concepts however, the teething period will continue to challenge.

Fellow PMers, responses please…what’s the cause of the extreme reaction? Answers on a postcard, or in this case, as a comment!

Categories: Agile, Change management, Complex transformation, Consulting, human behaviour, Methodology, Project Management, psychology, Transactional Analysis, Transformation

Tags: , , ,

6 replies

  1. Ben, I personally think a lot this is down to misrepresentation of what Agile is trying to improve, fix or replace, and unfortunately certain groups of people with a vested interest in their own agenda take extreme views. As a PM, I think that Agile methodologies should be viewed as an alternative delivery approach, not a replacement or challenge for anything that a PM should traditionally be concerned with. I’ve sat in numerous training sessions and presentations where the age old use case of a Waterfall approach to software development is quoted, destroyed, and Agile presented as the saviour. But the reality is, as a PM, one still needs to be concerned with the Inception phase, initiating a project and actually agreeing that what we’re about to embark on makes sense. Agile doesn’t replace that. At the other end, during Closure, again Agile doesn’t offer anything to replace the core steps and process that a PM needs to be concerned with. It’s during the Delivery, the execution and control phase of a project where I see the value add. As long as we educate our stakeholders, and our PM to understand this, then Agile development and delivery methodologies can make a lot of sense. I like the idea of short iterative development stages with frequent user feedback loops, milestones to be measured against, but that can’t go on open ended. Projects don’t run that way in real life, the money stops eventually! To me, Project Management is a discipline, and in my area of work, Agile is nothing more than a Software Development Methodology containing a set of best practices, tools and processes that need to be managed in the overall context of a Project, hence are complimentary, not a challenge to or replacement for project management best practices.


    • Thanks for your response…much appreciated. I agree that there are many aspects of good PM discipline which are required, regardless of the approach…the challenge comes however when you start seeing organisations as a whole wanting to adopt a PM approach to their BAU activities. They see the value of the cultural, people orientated dimensions around decision making, autonomy and personal accountability which are core to excellent project management but not necessarily enshrined in what is taught! Too much of the syllabus is focused on the tools and too little around the change. That is where Agile as an overall approach would appear to have an advantage.


  2. I agree with your three reasons. In my experience, emotional reactions to Agile tend to be primarily because of a lack of understanding and education. I often hear Agile quoted as a methodology and or contrasted against Waterfall, as if risks and issues mean nothing. The misunderstanding is further peppered with examples like one I had recently with a very large retailer who’s entire development team had the management believing that because the Agile Manifesto refers to “working software over documentation” no key documents were being written or updated what-so-ever and the risk team were very upset and very much anti Agile.

    Agile really isn’t for everyone. While there are 12 guiding Agile principles, it is very flexible which can be dangerous in the hands of inexperienced professionals. Methods like for example Scrum and Kanban require education and ongoing coaching for a period of time until the team are working as a self managed team where trust and daily accountability are at the for, velosity stable etc etc. These changes are not being recognised and implemented as the “organisational behavioral change projects” that they really are, required to support the adoption process and be successful.


    • Thanks Bron for your comment. You make a very important point…when those sort of organisational and behavioural changes are not being encouraged or focused upon in other parts of the business, its very hard to do it in an isolated way in the context of a single project. That’s in some way the biggest challenge, isn’t it? Managing stakeholders who expect either too much or not enough of the Agile way of doing things!


  3. Thanks for sharing. I like it.

    You hit many points regarding the adoption where people think only practice is enough to be Agile. Moreover, people think they want to do Agile but what they really want, at the end of the day, is to look at what proposition they want to pursue. Agile must be the mean not the destination. And project manager must help team/ organization to see the risk or opportunity that may jeopardize or benefit the product and service.

    Agile is not a methodology but a set of value derived from Lean. The key is learning by iterating to get to the right value, customer is happy to pay for.


    • Gun, very good to hear from you. The challenge of changing behaviour through the adoption of Agile is indeed the primary issue. Some organisations will indeed use this lever successfully, for others however, we may need to look at other methods as well


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s