Agile Principles Applied to Team Meetings (republished)
I am fascinated by finding new ways to apply agile principles to non-software development disciplines. I find myself doing it constantly and often with great results. This post is about how I revitalized our team meeting by applying simple agile principles like collaboration, business 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 my 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 and 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 some of the other project managers have had similar challenges and are able to give advice on how to navigate.
Meeting Subject Backlog:
Like any other agile project our backlog is a central tool for prioritizing what to discuss at the meetings. Between meetings new ideas are put into the backlog on the team site 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 in 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 do dot voting 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 have information, including team performance data, which I want to discuss with the team, but I don´t 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 interesting enough to spend time on. Luckily they have so far, but it also serves as a constant reminder to me to make the information interesting.
When we start of 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 them 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 returned to the discussion getting the entire value from it or we found it hard to pick-up where we left off. The backside is off cause that some topics are postponed to a later meeting (put back in the backlog) and the person responsible have prepared for nothing. We accept this because of the value we get from the reprioritization 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 still 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 have found 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 discussed. 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 a reflection 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 that we get more value from the meetings. People 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.
This post is part of my republished collection. It was originally published in May 2009 on Agile Thoughts and I have only made minor changes before republishing it.