An Agile Transformation in Progress, Part 1 of 2

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

I am part of a company with a rich history that is now moving through a transformation journey towards Agility. It is a journey that I began preparing for as many as 15 years ago, but I suspect that most of my life I have been building the skills I would need to be ready to help make this a possibility.

In 2014 we decided to change the way we build things; primarily focused on how to maximize the effectiveness of a recently-acquired international satellite office. We were struggling with how to enhance transparency, output, happiness and order for our 100+ new coworkers. We formed a Project Management Office, also known as a PMO, to help standardize processes and tools to ensure repeatable project success.

 We worked in an Agile way at that time. It was more of a happy accident, but looking back I think my instincts were right on.

My interest in project management started years before when I was managing a team of eCommerce web developers. We were really good. I had great, talented people to work with, a great manager and support from the company executives; we worked hard, had a lot of fun and got a lot done. We had two sites initially, and then over time with acquisitions as many as six, bringing in millions of dollars in revenue to the company. We were making a difference and we could feel it. We were collocated together in two groups – one in the U.S. and one in Germany. We were 100% dedicated to what we were doing. I still remember how much fun it was.

As I managed this Internet Development group, I spent less time doing development or design work. I spent more time focused on the team and how we were managing the complexity of the different systems we were building or were acquired and then handed to us.

We worked in an Agile way at that time. It was more of a happy accident, but looking back I think my instincts were right on, by focusing on:

• Individuals and interactions > processes and tools
• Working software > comprehensive documentation
• Customer collaboration > contract negotiation
• Responding to change > following a plan

I valued the individuals with whom I worked with and for. We pushed hard to get software out – many times it wasn’t perfect, but it worked and we were iterating, always making it better. We collaborated often and our executive would negotiate with us on almost everything. We didn’t fight change, we embraced it. We prioritized frequently and things moved around all the time. We released whatever was ready weekly – much like a one-week sprint.

I spent more time focused on the team and how we were managing the complexity of the different systems we were building or were acquired and then handed to us.

We managed the work similar to Kanban, with each developer taking two tickets: A primary highest priority item that a developer would work on until he was blocked and a secondary item that he would work on until I unblocked the primary. When he finished the highest priority item, he worked on the secondary item as the highest and then took another ticket from the top of the backlog. Our work in progress was two items instead of one, but it was very effective for us. I was scanning ahead all the time and while I was technically the Engineering Manager, I was turning into a Project Manager (and Agile thinker) – years before I needed to be.

Around 2006 through the great advice of my manager at the time, I began focusing on the process-side of things. He told me that I had a gift for Project Management and I needed to push forward and to become all I could be. He was right and looking back he really helped me zero-in on who I am and what I enjoy. Just because it was easy and fun for me, didn’t mean it was easy (or even fun) for others. I dove into the world of Project Management and Agile, building credentials along the way. I have many certifications now and have experienced so many different types of work, teams and processes. Credit goes to my manager for his insight. I owe him a lot.

Back to the PMO. I’m not entirely sure where I heard it, but one of my favorite quotes is “Luck is the intersection of preparation and opportunity.” You have to have one to take advantage of the other. I’ve been thankful for every time I get lucky. This was one of those times.

In 2014, when I was given the opportunity to start the PMO, I had lots of knowledge in this space. I had a new manager. I jumped right in and we took an inventory of resources, skills, and asked what each person enjoyed doing. It took a few months to get to the right place, but immediately started iterating on how to form and staff cross-functional teams that were right-sized. We had about seven people on each team and everyone – on paper anyway – was only on one team. The problem was the geographic distance between India, UK, Europe and the U.S. To address skills and leadership gaps , we had some teams with people in each of these places.

“Luck is the intersection of preparation and opportunity.” You have to have one to take advantage of the other. I’ve been thankful for every time I get lucky. This was one of those times.

I built content to introduce people to Scrum and Kanban. Most everyone had done some variant of these. I helped each of the teams line up the right tools and process to work for their individual teams. There was your usual mix of Agile tools like Team Foundation Server (TFS), JIRA, Asana, Trello, etc.

In 2014 our goal was to get a PMO boat to float. In the end, it did. We created a PMO with more than a dozen Agile teams doing Scrum or Kanban. They were spread across the world and using lots of different tools. We didn’t have enough visibility into the performance of the teams and the work they were getting done. So we checked in with them frequently and made it work. The boat was floating; it wasn’t a speedboat, but it wasn’t taking on water.

In 2015 we focused on global Agile teams working well together. We still had skill gaps so the teams were scattered geographically. In addition to that, our infrastructure was services-based, which means there was a core group of services that were consumed by many sites and teams. We needed to figure out how to extend the core web services to every team that needed them in order to eliminate the queue for the teams that needed something and causing everything to wait.

We started allocating people from the core services team out to the customer-facing teams. This led us down a path of partial allocation and set us up for a larger challenge. These people were now accountable to three different owners:

1. Core-services team – Needed to be kept up to reduce tech debt and also extended in an architecturally correct way to add functionality.
2. Customer-facing website team – Needs stuff from the core-services team so it can leverage common data and be built out in a way that other teams cam also leverage (aka reusable)
3. Manager – Has his own performance goals for his people, these should align but did not always. 

I see now that this wasn’t the best course but it wasn’t so obvious to us at the time. It seemed natural as part of the cultural change we were navigating. We were centralizing as an organization.

In 2014 at the same time I created our PMO, our organization had appointed a new CEO, and change was in the air. We had recently broken down our traditional business unit silos and had started to centralize skills within in a matrix-style organization. The developers moved from the businesses into Engineering, all the Project Managers moved into the PMO, Legal supported the entire company, Human Resources did too, Sales sold our entire suite of products, Product Marketing took on a holistic view, etc.

We had centralized the core-services group and had then created a new impediment we didn’t see yet. With this centralized approach, everyone who works on the core services team was now partially allocated to multiple teams – people started to complain of waiting on these guys. We were trying to mitigate the delays by pushing people out to the teams that needed them so that skill lived within the team. It didn’t really work. Had we looked up though, we would have seen that it wasn’t just in the Agile teams, but everywhere around the org.

During this stage of the evolution I focused on embracing the cultural differences of the teams and the individuals. I spent a good deal of time traveling around the world. Leading by example, I managed a large multi-team project that had members in the US, Germany and India. I was able to meet the deadlines and launch on time, but I have to admit it was a real challenge. The team only came together once as a full group for the kickoff. We did the rest of the project using Skype and it required a lot of patience and effort by all. I gained some new friendships along the way from what we all went through.

2016 was an important year. I did some research on what a PMO should do, and I got a new manager who had spent time in a much larger organization. He had seen a working centralized model and we came up with some ideas together.

We needed to standardize on the process we use. It’s not that Kanban and Scrum don’t both work – they do if done correctly. But having dissimilar processes made it difficult to measure performance of the teams. We needed to focus on one Agile process and build an expertise in it.

We also needed to standardize on the tools we use to execute. Again, each of these tools worked when used correctly, but in order to get a good view of the individual teams and roll this up to an enterprise-view, we were going to need to get everyone on a single tool. We doubled down on Scrum as the process and JIRA as the tool.

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