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.
A full PMI-ACP exam prep course. Self-paced with video training modules, you'll quickly be on your way to your agile certification. We love this course from respected trainer Cornelius Fichtner and it's a cost-effective way to prepare for your exam. Upgrades available to add on the exam simulator and study guidebooks.
We earn a commission if you click this link and make a purchase, at no additional cost to you #ad
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?
Elizabeth Harrin is a Fellow of the Association for Project Management in the UK. She holds degrees from the University of York and Roehampton University, and several project management certifications including APM PMQ. She first took her PRINCE2 Practitioner exam in 2004 and has worked extensively in project delivery for over 20 years.
Elizabeth is also the founder of the Project Management Rebels community, a mentoring group for professionals. She's written several books for project managers including Managing Multiple Projects.
