So you’re a project manager. You've been a project manager for years. You have your PMP (maybe). You have a list of projects that you successfully “managed” to completion on-time, under budget and at required scope level. You’ve probably also encountered projects with problems—problems you as the project manager were ultimately responsible to resolve because you were the project manager. YOU were the accountable person on the project.
Now your company has decided to adopt agile. In agile software development, the “team” is responsible for success or failure; NOT the project manager. Really? In fact, agile doesn’t really even define a role for a project manager. So where does that leave you?
First thing’s first—don’t worry. In most companies, project managers do not go away. They assume the agile role of “scrum master” or sometimes “product owner”. Related to the agile process, a project manager can also become an agile practitioner and be a coach to help others working in the process. Oh, and by the way, while the “team” is responsible for success or failure, the project manager will still certainly be the person who management goes to if things aren’t going well.
So now what? What do you do? How do you act? A pretty common defining phrase for agile project managers is “servant leaders”. Personally, I fulfill this role by dressing like a butler and delivering coffee and snacks to the team with a white cloth draped over my arm. Okay, just kidding. (I did actually get a team member a cup of coffee the other day, but I would have probably done that anyway…)
The real difference between a traditional project manager (traditional leader) and an agile project manager (servant leader) is mindset and focus. Let’s start by talking about mindset.
Leading via Command and Control vs. Leading via Empowerment
On a traditional team, the project manager will make the plan, then delegate activities of the plan to their team, who will do the work. In other words, the project manager is “directing” the team. The project manager reports status, good or bad, and ultimately owns the success or failure of the project. Decisions are made at the top and handed down to the team through the project manager, and those team members follow the direction of the project manager.
On an agile team, this structure is turned upside down. The team is presented a backlog of stories that make up the building blocks of the product. Problems, not solutions, are given to a team. The team will examine problems and decide how to best solve them. After all, the team members are the closest to the actual code, so they’re in the the best position to be able to craft the right solutions to problems. Instead of being directed by the project manager, the team is empowered by the project manager and self-directs their activities.
What Are the Most Important Things an Agile Project Manager Can Do?
There are many things an agile project manager can and should do, but I suggest there are two areas of focus that should come first:
- Remove any roadblocks that are preventing the team from moving forward.
- Be the team’s PR professional—report up, down and sideways.
Every day, team members report what they have accomplished in the last day, what their plans are for the upcoming day and what is blocking them. Also, teams that use some form of a kanban board will have visual indicators to show their “blocks”.
On a daily basis, an agile project manager, typically in the role of a scrum master, should focus on and very proactively remove these blockers. This will keep the team on track and ultimately set the team up for success. Simple, right? Well, of course some problems are complicated, and some may be out of your realm of influence. But that’s what makes your role exciting and challenging!
What about being the team’s “PR professional”? A common problem I’ve seen in agile projects is lots of people at standup meetings. Of course the team, scrum master and product owner must be there. The other people standing around will say they’re there because they want to know “the status” of everything.
The problem is that a stand-up meeting is not a status meeting. In fact, if it goes as it should, it will probably be hard for an onlooker to really get any more true stats than they can get from the kanban board alone. Typically, an overloaded stand-up meeting is caused by a lack in the information available to the people who want to know the status. Bingo! Another job for the agile project manager. Spend time and effort creating a dashboard of “information radiators” that will convey status to those above and to the side. I find these three artifacts to be the most typically useful throughout a project:
- Sprint burndown or burnup
- Burndown or burnup by feature
- A list of critical blockers that are out of or close to out of your influence.
At times, there may be other views necessary, and the best way to get the right information to the right people all of the time is certainly to gather their feedback.
Taking these two steps will clear the path to success for the team, enabling them to do great work and provide the most value to the customer.
Put Your Servant Leadership to Work
So there you have it. Adopting agile software development enables a project manager to achieve goals in a new and exciting manner. You’ll still use many of the skills you’ve practiced and learned to love over the years, just through a mindset that’s been somewhat turned on its side.
Now, please excuse me—this servant leader has to make a latte run. The team is feeling tired.
What else can you do to empower your teams—and your business?
At Summa, we use agile to iterate thoughtful, high-quality solutions fast. Our experienced agile coaches are ready to help your organization do the same. Learn more.
