Blog

Bridge the Gap Between Project Manager and Scrum Master

Dorthea Alsberg

As scrum master, you help find common ground between product owners and development teams. Learn how you can leverage skills rooted in traditional project management while you blaze a new trail into agile scrum territory.

Change is your friend.

Especially in IT.

In a world where new technology emerges every day, our focus on delivery must also change and adapt to keep up with the pace of demand. Today, business is moving at the speed of IT and IT is moving at the speed of business.

Traditional waterfall project management called for a pre-defined process with specific milestones driven to completion along a clear critical path. Teams often struggled back and forth to resolve dependencies, to answer design questions, to discuss scope, and to work through timeline issues before the team finally was able to race past the project finish line.

This is a proven approach… of the past.

Today’s cloud and software-defined solutions offer limitless possibilities. When delivering these transformational solutions and enhancements, you need to constantly integrate with several different areas of the business and IT units to be effective. The traditional project manager role did not embrace this fluidity. More and more of us (consultants, colleagues, providers, and clients) are jumping onto the agile bandwagon.

What is Agile?

Not just a hot buzzword, agile refers to a project delivery methodology that is equipped for the cloud revolution. Agile breaks down the overarching deliverables and goals of a project into incremental chunks, called sprints, that can be specialized and modified as little or as much as needed by the technical and business teams. Within agile, there is a specific approach called scrum for software development initiatives. The two have similar frameworks, but scrum takes it one step further by suggesting best practices for agile scrum teams, defining the specific roles of each team member, and necessitating standard terminology.

The three major roles within agile scrum are:

  • Product Owner: The product owner is the sole person responsible for managing the product backlog, or task list, for each sprint. The product owner is responsible for maximizing the value of the product and the work of the development team.
  • Scrum Master: The scrum master is a servant-leader for the team and product owner. The scrum master is responsible for helping the team follow the specific agile theories, practices, and rules that benefit the business. The scrum master helps the product owner and team deliver success to the customer. Scrum masters also facilitate agile events and ceremonies that help everyone understand which of their interactions with the scrum team are helpful and which aren’t.
  • Development Team: The development team consists of professionals who do the work of delivering a potentially releasable increment of product at the end of each sprint. Teams are structured and empowered by the organization to self-organize and manage their own work.

Adapting to Change Yields Success

In agile scrum, team effort is channeled into product releases which are further divided into short-term sprints designed to accelerate the feedback loop and readjust effort. There are daily or semi-weekly scrum team calls, typically limited to 15 minutes to communicate progress, collaborate, prioritize tasks, and identify impediments. Non-remote teams refer to these meetings as a daily standup, where they will literally stand together in a circle and provide their status updates one-by-one in sequential order.

Many of the responsibilities I have held as a project manager are off-loaded onto the product owner or development team where everyone is equally accountable for project success. For example, since they can leverage their wealth of knowledge on both business drivers and IT capabilities, prioritizing project tasks is the responsibility of the product owner. As a scrum master, I am still facilitating and monitoring progress, but I am allowing the subject matter experts to call the shots so we can focus on the best solution.

In a similar way, the development team is empowered to manage sprints and tasks. While the product owner evaluates what feature or product is most important, it is the development team members who are completing the work and determining what is feasible within a sprint, and how many sprints are expected. The development team is also responsible for communicating what is needed, what roadblocks they are hitting, and even what other relevant features are possible given the latest information from the client. As the scrum master, it is your responsibility to ensure this communication happens and is exhaustive of all vantage points.

The Scrum Master Role

In my role as scrum master, when a sprint is complete, I schedule a sprint retrospective. In this popular agile scrum ceremony or event, I gather the team to collect their feedback. Retrospectives foster transparency within the scrum team and improve interactions, use of tools, procedures, and other workflow conditions before the next sprint. By contrast, a traditional PM following a waterfall process would need to focus on legacy deadlines set at the start of the project. They would conduct a post mortem review with the team and other managers, but it would take place after the project had already been completed, leaving no time to course-correct while in flight.

One of the tenets of agile emphasizes working software over comprehensive documentation. Rather than defining all the requirements up front, agile embraces the unknown changes ahead. However, you might be thinking, “How can you start a project without a plan?”

The simple answer is sprints (and the work packages, user stories, product features, and tasks that are assigned to each sprint) are determined once sufficient environment information and business demands are collected. Compiling sprint plans at the start of a project and readjusting before each sprint forces candid communication and involvement from the entire project team at large.

A scrum master supports the sprint plan and the team in whatever way they deem necessary, and will do everything in their power to resolve any impediments to progress the team may face. As a scrum master, I find myself coaching and cheering the team along. I’ll often provide my unique opinion to mimic someone on the outside looking in. The team welcomes this feedback because it improves the solution.

In the past, when delivering a traditional waterfall project, getting the precise status of each black and white step listed in the project plan was more important than ensuring feedback was flowing and the product was fully inclusive. The work at hand was different (dare I say, more straightforward) than the work we are facing today. Nothing could interfere with the project plans of the past because it was constrained by the waterfall process.

Final Thoughts

Despite what you have read thus far, it is necessary to switch gears and defend some legacy best practices of traditional waterfall project management. As we all adapt to change, there is most certainly a middle ground between the traditional project manager and today’s scrum master. This is often where I stand.

For example, when kicking off a new agile effort, I will caution the team estimates can always change, but I do provide a high-level sprint plan with estimated levels of effort from the scope of work and preliminary conversations. This up-front planning helps to ease the discomfort typically felt at the start of a new project. It also serves as an aligned springboard for all teams to start filling in gaps and adding new related work together.

Daily standup calls are most effective when they are truly 15 minutes. If you’ve ever been on one of these calls, you know it is a struggle to keep them from turning into overly-detailed status calls or working sessions. The key is knowing when it is necessary to deviate from your established scrum process. There are cases when certain tangents are acceptable because they could ultimately lead to progressive steps forward or a better solution. Some traditional project management elements can be leveraged including risk registers and dependencies since they are still applicable and necessary in most situations.

No matter which agile practices, ceremonies, or artifacts you recognize (even ones rooted in traditional project management), be sure to involve everyone in the agile process. You want your teams to be empowered to voice, identify, create, and maintain work items so they can share in being accountable for them as individuals and as a unified team. They need to be aware of the impact of changes on all work tasks. And as scrum master, you enjoy the important duty of building that atmosphere of involvement, engagement, and awareness.

Never stop adapting to the needs of business and the speed of IT. That’s what agile is all about—embracing change.

And remember, change is your friend.

To learn more about Agile Software Development including the methods and practices based on the values and principles expressed in the original Agile Manifesto, see www.agilealliance.org.

To learn more about scrum team roles, see The Scrum Guide available at: https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide.

Dorthea Alsberg

Dorthea Alsberg, Engagement Manager, CDI

Dorthea Alsberg currently serves as an engagement manager at Computer Design & Integration LLC, where she is responsible for leading critically important consulting initiatives with clients across various industries in dynamic team environments. She works directly with CDI’s Advances Services Group to deliver cutting-edge, software defined transformative solutions. Dorthea is a Certified Agile Scrum Master, and holds industry certifications from VCE and AWS. She holds a Masters in Marketing and Integrated Communications from Marist College, and a dual BS/BA in Marketing, Economics and Finance from the University of Hartford. Dorthea is a national volunteer for Delta Zeta sorority, where she travels and serves as a membership recruitment and retention specialist.