Mindset Shift for True Agile Transformation
A case study on an approach for shifting mindset and perspectives for sustainable change
A Fortune 100 Financial Banking Services Company
In order to turn my very successful team transformation into a repeatable and teachable learning experience, I mapped out a method using a retrospective approach, and this roadmap was the result. This case study illustrates the approach I used to attain my goal of implementing an impactful and sustainable change for a team that went from base-line performance to outpacing every other team at the company.
I was assigned a team to help improve predictability, output, and quality. Once I began working with the team, I realized many of their blockers came from their struggle with product alignment and miscommunication around prioritization.
I used a collaborative leadership approach to work with the team to analyze, update and refine the processes they had in place to ensure the processes they were implementing served them as a team and the work they do. I also partnered with the team to improve the relationship with product in an effort to open the lines of communication between our team and stakeholders to bring a greater level of transparency and accountability to our processes and overall team culture.
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.
My 5 Pillar Approach for Sustainable and Impactful Team Transformation
- The mindset that Agile is not one-size-fits-all
- Acknowledge that vulnerability is a key ingredient in creating a healthy team culture
- Value over metrics: Emphasis on what actually delivers value instead of a narrow focus on process and metrics
- Measuring success: Upon reflection of the approach, measuring the success of the new team dynamic to understand the impact of the approach
- The value of self-improvement: Surprising realization that the team’s growth also depends upon my own growth as a coach
Meet the team where they are
Instead of where you think they should be
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.
What made our scrum master + team dynamic different from others at the same company?
I spoke with the team tech lead to try to understand why our team was different from so many others at the company. Together we came up with the list of items below that explained why our team had become so successful:
- Partnership vs. report driven relationship
- Open to trial + error
- Trust needs to go both ways, between the team and the scrum master
- Deep expertise relating to Agile practices and methods to understand the many different ways you can implement process and use the tools available
- Passion-driven supports a growth mindset when you are passionate about the team and the work
- Ownership + Servant leadership
- Creative ways to free-up capacity or protect engineer time
- Long-term improvement goals + vision
- Scrum meetings became more meaningful, impactful and productive
- Translator for team between other teams, mitigating confusion and delays
- Value & emphasis of work/life balance + self-improvement
- Focus of knowledge transfers, challenging team members to take on challenging work
- Gave team freedom to explore other ways to improve
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.
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:
- Values & Goals
- Reflected on the things I could do to help the team that they weren’t actively asking for; for example, I blocked out portions of the calendar to dedicate protected development time in the afternoons.
- I made time to continue learning how to be a better Scrum Master by taking classes and reading up on how to improve team dynamics.
- Product & Impact
- We thought of ways we could improve on what we were currently doing, challenging processes that might already be in place that might not be serving the team. For example: we tested a rule of no meetings on Fridays.
- Leadership & Culture
- Started retros with meaningful icebreakers to get the team in the right mindset to be vulnerable; for example, I have started with "what is something you're working on this month or this year outside of work that you're proud of?"
- To improve team communication and culture, I started a team building ritual - our example: we started a virtual Friday happy hour.
- Markets & Environment
- I looked into how my team connected with other teams so I could understand the ecosystem we existed in in order to become a better part of the whole. For example, I worked with other scrum masters when we needed to collaborate with other teams to better understand the needs of both my team and the other team (more on this below).
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