Ross Clanton

Hello, DevOps Enterprise folks. We're in the home stretch here.

It's funny: usually I speak earlier in the week, and I'm really happy I'm speaking day three because I had no voice day one and two. I have half of a voice today, so we're going to see how we get through it.

Our topic today, which I'm very excited about, is project to product transformation. We're going to talk about a research paper that we produced, and I'll get into the story here in a minute. I think it's really good guidance for the industry.

Before I get into that, let me talk about who I am and who my co-presenter is. I'm Ross Clanton. I've been speaking at this conference, I think, since the beginning. I really love this community and this conference, and I'm thankful every time I get an opportunity to share my story.

Early on, I was driving DevOps transformation at Target, so I was telling a lot of that story with Heather Mickman. The last few years, I was driving transformation at Verizon and was here telling those stories. I'm independent now, so now I get to work with different folks and tell those types of stories.

Amy is someone I had an opportunity to work with at Target, and she was very involved in the transformation there as well. Amy has moved on to U.S. Bank and is doing product transformation work there. Amy has gotten more and more involved with this community over the last year or so too, which I've been really excited about.

You might see our red shoes popping here a little bit. There's a story about these, and I'm not going to tell you it. For all of you who want to hear it, you have to come back to the U.S. Bank talk at the end of the day, but it's a really cool story.

I want to talk about the DevOps Enterprise Forum for a minute. This is a group of people that gets together once a year. Gene Kim hosts it. It spawns off the last slide in all of your decks, when speakers are asking for things they need help with or things that still aren't fully defined in the industry. A group of 40 or 50 people is invited every year, and we go try to tackle these problems. It's super exciting. You get to work with really smart people and create guidance for problems that haven't been fully defined yet in the industry.

Over the five years the forum has existed, they've produced up to 25 research papers now. I've had an opportunity to be a direct contributor, and even to lead the team for some of these, for five of them. I've indirectly contributed to a lot of them as well. The two on the top, the project to product transformation and getting started with dojos, were just published in September, so they're only about a month old. I'm very excited to have worked on those this year, and I think it's really helpful information.

This talk is going to dive into the project to product paper because there's a lot of really good information for folks in there.

Earlier this year, we came together at the forum, and one topic I was extremely passionate about was trying to get deeper guidance for enterprises trying to do a product transformation. I think guidance is starting to form in the industry around it. Mik's book, Project to Product, is awesome, and I would recommend everyone read it. But what has been lacking is real-life guidance based on what enterprises have done and what their experiences have been. We wanted to draw more of that out so we could expose it to the community.

I asked Amy to join our group this year. It was her first time at the forum, because she has so much expertise on this topic and I knew it would be powerful for the paper. We interviewed 14 enterprises that are at some stage of doing a product transformation, captured a whole bunch of information about them, and they spanned 12 industry verticals. We also looked at the expertise we had in the group working on the paper. With that, we built a 100-page report that we're synthesizing down to, hopefully, a relatively simple 30-minute presentation.

With that, I'm going to hand it over to Amy briefly. She's going to lay out the framework for the paper, and then we'll get into some details.

Amy Walters

Before we dive into the details, we wanted to share what we established as a framework for this transformation. Through our research, through our interviews at different enterprises, and based on our own experiences, we discovered that there are typically seven different domains that really have to turn in order for these transformations to take hold.

Starting with the top of the wheel, we have transformation implementation. This is really how you get started: how do you drive the momentum for this transformation, and how do you sustain that momentum over time?

Business and technology synchronicity is about the alignment between business and tech. How do we bring those worlds closer together so they're operating as one entity, not as if there's a wall between them?

Product taxonomy is about starting to define those technology products, which sets the basis for how you form that product-centric organization.

That leads to workforce and talent. How do you start to form smaller, persistent teams around these products, giving them full ownership, accountability, and autonomy to own those products, build them, run them, and so on?

Funding model touches on how we start to fund the work differently. It's super important that we fund the teams rather than these large, extensive projects that take many months to plan for. We'll talk about that later.

Architecture is about how we start to enable more autonomous teams by decoupling large systems and giving them more automation tools. That may mean designing architecture for that if you're just getting started, or perhaps redesigning architecture that's been around for many years.

Finally, culture and leadership is super important. This focuses on how you ignite that culture shift. How do you get leadership buy-in to help sustain the transformation through all the hard bumps and hurdles you're going to go through?

Continuing on our research, we discovered there are typically a couple of different stages to this transformation. It starts with an incubation stage. You're starting to experiment. You've probably found some grassroots folks who are passionate about this type of change and willing to do some experiments.

Hopefully, that leads to the scaling stage, where the rubber really hits the road. The organization is mobilizing around this type of transformation, and everybody is leaning into it, scaling it across the organization.

Optimize is about how you continuously improve on the transformation journey you've been on. You're never done. There's always more to do and more improvements to be made.

And of course there are constraints. We've talked a lot over the last three days about how hard these transformations are. There are obstacles and hurdles. We highlight some of those constraints and how these 14 different enterprises were able to work through them.

Ross Clanton

Now that we've set a framework around how this paper worked, we're going to dive into the insights we captured around each stage in that journey. Let's get started with incubate.

This is highly summarized, so I'm going to tell you multiple times during this talk: download the paper and read it, because we're only going to scratch the surface.

Here are common things we saw when companies were at the early incubation stage, where they're building momentum and working to start driving change across the organization.

First, a common pattern was finding a coalition of change agents: the small group of people within the company who thought alike about this stuff, wanted to see change happen, and were willing to invest in and drive that change. They banded together as a small group of change agents.

They focused on local experimentation. They weren't going big fast. You can't try to tackle the whole organization. Start with a single line of business or a single portfolio, a few teams, get the right leadership involved for those teams, and experiment, because at this point you're still trying to prove what's possible.

From a product perspective, you're not tackling bigger questions yet about how to organize around products and structure the organization. At the most basic level, start to align on what the definition of product actually means for your organization. That's a common thing people tackle early on.

In this stage, you're also starting to sow seeds for future things you need to do. You're starting to look at existing frameworks, like business capability frameworks, to think about how you're going to anchor around product. But really focus on defining at this stage.

New roles start to emerge in these transformations: product management roles, product owner roles, and Scrum Master roles. Companies start to introduce and grow those roles at a small scale. For example, what do experience-based product managers versus technology-based product managers look like for your organization?

Some organizations start to introduce a dojo model early when they're working with this incubation team, but I'll talk more about that in scaling. I think that's where most companies are really focusing on dojos.

From a funding and governance perspective, at this stage you're working within constraints. You're not changing your funding model when you're incubating. You still have your project-based funding model and most of your enterprise governance model in place around organizational processes.

But for the teams you pull out and put off to the side to test and learn, you figure out how to abstract them away and allow them to work a little differently. That could look like the VP of the pilot organization still having annual project-based funding, but then working to turn it into product funding for the incubation teams. You're not changing the broader organization at this point.

From an architecture perspective, you're largely starting to get the foundation in place. You're engaging and aligning architecture stakeholders in the organization, whether enterprise architecture or business architecture teams. You're looking at frameworks you can anchor to later when you start defining product organizations. And you start thinking about and introducing patterns around creating a lower-friction environment for developers to release software. At this point, you're not doing that at scale. You're figuring it out with incubation teams.

Most importantly, I can't stress this enough: the most important thing we saw with companies having success with incubation was that they were creating a movement in the organization. They were focused on creating a grassroots movement. They were igniting the base and getting them excited. That's only going to get you so far, and you'll hear my Jonathan Smart quote soon, but you have to create a movement at this stage and really focus on the bottom.

What are some outcomes companies saw as they were getting through incubation? You're starting to prove what's possible. At this point you're experimenting and proving to the organization. You're not scaling anything. You're not doing thousands of teams. You're doing a few.

You're generating excitement for change. That excitement may still be just a minority, a small portion of the organization, but when you generate excitement and start to build community around that, it fuels change across the organization over the long run. And you're building momentum. Those early teams working to create change are working together to show it's possible and prove to others what they can expect when you get to a point of scaling this out.

Now that we've talked about incubate, let's talk about scale. This is a really challenging stage. At this point, you're ready to make a bigger investment. You're seriously looking at changing your organization at scale.

From an implementation perspective, it can't just be about grassroots now. I'm going to quote Jonathan Smart from Deloitte. He used to be at Barclays and leads the Agile practice for Deloitte in the UK. He had a great quote at the London DevOps Summit: grassroots change is amazing, but the problem with grassroots is it only goes as high as the grass ceiling. He's so true, because if you get this bottom-up movement going, at some point, if they don't have support from the top, they get frustrated and leave. You have to make sure support is layered in at the right time so you can grow these changes and scale them out in your organization.

That's about aligning the right sponsors and getting the right champions. It's about making sure you can articulate how this technology transformation can support and align to your business strategy.

Some of the hardest work in these transformations was business and technology alignment. Now the rubber is really hitting the road. You're starting to map teams around products, build value streams for your organization, group products to those value streams, and structure teams of people around these products that mirror both the business and technology sides of your organization. It's a significant amount of change.

You start truly building your product taxonomy. There are different tactics for how to do it. Amy is an expert in this, so talk to her if you really want to understand. You actually start to map what the products will be around your organization and map them to the value streams.

You start growing engineering competency, and also product and Agile competency, across the organization. Many companies are doing training programs and different ways to start learning skills, but this is where a lot of companies are really investing in dojos as a scaling mechanism. You're scaling learning through immersive learning centers so people learn these skills in the context of building the products and services they were already planning to build.

This is where you really start to tackle the funding model, which is really hard. You're shifting from annual project investments to funding long-lived teams. You're funding team capacity instead of project investments. Your whole model for how you measure results and outcomes has to change to support that.

From an architecture perspective, you're focusing on how to introduce new architecture, new platforms, and changes that can enable these new product teams to be autonomous and decoupled. If they can't actually operate as a product team and they're dependent on 50 other teams, there will be a lot of challenges. You're not going to change the architecture overnight, but investment needs to start here.

This is also where you're linking bottom-up and top-down change. It has to come together at this level, and leaders are fostering and growing that change.

The outcomes you see here: you have leader champions who are really driving and leading change across the organization. You've started to drive strategy and see results and measures improve at scale. You're organizing around products and accelerating. People are delivering more value faster, and you can start to measure that.

Now let's talk about optimize. A few companies we interviewed were at this state. It definitely wasn't all 14, but we got some really interesting patterns from them.

First, they started to expand their ways of working, product practices, and Agile practices beyond the technology organization, even deeper into the business. Think business-oriented teams that own processes, like marketing teams, that didn't necessarily have a technology component.

Convergence was starting to happen. Business and technology were truly starting to come together, organizing more around a team, and product owners became more of the authoritative source on prioritization. They got to a point where that truly wasn't happening through traditional top-down approaches.

The product taxonomy at this point is continuous improvement. You're constantly adapting and learning which products are adding more value and which ones aren't, and you can tweak your model.

The organizational structure starts to lean out. I know this is a controversial term, but some companies started to get rid of traditional PMOs and traditional planning, what I would call overhead functions. It didn't mean there wasn't a home for those people, but there was investment made into them so they could transition to new roles. When you move to this model, you have an opportunity to really lean up some traditional practices.

The funding model also expanded further into the business for some companies. They were starting to fund non-tech investments more from a product perspective and not a project investment perspective.

From a decision perspective, architecture decisions became more community-driven. They created models that allowed the engineering community to contribute to decisions so their voices were heard, and it wasn't top-down.

They truly started to get transformational leaders in place: leaders who could inspire and continue to lead change inside their companies, and in some cases inspire and lead these changes in the industry.

Some outcomes at this stage: you start to simplify the organization, making it more highly adaptive and fast. That creates an environment that fosters innovation, where you have a more resilient and adaptable organization. Innovation flourishes in that scenario. Some companies can start to influence the industry from a leadership perspective.

That is a 100-page paper on one slide. Those were the 21 things you just learned, mapped to the framework Amy laid out. I am not going to walk through this. Download the paper, please, because you can read about all of that.

With that, we wanted to walk through some case studies that are also in the paper and that we think will help drive some specifics home. I'm going to hand it back to Amy.

Amy Walters

As we mentioned, we interviewed 14 different companies, and we took the learnings from those interviews to compile the guts of the paper, walking through all of these domains. But then we took time to create three case studies. We wanted to go deeper with each and tell a more robust story about how they worked through the domains.

We have three case studies in the paper that span the three stages: incubate, scale, and optimize. The case studies span three industries: an apparel and sportswear enterprise, a global media service provider, and a retail enterprise.

Let's get into it. We'll give you just a little sneak peek of each because we don't have a lot of time, but we wanted to share a couple of nuggets or highlights around a couple of the domains for each.

The first is a case study around the apparel and sportswear company. They had success with their incubation stage that helped them move into the scaling stage, which is what they're currently in. They started incubating their transformation in the digital and customer-facing portfolios. They had a leader who was passionate about this way of working and had previous experience in a product model, so she started to champion this way of working.

She prioritized lean value stream mapping and a continuous improvement model. She created strong relationships within the business with people who were also passionate about similar outcomes, and they came together. She knew she had to be bold and act fast because there was a Scaled Agile Framework implementation happening across the organization, and she felt strongly that this product model would be a better way to go and would show more value.

She found teams willing to experiment, take on lean value stream mapping and the continuous improvement model, try some things, and keep going. Ultimately, this built momentum into their scaling stage. Their scaling strategy was to treat the transformation as continuous, small, consecutive experiments, always improving, communicating across the broader organization, not just within IT. We don't want this to be an IT secret or an IT transformation. We have to bring our business folks along, and then align business and technology strategies to drive the transformation forward.

The second one is an example of a company in the midst of the scaling stage. We focused on how they attacked the funding model: how they started to shift to funding the work of the team instead of large projects. They had to shift away from funding projects and start to fund the team.

Has anyone seen the show Shark Tank? They treated their funding model much like the show Shark Tank. They formed a common product backlog for the product teams. All the new epics that came into that backlog had to have a compelling business case. Every Friday for about 90 minutes, technology and business leaders came together to pitch the epic to the Shark Tank committee. Based on the value and the compelling business case, they were awarded funding for the work they wanted to do within those teams. Not all work was approved. There was some competition and some politics. It was based on the business case they pitched and the business value they articulated.

The last one is a retail enterprise that scaled through all the stages and is very much in the optimize stage. They're continuously improving and coming up with new ways to improve their transformation all the time. This touches on how they leveraged product taxonomy to form their organization and excel.

They took time to draft their taxonomy. Technology leaders did some iterations. Once they had it set well enough, they started to form persistent, sticky product teams that were cross-skilled. They started to replace traditional roles of project managers and business analysts with product owners and Scrum Masters, and they increased the number of engineers, growing engineering talent.

They had a dojo and leveraged it heavily to accelerate teams, teach them their new roles, and allow them to refine the definition of those products, further maturing the product taxonomy.

Soon, these technology product teams were moving faster than ever. They were no longer the dark, black box of IT. Business teams were brought into sprint reviews and demos. They were hearing words like scrum, sprint, DevOps, and Agile, and asking what was going on: we're not giving you requirements and then not hearing from you for a year; we're being brought into the conversation all the time.

The dojo was a well-known concept at this point, so the business teams knew where to get help. They reached out to the dojo coaches and started asking for help. They were interested in working in this way, adopting Agile ways of working, and acting like more product-centric teams. They came into the dojo, went through similar workshops to the technology teams to build those skills and adopt new ways of working, and the coaches took that opportunity to bring the technology teams to the table. For the first time, they had a new way of working together: technology and business sitting at the same table, collaborating toward common outcomes.

Please download the paper, because you'll learn much more about all of these companies and the three case studies. We would be remiss if we didn't thank the team that came together to write this paper. It was a lot of fun and a lot of work. There's a lot of expertise on the slide, so thank you to all of them, and thank you to IT Revolution.

Last but not least, we need your help. We need you to download the paper. We want you to use it and read it. We want to continue to expand on this topic, so give us feedback. Give us your stories. We want to continue to expand on this so others can learn from it as well. Thank you.