The 8 dangers of implementing Agile

by ·


Keith Richards speaking at the APM Conference

Keith Richards speaking at the APM Conference

As if adopting Agile wasn’t scary enough, Keith Richards from KRC talked about the 8 dangers of Agile at the APM conference last month. And here they are:

It arrives bottom up

“We don’t really want the techies taking over the organisation,” said Keith.  “This bottom up stuff is a bit dangerous.”  He made the point that Agile isn’t something that should grow organically from the IT department.  Make sure your Agile deployment is a conscious decision.

It looks simple

“It if was simple we wouldn’t need to be trained up in PRINCE2,” he said.  My view is that everything is simple when you know how it works, but Agile looks deceptively simple from the outside. Be cautious with your implementation, Keith recommended.

It’s mixing oil with water

Agile has a particular approach to governance that doesn’t sit well with some heavy corporate governance structures.  Agile (in my opinion) isn’t anti-management, but it is nimble.  Some companies aren’t nimble, so give some thought to how the two approaches will sit comfortably together.

You start with timeboxing

Timeboxing is the Agile approach to getting things done by a fixed date.  Chunks of work are packaged up and delivered at the end of a timebox, and this means that projects deliver on time.  I honestly thought timeboxing would be a good place to start, but Keith flagged this as a potential danger.  Put Agile into a wider context, he suggested.  This means not starting with timeboxing, but starting instead with an education campaign and really understanding what you are setting out to do.

Teams self-manage

“Who’s going to pull this together?” Keith asked.  You can’t rely on teams to be self-managing when there are numerous people or multiple strands involved in a project.  People need a single point of contact.

It grows virally

Don’t let Agile spread virally, Keith warned. While this might work for some things (like adopting a corporate wiki), it won’t work with Agile.  You will end up with variants that don’t work and no consistent understanding of what Agile is all about.

The people upstairs don’t get it

This is a very real danger, but I would argue that it’s a problem for all project management approaches, not just agile ways of doing things.  If you don’t have senior stakeholder buy in and understanding, making any type of process or methodology change is going to be very difficult.  You can counter this danger by increasing your education campaign to cover those stakeholders, as well as the people who’ll be doing the doing.

The tools drive the transition

Keith flagged this as a danger for Agile implementations, but again I feel this is a danger for any change in methodology.  Don’t let tools drive the transition to a new way of working.  The tools should support your new processes, not the other way round.  In the case of Agile, don’t buy some kind of software to support development and then hope it will ‘fix’ everything.  Software doesn’t roll out new processes – you do.

What other dangers have you come across from deploying Agile on your projects?  Or from deploying any new project approach, for that matter?

Read what else Keith talked about at the conference here.

  • http://blog.dayleyagile.com/ Alan Dayley

    In Agile, teams do not “self manage,” teams self organize. This is a significant distinction. The business manages “What?” is to be created. The teams organize “How?” it is created. It’s important to be careful with the terms and to help managers understand that they still have a very important role in Agile. Figuring out what should and should not be built is not an easy task.

    And, yes, teams can self organize very well and very powerfully.

  • Elizabeth

    Alan, thanks for the clarification. I didn’t understand this distinction, and I’m sure many others haven’t realised it either.

  • Pingback: Eight Arguments for a More Flexible Project Management Approach | Project Management Competence Assessment Tools

Previous post:

Next post: