I am fascinated by application of Agile principles to non software development disciplines. I find myself doing it constantly and often with great success. This post is about how we revitalized our project management team meetings by applying simple Agile principles like collaboration, value driven prioritization, embracing change, etc.
Before discussing the details a little background information seems appropriate. Apart from being responsible for our project management model and leading my own client projects, a large part of my job as Head of Project Management is to lead our team consisting of nine talented and skilled Project Managers. The team is located at two different physical locations three hundred kilometers apart.
When I took over the team two years ago there was little focus on project management craftsmanship or on collaboration and knowledge sharing between the project managers. To change this and kick-off the new team I arranged a project management day where we discussed both Agile and traditional project management and how we wished to define us as a team. Since the first meeting we have met approximately monthly, spending an entire day to discuss different aspects of project management. We also use the meetings to support each other if we have had rough times on our projects. The team is a safe haven where we got each other’s back. And now let’s discuss the details of the team meetings.
Since we only meet once a month and work from different locations it can be difficult to keep updated on what the other project managers are doing. To share some information on what’s going on we start every meeting with a quick stand-up status. Each project manager focuses on answering the questions; what is my biggest achievement since the last meeting and what is currently my biggest challenge that my fellow project managers might be able to assist in solving. We try not to solve the challenges during the stand-up, but often some of the other project managers have had similar challenges and are able to give advice on how to overcome them.
Meeting Subject Backlog:
Like on a traditional Agile project our backlog is a central tool for prioritizing how we spend our time. Between meetings new subjects are placed onto the backlog with a description of the topic and information about who will be able to facilitate the subject. Every project manager is allowed to add both subjects they can facilitate themselves and subjects they can´t, but are interested in hearing about.
Business Value Driven Prioritization:
At the end of every meeting we discuss the items on the backlog to decide what to discuss at the next team meeting. Sometimes we “just” agree on what to put on the agenda and other times we dot vote to decide. Regardless, we end up with an agenda that has the highest possible value to the team. This sometimes frustrates managements when they want to speak at our meeting and I tell them that they will have to “sell” it to the team and get prioritized. Off cause I have to make exceptions when they insist on stage time, but I try to stick to the concept as much as possible.
At every meeting I there are some information, including team performance data, which I want to present and discuss with the team, but I don´t pull rank and make an exception from the concept just because it’s something I want to share. This means that I only get to share the team performance data, if the team thinks it’s interesting enough to spend time on. Luckily they have prioritized it so far, but it serves as a constant reminder to me to make the information interesting.
When we start a meeting, we decide which of the topics on the agenda is the most interesting and we start with that topic. We don´t work with a timetable unless we have external speakers attending the meeting. This means that we can decide to spend the entire meeting discussing only one or two topics, if we find it sufficiently interesting – this happens more often than not. Previously when we followed a timetable we often found ourselves breaking off a valuable discussion to move on to the next topic. Often we never picked up the discussion again and therefore didn’t get the entire value from it. The backside is off cause that some topics are postponed to a later meeting (put back on the backlog) and the person responsible has prepared for nothing. We accept this because of the value we get from the re-prioritization and often the postponed topics are then selected for the next meeting.
At every meeting we do at least two reflection sessions to evaluate how the meeting is progressing. The first is a short reflection just after lunch. This serves two purposes. First of all we have time left (approximately half the meeting) to change things if there is something that could be improved to provide more value. Secondly it’s used to share information about what was discussed over lunch. With ten participants one cannot follow every discussion during lunch and often others has discovered new valuable insights on topics discussed during the morning while having lunch.
The second reflection is held at the end of the meeting where topics for the next meeting are also selected. This is a standard reflection session focusing on what we should keep doing and what we would like to start doing at the next meeting. Actually the lunch reflection session was a result of one of these reflection sessions and now we find value in doing it at every meeting.
Since we changed the meeting structure from a more traditional structure with a solid timeline to a subject value driven structure, we have found we get considerable more value from the meetings. People now look forward to the meetings, prioritize participating and are more engaged in the discussions than previously. Personally I also find myself speaking less than I did previously which is great – now it’s not only my views and experiences that are shared, but the entire teams.
What is your experience running meetings using Agile practices? Would love to hear how you make sure meeting are not a waste of time.
This post is part of my republished collection. It was originally published in May 2009 on AgileThoughts and I have only made minor changes before republishing it.