An Agile Transformation In Progress, Part 2 of 2

Author's note: You are viewing part two of a two part post. See part one of "An Agile Transformation in Progress" here.

Once we aligned on Scrum, we really started honing the process side. The PMO provided training for anyone who wanted it around Scrum; what it was and how to do it right. We wanted to get everyone on the same page. We helped people get really good at it by providing one-on-one help for Scrum Masters and Product Owners and then as they got better, we made examples out of them and sent them out happy and successful.

We also started advocating for tools like Slack and Zoom, which allowed us to have more real-time collaboration, and helped Agile work better.

We migrated all of the projects into JIRA and started working to hone our skills on the tool. Soon, we had people coming to us for help with JIRA that had previously been using it. We became the experts. We encountered some pockets of resistance, but we pushed it through by continuing to provide more value and help for others. Working with the PMO provided a clear benefit of process expertise, visibility, transparency and the highest chances of project success. When people worked with the PMO they needed to use Scrum and JIRA.

We also started advocating for tools like Slack and Zoom, which allowed us to have more real-time collaboration, and helped Agile work better. My manager pushed up the ladder and I aligned down. We made a lot of progress quickly.

In addition to aligning process and tools, the PMO started tracking the full Engineering expense budget and Engineering resources. This meant we knew:

• How much money we had to spend and could prioritize what was being done
• Who was available to do the work we prioritized and that the teams were not working on things that didn’t matter
• That they would have a great process to execute the work and could get help or training if they needed it
• That we could provide clarity around progress while they executed the work

While we did so, we also provided a new level of clarity around expense forecasting and resourcing on different projects. We were providing a benefit to the entire organization while we did these things. We became much more effective that year.

At the end of 2016, I looked around the organization and was left with a nagging feeling that we could do more. That we could help others around the organization do a better job with their projects. After all, we were experts. Everyone had projects to manage. They could all learn how to do them better. The PMO needed a more enterprise-level view in order to provide more value. We could make the entire company better.

I started shopping these ideas around. Many of the executives and others that I talked to already knew about this issue and agreed with me. They gave me more ideas and support. We would work in 2017 to make this happen.

The PMO needed a more enterprise-level view in order to provide more value. We could make the entire company better.

In 2017 we began to extend the PMO into new projects and different types of work. With the support of the executives I started to work with IT, Finance, Sales Operations and even Corporate Marketing. We spent time learning about their work, helping them with workflow, and adopting new tools and process. When I spoke with people, I could feel the difference we were making. It was satisfying and enriching. I felt energized each time I saw the success happen – to see the light in people’s eyes when I helped them succeed.

To manage resources, we had to start building out the Project Managers as both Scrum Masters as well as Agile Coaches, to enable and empower them to energize others to do great Scrum even if they didn’t have the bandwidth to be in every meeting. We got all of the PMO people CSMs and CSPOs, while some also got other certifications like PMI-ACP, which helped hone their skills and built confidence.

Meanwhile, we had some problems with the teams that had caused their velocity to slow and they were not performing as well as we would like. Working with other leaders in the organization, I suggested some changes we should make to optimize these teams.

• Teams should have no more than nine people (five is ideal)
• Teams should be co-located together in one place
• Teams should have a Product Owner (and all other Scrum roles) assigned and someone accountable
• Teams should have all required skills to be autonomous
• Teams should put the team first, not their managers

Sure, these were obvious changes to benefit the teams, but we had drifted from these ideals in the previous years. We rebooted and deployed these changes. We found holes that needed to be filled to allow the co-location and filled them. We evaluated the best models to allow for Agile organizations and settled on a Spotify-inspired model* of Squads and Tribes.

I also met with the managers and made sure they were clear they could not and should not look for ways to make the teams better, but instead to prompt and coach them to solve their own problems.

Each team chose a name – we decided on a naming convention for out new teams based on Greek and Roman gods – and I personally met with every single team. I helped them understand the model we were adopting, how this affected them and why we did it. I told them that we wanted them to be happy – and I meant it. Happy teams deliver better results, so their happiness was not only important to them, but also to the organization. I told them they had to find their own impediments and fix them, that their managers were not going to do it for them. It was on them to make things better.

Of course, I also met with the managers and made sure they were clear they could not and should not look for ways to make the teams better, but instead to prompt and coach them to solve their own problems. They also needed to jump right on any impediments that were found and escalated.

We put multiple Squads into Tribes and then began rolling that view up to senior leaders. We had 20+ Squads, but only five Tribes, which was easier to digest. Because the Tribes were customer and business-focused, this allowed us to tie business metrics to Tribe Agile performance, which was fantastic.

The PMO instituted a Scrum Health Survey that allowed us to get some data about how engaged our Scrum teams were regarding Engineering, Culture, Product and Process.

While all of this was going on, I was researching models to scale Scrum out to the rest of the enterprise. I wanted to build a process infrastructure that would allow any team, regardless of the kind of work they were doing, to be able to succeed. Scrum was not a software building process, it was a way to get work done. After looking through a number of models, I eventually settled and got certified in Scrum@Scale, which was the model that Jeff Sutherland created and endorses through his organization Scrum Inc.

That brings me to today.

The executives and leaders of our organization have now gone through an executive workshop on Scrum@Scale and are learning how to be leaders within an Agile organization that uses Scrum. They have learned how to adopt this scaling model to achieve alignment, reveal and resolve impediments and pivot faster than ever before. I already have talks lined up with three new teams to start adopting Scrum process into their own workflow. I have a feeling that our PMO may even be shifting into an Agile Practice as I write this.

We aren’t done yet, but we’ve come a long way. Wish us luck as we continue to iterate our way through this Agile journey. I know we can be even better tomorrow and I am looking forward to helping that happen.

Thanks for reading.

*There is lots of great reading online about the Spotify Agile teams model if you are interested in learning more.

Author's note: You are viewing part two of a two part post. See part one of "An Agile Transformation in Progress" here.