Summary:  My name is Brutus Segun and I am a Project & Program Management Consultant at Tuck. I’ve been working as an Agile project manager since 2016, mostly in software development and IT. My clients come from both the public and private sectors, and I am particularly proud of my work with the Kansas Department for Aging and Disability services, where I was able to impact ~25K users statewide as a Director of Policy and Program Oversight. In that role, I guided policy, procurement, and contract administration activities as well as championing several multi-million dollar projects. I am also a US Army veteran. I wrote this blog entry for PMs who are early in their journey as Agile practitioners.

Agile Expectations vs Reality

As a new scrum master, you should be familiar with distinctions between “traditional” (Waterfall) and Agile approaches to project management. Waterfall follows a linear approach with less consideration for flexibility and change. Each phase (initiation, planning, design, build, test, implementation, transition, and closure) must be planned and broken down in a schedule, tracked, and regularly assessed for risks and issues.  Waterfall PMs handle these tasks while managing stakeholders — balancing the interests of the highly influential ones against valid concerns of the less influential. Going back to your new title of ‘scrum master,’ you must take the journey towards developing an Agile mindset and and embrace all the ceremonies for the scrum framework. However, all of the seminars and trainings that I attended as a new scrum master missed one key element: a realistic perspective of what to expect in the scrum master role.

What’s missing from most Agile curriculum?

Consider the role of scrum master as if you were appointed a team coach of your favorite sports team. Mine is soccer, or football, as known outside of the United States. While there are many specific rules to the game, there are only two basic rules most players need to know:

• you must move the ball around with your feet
• only the goalie can touch or carry the ball within 18 yards of the goalpost

Scrum guides often read similarly. They define some essential ceremonies that a scrum team must hold and describe the responsibilities of the scrum master leading them. But as in soccer, simply learning the rules rarely results in a single victory, let alone tournaments or championships. Successful players have to develop the skills required to optimize the basics to get the best out of them. How you apply Agile principles determines whether or not you can bring wins to your team. And just as in football, the different opponents (i.e., challenges) you face will require different tactics. As the head coach of your scrum team, you should always be ready to pivot (within the Agile framework) to overcome each one.

Here are some tips that should be included in Scrum Master & Agile Trainings:

1. Serve the people, not the process

My first tip is to keep a very open mind and continue looking for opportunities to improve your approach. The scrum guide provides you with the fundamentals, but when you’re leading your first Agile team, you’ll discover just how complex and nuanced your teammates, the business challenge, and your executive sponsorship are.  Moreover, they’ll keep evolving over the course of an engagement. That means you must adjust your tactics from time to time, without deviating from the spirit and intent of the scrum guide. Whether you’re stuck with a mature team of technical wizards, or with new graduates fresh out a coding bootcamp, your job as scrum master is to remove blockers or impediments for each individual on the team and them overcome challenges as a single unit.

2. Embrace the ‘Inspect and Adapt’ Loop

As an Agile professional with many years of project management experience, I’ve watched many a sprint planning session turn into an extended discussion about specific backlog items or cards. It’s easy to forget that the product owner is responsible for prioritizing backlog items. The planning session ceremony itself is a negotiation about how the backlog items extracted into the sprint can help deliver the next iteration as captured in the sprint goals. With this in mind, focus on defining and understanding the goal, so that you can help your teammates understand and buy into it. Some tips to help shape the conversation include:

• Align the backlog with the product owner, business analyst (BA), and tech lead
• Align with your tech lead on some sprint goal candidates (helpful so you don’t have to come up with a goal in the planning session)
• Set a draft agenda and circulate it with your tech lead and facilitate the session according to the agenda

Follow these tips and boom, you’ll have a successful session. Just remember to share the aligned sprint goal with everyone.

3. Use data to measure progress, and don’t over-promise

As a Scrum Leader, you’re going to get a lot requests for forecasting and predicting work completion. Customers always ask the business side of the team “When will this or that feature be done?” and inevitably you’re asked to predict the future. The sponsors generally want an exact date, and they want it to come with a high degree of confidence. Once in a while, you’ll have a relatively straightforward project that permits you to forecast feature set completion based on past work completion (if you have completed some sprints with the same team already). But even then, you risk overpromising and underdelivering due to some significant shortfalls of Scrum’s estimation method (to be discussed in a future post).

As a refresher, Scrum uses a story point system based on the Fibonacci scale to estimate the effort required to complete backlog items. But some customers think this method provides 100% certainty instead of a probabilistic estimation, which it can be under ideal conditions. As a scrum master, one way to navigate the challenge of making commitments that are helpful, realistic, and acheivable is using the story point estimation method.  This method incorporates adjustments for the risks that come up during a backlog items estimation session with your team. I can do this by:

• Adjusting each user story for risks by conducting a quick risk assessment on it, looking at the probability of an issue materializing and the impact of the issue on the story. This typically allows the team to factor in the risk when estimating. This might lead to an upward estimation of a user story but invariably allows room for risk response in the event of change.
• Adjusting at the feature set or epic level with risk-based cards that are risks that could impact the feature, and sometimes these may be in the form of spikes or discovery cards. When estimated as part of the feature set, these risk adjustments account for a more robust sprint that can provide a better high-level estimate of delivery.

In a future post, I’ll dive deeper into more valuable tips and tricks for new scrum masters. Scrum is one of the most popular Agile frameworks, and project managers should take the time to understand it. When you serve in that role, focus on collaboration and teamwork, deliver value, grow the team, and build and sustain strong comradery relationships between individuals working on a project.

Sign Up For Our Newsletter