Agile Project Management

In the project management world, the Project Manager is the one in charge. The one that created the plans and make the decisions. In short, he or she is the king…
In the world of Scrum, there is no Project Manager. There are just 3 roles, and the focus is teamwork.

Two events are mutually exclusive if they cannot occur at the same time. An example is tossing a coin once, which can result in either heads or tails, but not both.
I would say it is fair to claim that Project Management and SCRUM are mutually exclusive. It is impossible to do traditional waterfall together with SCRUM.

But with that said, in my opinion,  it is definitely possible to combine the two and do Agile Project Management.

Project Management merged with SCRUM? The king is dead. Long live the King!

I think it is fair to clam that more than often, Project Managers are what we could consider “alphas”. They are “the leaders of men”, “the one in charge”, with a personality and ego reflecting a desire to be in the driver seat. And this is not a bad thing. This is in fact what is required of the role. If you are not playing this part, you might even been considered weak…

Or…?

Is it possible to play this role somewhat differently, and use some of the learnings from the agile world to deliver even better projects?

First of all, in my view – a really good traditional Project Manager are actually following a lot of the same core principles that SCRUM advocates. Since this is a short article, I will settle by listing the top 5 tip how traditional project management could evolve into what could I like to call agile project management.

1. Improve communication with “standup-meetings”

This might be the single most important tip to any Project Manager; Borrow and use the power of the daily stand-up meetings in SCRUM to improve communication while keeping it short, to the point, inform each other and to discover the trouble spots as early as possible.  To achieve these things, SCRUM dictates that the daily scrum meetings should be;

• Maximum 15 minutes
• Only the team members can speak (but others can attend and listen)
• It’s all about informing – not reporting
• The 3 questions: What did you do yesterday? What are you going to do today? Do you have any impediments?

Now I would again point that this is how it is done in SCRUM. But as an agile project manager you don’t have to do it exactly this way. Remember – we want to achieve is the benefits – short, to the point meetings, discover trouble spots early, and inform each other about progress. Let me elaborate by answering the most common questions in this regard;

No, you dont HAVE to do these meetings every day. In your project you could have a lower frequency on the these meetings. The consequences are of course that you get longer feedback loops, but maybe that is ok? And then, sometimes you probably should have daily meetings, if you are in a very critical stage in your project, or if the consequences of not discovering trouble spots are very big. The point is – adjust so it fits your project. After all, you can always revisit the decision as your project progresses.
No, the meeting does not always have to be 15 minutes. It can be 30 minutes…or 1 hour…but remember what you are trying to achieve…short , to the point meetings! If you have a huge team, then it might make sense to have a longer meeting. But then you might also want go consider splitting into smaller teams. As a rule of thumb – status meetings should not be long meetings. Consider this, and make adjustments based upon what makes sense in your project.
Why informing – and not reporting? In SCRUM this rule supports the idea of a self-organized empowered team. In your project, you might not need to have the same focus on this, just because your goal is not necessarily to have a self-organized, empowered team. But take into consideration the benefits of what a “informing-not reporting” environment creates; your team members might be more honest and not afraid to speak their mind about the status and their concerns. If your goal is to discover trouble spots early, it just might be a really good idea to bring this mindset forth in your project.
Do we need to ask those 3 questions? No, not at all…it is just a very efficient way of keeping the meeting short and to the point. In combination with a maximum length of the meeting, this enforced everyone to spend their given time wisely. I would recommend that you build your meetings around a specific set of simple questions.  But consider not having to many questions, and make sure that the questions asked actually supports what you are trying to achieve.

2. Retrospective

In SCRUM, retrospective meetings are  held at the end of every sprint (iteration). The purpose of the retrospective meetings are to gather the teams opinions and experiences about what went well in the sprint, and what could be improved. By reflecting together, they identify areas where they can adjust to improve their efficiency in the next sprint.
In my opinion, retrospective meetings are one of the most powerful activities in SCRUM. And in my opinion – you are not doing agile project management if you do not do retrospectives.
Retrospectives is all about using the knowledge gained to make adjustments to improve our way of working.
Consider who should be part of your reflection meetings. It might be wise to include different roles and people to capture different perspectives. Maybe you have a large team, so it might not be efficient to include everybody? Or different time zones makes it hard to include young Mark sitting down in Australia? These are decisions might you have to make, but always consider the consequences of excluding someone from these meetings. It might be interpreted wrong and feelings could get hurt.
Consider how to facilitate your retrospective meeting. Doing Retrospectives might spawn off difference of opinions and even scenarios where the blame-game is played out. While dedicated and passionate people in your team is obviously a good thing, you should prepare and facilitate the meeting by agreeing on a set of ground rules to establish a common behavior of respect and professionalism.
You can`t fix everything at once. By the end of your reflection meeting you often end up with a long list a lot of good suggestions. Instead of just having a long list of improvements, pick a few and commit to them! If you want to prioritize yourself or get input from your team, is really up to you.  If you want to use the team to help prioritize what improvements to commit to, set aside some time at the end of your reflection meeting to get their input. Exercises like dot voting is a fast and easy way to get this done.

3. Estimate & Prioritize

Estimation and prioritization is something that every Project Manager knows about. But while these are familiar terms in traditional project management, why not consider doing estimating and prioritizing the agile way? This means embracing the fact that your initial estimates are pretty much going to be inaccurate, and applying the Pareto principle byspending 20% of the time, and get the estimates 80% right. However, don`t forget that this approach assumes that you revisit your estimates as your project progresses, and re-estimate on a regular basis based upon your new knowledge.
Prioritization in a project are usually based upon one or any combination of customer needs, a set schedule, and of course, your estimates. In the agile world, prioritization is often based upon business value and a principle of delivering business value as soon as possible to the customer. For a Project Manager, this is in fact an excellent way of getting your prioritize right. And in combination with your estimates, you can quickly identify low hanging fruits – meaning important functions that requires low effort. I mention this as an example, because a really (really!) good Project Manager might want to use these identified low hanging fruits and plan strategically  when to deliver them to keep the customer happy.

4. Teamwork

So, you have a project team. But how can you maximize the efficiency and collaboration within your team? Why not use some of the key leanings from agile team work? I would recommend that as the Project Manager, you start your project by defining a set of team ground rules together with your team. This might also be an excellent opportunity to get superficial understanding of the personality types of your team members (introverts and extroverts). Such observations can be key in order to understand and facilitate how to get the most out of your project team by building a sense of trust and commitment.
Remember the retrospective meetings? Use them to capture inputs on how to improve the teamwork.

5. Iterations

Your project is like running a marathon, and Project Managers use milestones while planning deliveries. In SCRUM – work is done in iterations. And the Product Owner uses the team velocity to do their release planning. At first sight – these seems to be very similar approaches.But there are a few major differences to be aware of.

In SCRUM, an iteration lasts between 2-4 weeks. A milestone in a traditional project might be considerably longer. The benefits of short iterations in SCRUM is that you have to break down your work into smaller pieces to be able to complete them within the short iteration. This creates a much shorter feedback loop – identifying impediments, wrong estimates, dependencies etc. This again enables you to discover trouble spots early, and make the necessary adjustments much earlier.
Short iterations also enables you to deliver small, but fast and frequent deliveries to your customer. Now,some might argue that in many projects we don`t want to deliver often and small. I can understand this argument.But even if we do not want to deliver often, having short iterations still gives us the possibility to both do testing and also get customer feedback by setting up test environments where the partly finished features are made available. Please do not underestimate the vast improvement this can have on the quality of your project delivery.