These days many project managers are interested in – and frequently being actively asked – 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. 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 find success. The bad news, if there is any, is that in order to shift to an agile project management structure, 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 the change fun and interesting, like learning to ride a bicycle all over again. It’ll take a while to learn, and then you’ll be able to ride smoothly, enjoying the ride.
However, if you’re iron-bound about your PM practice and the way you do your work, you may experience more challenges with a shift to agile. In this article, I’m striving to help you understand the differences in the new work you may be getting into. I want to help you figure out if you’re interested in doing it, or not.
Scrum Masters
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 to review such as the Release Train Engineer, from the Scaled Agile Framework for the Enterprise. However, those jobs aren’t as common to find. SM jobs are more readily available at this time. People who 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.
- Goals and outcomes identified, project charter or scope document created
- Tasks and work breakdown structure identified
- Sequencing and critical path analyzed
- Resources (people, time, skills, money) identified & secured
- Gantt chart constructed and dependencies tied down
- Timeline and budget established and baselined
- Risks and issues identified
- Project launched
- Project controls, communications plan, metrics identified and launched
- Stakeholder management plan created & launched
- Change management process created & launched
For the start of this example, I acknowledge that I am not focusing on the people side because that’s a management skill, not a project management skill. 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 have, you may or may not be aligned for success as a Scrum Master. The comparison between project management and a role as a SM simply is not a 1:1 parallel.
Core responsibilities of the scrum master are:
- Protect the team from outside interruptions and lost productivity
- Maintain a focus on agile mindset and practices, emphasizing team self-management
- Organize and facilitate the agile rituals and activities of the team
- Coach others to success, help them bring out their best
Through the lens of these priorities, the SM decides how to best spend their time. Be sure to take notice of what is not listed–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, and issues, 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 parties in order to protect the team from outside interruptions. They will also stop such a log when it is 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 is what makes the SM role 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 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 and will have to foster and grow an agile mindset. You won’t disregard your current skill-set, just adjust the focus.
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, agile methodology 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, agile methodology is an area where you may find success and happiness.
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.
At New Signature, we work to create agile solutions internally and for our customers. If you’re interested in learning more about New Signature and becoming part of our team, you can review our current career openings or watch what we are all about below:
About the Author
Ryland Leyton is a Senior Business Analyst with New Signature and is based in Atlanta, GA. Ryland loves getting to help clients solve business issues through creative & valuable use of technology solutions. Working in tech since 1998, he has moved through different roles starting with database & web development, and gradually moving through project management and into business analysis. He has a strong love of agile practices and works to help people benefit from agile wherever it makes sense to do so. Ryland is a frequent educator and speaker on BA, PM, and Agile topics. His books include “The Agile Business Analyst: Moving from Waterfall to Agile”, as well as being a Core Team Author of Version 2 of the IIBA BABOK Agile Extension. Ryland often gets involved in career & workplace conversations (as you’ll see on our blog ), and his recent 2019 book “It’s About Your Career: Skills for a lifetime of loving your work!” has become a conversation starter in professional groups.
