CASE STUDY OVERVIEW

While I worked with the team on several aspects of delivery and performance, I can not stress enough how fostering a strong team dynamic was the true impetus/catalyst for the change I saw with this team.  the challenges of evaluating success, and results of a retrospective approach used to map and define the techniques and strategies I used to achieve it. This case study also includes the ultimate impact I had on the team -- creating a measurably stronger team dynamic.

I worked with this team of engineers over the course of two years and led a successful transformation which is still in place today. Not only is the team still operating at an optimal performance level, they are now seen as a gold standard for other teams at the company. This team is even being tapped to consult with other teams to improve performance for the company. 

Important to note…

This team was already practicing Agile, but there was a concern among leadership that this particular team was underperforming and was not operating at their true potential given the talent on the team. 

Our goal wasn’t to recreate Agile or its processes, but rather to outline what we could do differently to unlock that potential, and to identify the elements that had been missing in their past experiences with other scrum masters and Agile coaches.

Meet the team where they are

Instead of where you think they should be

Observe.

Instead of coming onto my team assuming they needed to work on things like velocity, capacity, planning, etc., I observed for two weeks to understand their current process. After two weeks, I had an understanding of what was working well for the team, and what the team could improve on.

Work with the team to develop an improvement roadmap.

After two weeks, it was clear what the team could work on immediately and what improvement items could wait until the next sprint or even the next PI. It was helpful for the team to know what that plan looked like. We both had an understanding of what to focus on now and what we would focus on later.

Create an environment of trust, respect & open communication before you expect any successful changes in any team process.

New/added team members can be disruptive to any team dynamic, especially if that new team member is a scrum master. As a scrum master I held the team accountable to process, but it was the team that was responsible for understanding what process was right for them; therefore the team was part of any conversations we had around process change or implementation. 

Here is how I created an environment of trust, respect and open communication:

By asking questions about the current process, I encouraged the team to be curious about the current process in place. We would tackle their questions in a retro, or as they came up when time allowed. 

• How do we feel about the process?
• Does this process still make sense for this team?
• Is there a way we can refine this process to make it even more effective for our team?
• Is there any process that no longer serves us?
• Are there any processes that we feel hold us back from being the best we can be?
• When making a new process, do we feel like the effort is worth the reward?
• Do our processes serve or hurt our team's progress?

An important step we took when trying a new process was to try the new process for 1-2 sprints so the team wouldn't feel like they were locked into a new process that they weren't sure would work for them just yet.

Create a space where team members are comfortable being vulnerable.

Vulnerability is central to creating an environment of trust, respect, and open communication.  Here are a few ways I was able to foster vulnerability in teams.

Openly admitting when I made a mistake.

I showed the team that they were encouraged to admit when we had made a mistake to illustrate that mistakes are opportunities for learning.

Be curious about mistakes that have been made.

By accepting that we all make mistakes, we were able to talk about them so we could learn to avoid them in the future (instead of scolding, blaming or shaming the person who made the mistake).

By helping team members feel safe when asking questions, and responding to questions with phrases such as "that's a great question" or "glad you asked" instead of allowing condescending language such as "Oh, you didn't know that?" or "I'm surprised you didn't know."

Encouraging the team to be curious.

I reminded the team members that oftentimes a question they might have is a question another team member might also have (but may be too afraid to speak up).

By focusing on moving forward when mistakes, delays or issues arose made the team solution-oriented rather than focusing on what went wrong.

I looked at the ways we could measure our improvement and I worked with the team to create a list of items we could use to test further improvements or to use as a benchmark to track our progress over time.

Fewer hours spent by developers in unnecessary meetings

I joined every external team meeting we had on our calendars. I told the team to forward me every non-Agile ceremony meeting so I could coordinate with the organizer on what was needed from my team. If it was not absolutely necessary for a developer to be in the meeting, I would attend on their behalf. If a question came up during the meeting that I could not answer, I was able to message my team for an answer. This decreased the team's time-spent-in-meetings drastically.

I also blocked the team's calendar every Wednesday and Thursday afternoon with a "protected developer session" so the team would not get invites to meetings unless it was critical.

Blockers/impediments removed faster– 

If my team was blocked by another team, I was able to get the meeting or response we needed from that team in an impressive amount of time.

Massive increase in productivity

We tripled our throughput (delivery of key features).

Decrease in time-to-market and response times to production support

My team had 30% more capacity due to the elimination of wasteful activities.

Ability to move faster

By improving planning meetings we had an understanding of what we were currently working on, and what could be pulled next because we had a prioritized backlog for the entire PI with the whole team understanding the work that was needed to meet our goals. This resulted in shortened meetings, impediments removed faster, and faster decision-making.

Documentation improvement

I scheduled dedicated time for the team to discuss how we could improve documentation for both internal needs and external communication. This not only improved our onboarding process, but also decreased the amount of time spent on calls and writing emails to external teams regarding our architecture.

Ability to innovate on architecture

I worked closely with the tech lead to document and plan for innovating our architecture. The tech lead later expressed that there was no way we could have finished our architectural overhaul this year without my partnership and our planning and coordination efforts. 

Team is now cross-functional

I had worked with the team to dedicate time to KT and collaboration sessions to spread knowledge across the team, and to dissolving blocks by team members who held a specific expertise or knowledge.

Faster resolution of dependencies

I created better relationships with external teams which meant we were able to mitigate blocks faster.

In addition to mapping my team's improvements, I realized that it was necessary to map my own.

As I thought about my own role as a Scrum Master for this team, I took into account four areas I could look at to gauge personal improvement. In terms or measurements, these four areas fell into two important categories:

Left side = Qualitative, unobservable

Right ride = Quantitative, observable

Here are some examples of how I improved in each during my time with my teams:

Final thoughts.... 

I recently had a conversation with a group of people about the concept of “bringing your whole self to work.” It turned into a debate about what the concept actually means, and about the fine line between what could be considered professional vs unprofessional workplace behavior. As I reflected on my time at this company and with my team, I realized that there was a larger point that made this debate academic.

If we focused on creating environments where people felt safe, supported, trusted and empowered, we wouldn't need to have a conversation about bringing our "whole self" to work, because not only we would already be doing it, we would all be doing it. 

This culture is exactly what we had on this team, and it's not just because I was their Scrum Master or because the team members are brilliant (and they absolutely are), it is because we had created a dynamic within our team that was built on trust, partnership, communication, transparency, compassion and openness.

We laughed, joked with each other, and talked about topics ranging from home improvement projects to the great unknowns of the universe. We talked about our families and friends, stories from childhood, stories from the past weekend and plans we had that we were looking forward to. We brought our whole selves to work, and it has forever changed the way I think about work and what I now know is possible to have on a team, including the friendships that came with that experience. Because there was such a high level of respect and appreciation from every team member, because there was such a strong degree of connection and understanding between each of them, the classical idea of what professional behavior was began to appear ineffective, outdated, and undesirable.

In a recent 1-1 with the team tech lead, we revisited the question: “What IS IT about this team that makes us so darn good?,” and again, we circled back to words like trust, partnership, communication, and laughter. It got me thinking about how other teams interacted with us, and how so many people would tell us "this was the best call I have ever been on." or "wow this call made my week." It made me realize that, if a team feels safe, trusted, supported, and empowered, they will treat other teams with the same level of kindness, respect and communication that they themselves show to the individuals on their own team.

Imagine where we could be as a company (and beyond) if more teams were like this team. Think of how different our workplace–and our lives-- could be. Because even if you don't bring your whole self to work today, you bring home to your family and friends how work made you feel. And if you are feeling scared, worried, or anxious at work, then that is the workself that you're bringing home. 

I hope whoever reads this feels empowered to be a change agent at their company, and in this world, so that more people can bring their whole self to work, and feel the way I got to feel working with this team -- so they too can go home and be not just better coworkers, but better people for everyone they come in contact with.  

There are few small changes you could make that would be more powerful than that.

 With love, and gratitude,

Alanna Finn, Friend & Former Scrum Master and Team Member