Skip Ribbon Commands
Skip to main content
  • Apex |
    • Blog-PM_Moving_to_Agile
Visit the main blog page.

Follow us on our social media channels, where we share lots of great content and events!

Twitter Facebook LinkedIn Instagram

The Project Manager Moving to Agile

July 2018- Ryland Leyton, CBAP, PMP, CSM, Business Analyst, Author, Speaker, Educator, Agile Coach, and Technology Translator


These days many project managers are interested in - and frequently being actively asked or told - to move to agile environments.

The difficult thing about this is that the Project Manager (PM) just doesn’t have a clean parallel in small agile teams. I’m sorry. For the sake of simplicity, I wish it did. It doesn’t.

The good news is that the PM skill set and competencies are very useful in agile environments. If you’re interested in making the focus, skill and mindset changes that I think are necessary, you’re going to do just fine.

The bad news, if there is any, is that your profession has some unlearning to do. The mindset implicit in the PMBOK is frequently the opposite of an agile mindset. If you have a nimble and adaptable style of work I think you’ll find this fun and interesting, like learning to ride a bicycle all over again. It’ll take a while to learn, and then you can really do some cool things!

If you’re ironbound about your PM practice and the way you do your work, you may be in for trouble.

In this article, I’m striving to help you understand the differences in the new work you may be getting into. I’m not going to go into the granular details of the job. There are many other places you can get that information.

I want to help you figure out if you’re interested in doing it, or not.

The most common role you’ll see that maps to the PM job is the Scrum Master (SM).

We will discuss the Scrum Master in this article as it’s pretty common in the marketplace. There are other positions; you may want to look up the Release Train Engineer, from the Scaled Agile Framework for the Enterprise, as another and very different example. However, those jobs aren’t as common to find.

SM jobs are frequent at this time. People who do can do this job well are in demand.

That said, let’s get into the differences that are relevant for you as a player in the job market.

Classic, typical, non-agile project management.

Let’s start here. In the stereotypical PM space for a project of any duration longer than 6 months, you are ensuring that the following things get done, not necessarily in this order.

  1. Goals and outcomes identified, project charter or scope document created.
  2. Tasks and work breakdown structure identified.
  3. Sequencing and critical path analyzed.
  4. Resources (people, time, skills, money) identified & secured.
  5. Gantt chart constructed and dependencies tied down.
  6. Timeline and budget established and baselined
  7. Risks and issues identified.
  8. Project launched.
  9. Project controls, communications plan, metrics identified and launched.
  10. Stakeholder management plan created & launched.
  11. Change management process created & launched.

I acknowledge I’m leaving out the people side…because that’s a management skill, not a project management skill. That’s going to be important in a minute.

In summary, your stereotypical project manager is supposed to get several things done, typically through other people. The PM is responsible for bringing the project and its deliverables in on time, on budget, and on scope.

What about agile?

In Scrum, the closest thing to this role – and it really isn’t that close – is the Scrum Master (SM).

As I’ve been hinting at so far, depending on the kind of project manager you are, what kind of people manager you are, and what your professional likes, dislikes, and passions are, you may be an excellent or a terrible Scrum Master. This simply is not a 1:1 parallel.

Core responsibilities of the scrum master are these. Again, this is from my point of view. I’d encourage you to find some other sources as well.

  1. Protect the team from outside interruptions and wasted time.
  2. Maintain a focus on agile mindset and practices, emphasizing team self-management.
  3. Organize and facilitate the agile rituals and activities of the team.
  4. Coach others to success, help them bring out their best.

That’s it. Through the lens of these priorities the SM decides how to best spend their time.

Notice what isn’t there: directing activity, assigning tasks, assigning deadlines, and singularly owning success. Agile is a team sport, and it is a best practice that the SM is a peer-coach, not in charge of the team.

The SM may help the team (developers, product owners, BA’s if present) think through risks, sequencing, issues, and so on…but they do not own the action of doing so. If it seems right, they may (for example) create a risk or issue log and communicate about it with interested others…in order to protect the team from outside interruptions. They will also stop such a log when its no longer needed.

The SM actively strives to eliminate meetings and preserve the time of the dev team towards the thing that only the dev team can do: produce working software. Working software is the point of the effort and is how we show progress.

Are you beginning to see the difference?

Supporting and growing others, enabling others to act, encouraging them, staying out of unnecessary details…the SM is all about servant leadership. Serving the team and coaching them to solve problems, use their skills, be creative, collaborate actively, surface information for the benefit of the team, this is the spirit of the SM job.

The focus is not on the tasks the people do. In agile we value individuals and interactions over processes and tools; the SM focuses on the people and how to help them do their best work, not how to work the best process.

You can use most of your PM skill set in doing this. You’ll add agile-specific skills and knowledge. You will have to foster and grow an agile mindset.

You won’t throw out anything that you know. The focus just changes a lot.

Does that sound interesting?

If your work passions are more strictly around managing and directing tasks, status reporting, and the mechanics and tools of running a project, and the people focus is of some disinterest to you…this may not be your cup of tea.

On the other hand, if servant leadership, developing the agile skills & mindset of yourself and others sounds challenging and exciting, I’m very happy for you, and this could be a great fit for you!

I have found that agile environments offer tremendous job satisfaction and the ability to do great and fulfilling work, with a strong emphasis both on learning from & contributing to other people. It’s a more active, participatory team activity than typical waterfall development. It is a fast paced, contact sport!

My best wishes on your agile journey!

Use the links below to connect with Apex:
> Join our Talent Network
> Search for a job
> Connect with your local branch