We’re Moving to Agile…

In the last few years I think we’ve all heard development or IT teams say that they’re moving to Agile because it will allow them to deliver faster. What normally happens is that they change overnight to running meetings they call ‘Stand Ups’, ask stakeholders for ‘Epics’ and ‘User Stories’, and then spend a number of ‘Sprints’ building something which doesn’t really meet the business’ needs. 

The reason for this is simple: the Agile methodology wasn’t successfully applied (just like the one before that). 

Agile is a great methodology for getting things done quickly if it’s correctly implemented and the transition to using it is well managed. Unfortunately, ‘we’re moving to Agile’ is often shorthand for an overnight change that practically removes planning and design (aka The Boring Stuff) and encourages going directly to hands on development or technical build (aka The Fun Stuff). The result is that the same problems occur just as surely as before but in a different way. 

So if the result will still be the same why bother changing?

One of the main reasons is that methodologies are sometimes used to mask the underlying problem causes, and, rather than fix these, it’s easier to blame weaknesses in the methodology (and all of them have weaknesses). During the transition there’ll be a lot of talk about ‘embedding the change’ and ‘learning through mistakes’ but, if the organisational culture and behaviours of teams, managers and leaders remain unchanged, it’ll lead to the same result.

I’m very keen on methodologies because they bring a lot of benefits, but I’ve never seen the ‘one size fits all’ approach work regardless of whether it’s PRINCE2, Agile, PMI, MSP, or CI for one simple reason: 

There isn’t a single methodology that fully accounts for the end to end needs of every business and it’s customers.  

For example, Agile development works well if the expected outcome is clear, deliverables are of sufficient quality, and output meets the needs of the customer, business, and operational support organisation. Operational support is less dynamic in is nature, and the output of the Agile process must be ready for delivery into the risk managing change & release processes defined under ITIL for effective Service Transition. These processes tend to imply delivery quality gates which are part of Prince2 (and MSP).

If methodologies are pragmatically applied to allow resources in different parts of the business to work together in an agreed way, success is far more likely. This is important because customers prefer suppliers to deliver what was agreed, when it was agreed, and at the quality agreed. They’re not interested in ‘failing fast’ because their end customers won’t accept that.

To help solve this problem I suggest working with a pragmatic, external consultant who is objective, methodology agnostic,  has experience of the pitfalls, and will work with you to transition to the right model for your business. The outcome will be integrated, cross functional teams who can successfully meet the demands of your business and its customers. 

Pragmatist Consulting provides a pragmatic, emotionally intelligent business and change consultancy service which we tailor to fit your needs. We focus on helping you turn your business problem into a success story.

27 February 2020