top menu

Lessons Learned on an Agile Project

Lately, the Agile Project Management approach has become very popular, and it seems that everyone is a scrum master. Here are lessons learned on an Agile project for every project manager. Now I have to disclose to you that I am not a certified Agile PM. I’m sort of a fan of the traditional approach, but more and more, Agile is taking over. What I would like to share with you today is a bit of a lessons learned from my first Agile project. Project Methodology Main PageLessons Learned on an Agile Project

First of all, Agile PM does not mean that we don’t have to plan, or that we can slack off on documentation. On the contrary, I want to warn you not to underestimate these two aspects of project management. When I was asked to take over one of our “projects in distress,” the project was three month behind schedule and the cost to implementation ratio was deep in the red. Our consultant had sold the idea of Agile PM and my company followed it. For the first three months of the project developers were talking to functional users and going through implementation cycles. The users rejected the implementations because something was missing or incorrectly implemented. Needless to say, there was not much documentation available. So when I took over this is what I did:

1) Organize a user training program about Agile Project Management. Being a newbie to Agile myself, I reached out to my colleague who had experience in Agile PM and we organized user training about this topic. We explained how Agile works, what we expected from users in terms of user story documentation, and what we would expect from our consultants. It turned out that this was a very important step because most of our users had no idea what a sprint was (gathering people involved in the project to focus on its development) and what was expected from them. Agile Project Management

2) Using elements from the traditional project management approach, I redefined and documented the sprint cycles, communications plan, and general project structure. As a result, each sprint now required an official sprint scope document that clearly outlined which topics were in the scope for the sprint. Moreover, I established clear deadlines for submission of user requirements and specifications. The goal was to establish a fair environment for both the functional users and the developers. I expected the users to tell me what they needed, I asked for agreement between functional users and developers on what was possible in a sprint, and I expected the agreed-upon scope to be implemented.

3) If you work in implementation sprints, it is easy to loose sight of the big picture. So I created a diagram that visualized the expected project objective and all user stories had to contribute to that goal. Project scope must be managed all the time.

Using elements from traditional project management, my colleague and I were able to turn that project around and I’m quite confident that we will end it with success. So what are the lessons learned? Even if you are not a certified Agile PM, you can manage an Agile project. Many aspects of a traditional project management approach should be used in Agile too. Planning might be a little different under Agile but it is still necessary. And so is scope management, communications management, procurement management, and cost controlling.

Until next time.

No comments yet.

Leave a Reply

Powered by WordPress. Designed by WooThemes