Agile Project Management is a methodology that is seen by many to be the evolution of project management into system that works in the Information Age. I love that the practitioners of Agile PM are die hard evangelicals of their trade and feel that their methodology is the only one that makes sense in the ever changing workplace of today. I have used tenets of Agile PM in my efforts to provide more flexibility on a project that requires that decisions are made based on the realities observed during the actual project implementation. I feel in the projects I used the methodology, we were able to improve the overall outcomes.
David Taber recently wrote an article for CIO magazine called “Top 10 Ways to Blow Up an Agile Project“. Mr. Taber is one of those writers who just makes sense and I really enjoy reading. I loved this article, and I wanted to take what in my experience are the three top reasons why agile project fail and what I did to avoid these pitfalls. The reasons are his, but the solutions I present are mine.
7. Demand Monthly Waterfall Metrics. Waterfall Project Management methodology would produce reports for team members and stakeholders on a regular basis so they could determine the progress of your project in meeting the defined objectives. Agile PM does feature controls that are used throughout the process. These metrics can be used by the PM to monitor the project on a daily basis. The cards, stories, and units of work do require daily monitoring by the PM, and frankly do not translate well into the traditional progress charts that are used in CCPM, Waterfall PM, and other methodologies of project managements.
Solution: Before you start a project using Agile PM methodology, you absolutely must get buy-in from your clients, internal and external. Everyone has to be committed to the process and understand that the progress reporting is not structured the same way they might be accustomed to seeing in projects that use CCPM and Waterfall PM structures. Because Agile PM is based on trust and involvement of the client in all phases of the project, your client should feel they are intimately involved in the process. They should at any moment be able to tell anyone who asks where the project is and how it is progressing.
6. Don’t Let Users Participate Until the Very End. This is the best way to kill your project. While using a Waterfall PM methodology would insert the user after the testing phase, Agile PM includes them in all phases of the process. The user becomes a member of the project team. I think this is one of the biggest strengths of the Agile PM methodology.
Solution: Your client should become a member of your team. If you are going to use Agile PM to drive your project, you need a client to dedicate the amount of time required to be involved in the day to day movement of your project. It has been said that distance is the enemy of Agile PM and I think that is true. Optimally you would have your client involved in morning scrum meetings, giving their input when and where it’s needed. But this isn’t always a possibility. I know this will make Agile PM purists cringe, but I have sent notes of the meeting to the client when they are unable to attend. But with today’s technology, with Skype and other video conferencing options available, there is little reason why your client should not be available when needed.
2. Don’t Put Your Best Players on the Team. Really? Why wouldn’t you put your best developers on a team? Taking this to a sports metaphor, if you were managing a team in the World Series, if you wanted to win you would field your best nine players. One other challenge identified by Mr. Taber was the proximity of your team — they need to be close to each other to reap some of the benefits of Agile PM. Active collaboration and brainstorming works best when two people are together in the same room.
Solution: Sometimes you will have to compromise when it comes to the developers you put on your team. The superstars in your company may be unavailable for six months and your client wants a product delivered before then. In that case you will need to take the best people you have available at the time. When you company is spread out over the country or possibly even over the world, you may have to take that down one more level — select the best people who are available AND in your office.
I think the Agile PM methodology is best used in situations where you need the flexibility to make decisions using information that may change from day to day. You can use the framework of Agile PM to create solutions for a client that will meet changing needs. In today’s business environment, that flexibility can provide your client with an advantage so they can meet customer needs in six months instead of rolling out a product that will fail to meet new needs.