Using Value Stream Mapping to Create Shared Understanding and Teamwork Across Functional Boundaries

Jim Cuff: All right. Welcome, everybody. We're here to have a great conversation on a journey with Duck Creek to improve customer onboarding. My name is Jim Cuff. I've been working with Duck Creek as a technology consultant.

A quick thing on my background: I've been an industry practitioner, either as head of engineering or operations, or both, building scale-up SaaS solutions for a while. Some of the companies I've worked at are Amazon Alexa, Endurance International, where we hosted over 5 million websites, Constant Contact, and a few others that I'll not go into here.

We have joining us today Tricia Burke and Josh Berry from Duck Creek Technologies, and the three of us are just going to have a conversation on our journey going through improving a customer onboarding process. So Tricia, I'll let you introduce yourself, and then Josh.

Tricia Burke: Sure. Thanks. My name is Tricia Burke. I am the SVP of SaaS Operations here at Duck Creek Technologies. I've been here for about 18 months, and before that I came from another SaaS company called Diligent, which is in the governance space. So lots of experience in the SaaS world and looking to bring that to the insurance industry, which is where Duck Creek lives.

Jim Cuff: Josh?

Josh Berry: Yeah, Josh Berry. I've been with Duck Creek since 2004. Currently I'm the senior director for our service management department, focused on our on-demand platform. I've seen a lot of growth over the years in Duck Creek, and I've predominantly spent my time in the customer-facing role.

Since I've been at Duck Creek the longest, I'll do a little intro on the company itself. Duck Creek was founded by insurance experts, and we focus in the property and casualty market. Our whole goal is to try to innovate and deliver tools that allow our customers to rapidly implement and deliver insurance solutions to their end users. We've been doing that for a little over two decades, and seeing rapid growth and super excited for what's in our future.

Tricia, do you want to talk through some of the tech side of things with the solution?

Tricia Burke: Sure. Like a lot of companies, Duck Creek started out as an on-prem software company. We were selling essentially a shrink-wrapped product that would be implemented by partners and integrators, with lots of customizations done to the system.

Now we are only selling our product as a SaaS solution, as a service. We have more than 50 customers running our application in our production Azure environment. We have offices in Europe, in the United Kingdom and in Spain, and Europe is a really emerging market for us, so we're really excited to be talking to you folks today.

Jim Cuff: On the SaaS front, Tricia, one of the things that's super interesting as I learned more about Duck Creek as we were working together is that while you guys are on the on-demand SaaS journey, it was super interesting how you're also leading a lot of your customers along as well. When we look at change within Duck Creek, one of the aha moments for me was that you get customers who say, "Yeah, I don't want too frequent a release. I would like a lower change rate." But at the same time, if they wanted one thing, they would want it quickly. It was interesting to see that dynamic of speed and change rate and smaller, more frequent changes being something you were improving at Duck Creek and also bringing that message to your customers.

Tricia Burke: Yeah, it is interesting and funny. Customers want their things fixed immediately, but they don't actually want to absorb the change related with those releases. In as much as we as an organization are really transitioning to a SaaS delivery model, we are also trying to get our customers used to how to operate in that model as well.

Jim Cuff: Josh, you're representing the business, and then you're also interfacing with third-party businesses. It's interesting to have you as part of this conversation, bridging that gap and helping everybody along.

Josh Berry: Right. One of the battles I've had is customers want the things they do want extremely fast. As we try to deliver this SaaS solution, and customers have the expectations they have with a SaaS solution, what we run into is that while we do some things really well, we found out that we were struggling in certain departments where we were trying to keep up with demand. Quite frankly, the provisioning of our environments was not meeting customer expectations, which put a pretty big burden on us from a service management standpoint, trying to live up to that expectation in the customer's head of just flipping a switch and having an environment ready. It was a real struggle for us.

Jim Cuff: That's what that paddling duck image is. It may have looked real smooth on the surface, but underneath the water there's a lot of legs paddling like crazy.

Tricia Burke: Yeah, and it was really about scalability. We could paddle our legs like crazy for a while, but eventually we knew we weren't going to be able to keep up. Thinking about how we were going to scale and grow the business, these are high-class problems that you want to have, but still things that you really need to deal with and think about how to grow overall.

Jim Cuff: Let's talk about where we started as we went through this process of looking to improve.

Tricia Burke: On the plus side, we were keeping pace with our customers' needs. We were meeting our commitments. But the reality was there were our own internal objectives we were not meeting. We had service level objectives for how quickly we were going to be able to onboard customers and set up their operating environments: 30 days for a new customer, and then 15 days for a customer adding environments.

What we realized when we looked at it was that we were hitting our SLO less than 30% of the time, and the success rate for our provisioning process itself was also successful less than 30% of the time. That was the root of the problem for us. We had a lot of good instincts about what needed to happen. We had a sense that we needed to reduce variation, automate more of it, and create fewer manual tasks, but people were really busy and paddling their legs like crazy. It was very difficult for us to actually make the investment we needed to make long-term fixes that were really going to get us out of that place.

Jim Cuff: Josh, from the business standpoint, you're in the middle there, empathizing with all the hard work and being the face of the customer. As we started this, how did that feel?

Josh Berry: The demand for environments never slowed down. If we could get these out at a certain rate of speed, the demand kept coming, whether that was an existing customer that needed extra environments for whatever reason, or a new customer coming on board needing all of their environments up front.

I was in a constant struggle of trying to balance all of these requests coming in and struggling with telling the customer when we can get that done. If we have an SLO but we're missing that SLO, it's hard to tell a customer what we can hit. So we'd be a little bit conservative in our estimate to make sure we do hit what we tell them, knowing we're missing our SLOs.

Then, of course, an emergency would come up, or some need would come up where we'd have to have it right away. That's where the rate of speed of the paddling changes, and other folks come in, and the hero effect of coming in and trying to make it work. It was a constant struggle to balance all of that with our customers and also our internal teams.

Jim Cuff: One of the things I've observed is there are so many people with a huge, quote, "give a crap" factor, who cared a lot and did what needed to be done. As you said, Josh, they would take those superhuman efforts. I heard a DevOps talk around moving from hero to zero, and we had too much need for heroes to save the day versus repeatable processes and, as Tricia says, reducing variation and variability as we went through things.

As we looked at what we did, we started on this value stream mapping process. Tricia, what was your thought? You were saying, "I think we need to look at this differently." Take us back to the start of this. What were you thinking?

Tricia Burke: The interesting thing was I'd only worked here for maybe four months at the time. I started going around and talking to people about the process itself: "Why is this taking so long? Why is this so difficult for us to do?" I started asking a lot of questions, and what I realized was that there were a lot of people who knew their piece of the process really well. They were very deep in their particular area, but they actually didn't know as much about what led up to their piece of work and where the work went after they did it.

It's a multi-step process. There's a number of handoffs. What I really realized was that we needed to take a holistic view. It wasn't just your individual tasks or piece, but the whole process was something people needed to understand. That's when you and I started talking about it and brainstorming how we could create that view for our own folks.

Jim Cuff: Josh, this didn't come in as a technology project. Part of this track is spanning the business-technology divide. You shared with me earlier that you were a little bit dubious as we started, which I had no idea about as we were going through this because you were such a great partner. As we started and looked at getting buy-in and changing and doing things differently, what were you thinking?

Josh Berry: First of all, you have to put yourself back to when that pain was really felt. There was a lot of tension anyway, because I'm trying to face the customer's demands and internally trying to figure out what to put in front of another task. There was already that to deal with. Then this comes in, and my initial thought was more skeptical: "Okay, I'm not sure this is the solution, and I'll believe it when I see it," kind of thing.

As we got through it a little bit more, I definitely started to see the value in this exercise. Of course, we're where we are today. Early on, we were all in a struggle. Tricia, if you remember, this was a discussion we had every day, multiple times a day. There was a constant tension there. Yeah, I was a little skeptical, Jim.

Jim Cuff: Everybody cared a lot about solving the problem, but there was a little bit of "Haven't we tried this all before?" There was also a little bit of "I know my stuff, but I also don't know the big picture." The thing that really helped to get buy-in was that Josh and Tricia were aligned: "We're trying this. We're doing this. We're going to look at this end to end. We're going to allocate some time to do this." It really was a we project versus a me project from technology. That helped a lot.

As you start the conversations, people are super engaged. Tricia, you did a great job of figuring out where the goals are. You set your goals beyond your department.

Tricia Burke: The goal for me always was meeting our customers' expectations. That was always the goal. But I also had a goal of lessening some of the pressure on my own teams, and really freeing them up to do other work. That was one of the conversations I had internally with my own team: "Look, I know this isn't what you want to be doing in a year from now, and I really want to get you doing some more fun and interesting work. One of the ways we can do that is to work through some of these things and really make this process flow a little bit better."

Jim Cuff: If we jump into how we actually went through stuff, we could probably do a whole other talk just on the process of doing remote Gemba walks and value stream mapping. At the high level, when we looked at the approach for the virtual Gemba walk, Duck Creek is a global company. We had to figure out how to handle time zones. We had to figure out how people who are logistically not doing provisioning as a full-time job could get through that.

We used the tools people were familiar with for the value stream mapping exercise. You can get this beautiful value stream map that looks pristine, but we had sort of this Rube Goldberg device-type ending piece in PowerPoint, and it totally worked for the crew in the value stream mapping exercise because everybody in the organization was comfortable with PowerPoint and co-editing.

Whereas you might think, why not use Visio, Lucidchart, Miro, or one of these, it was a piece around using the tools the organization is comfortable using. The value wasn't in having a beautiful value stream map at the end. The value was in the conversation as we went through it. Tricia, what's your thought on how the actual process went and the takeaways?

Tricia Burke: The biggest thing I would say is don't get hung up on the tooling and the technology, because that's not what it's really about. We even tried to use a whiteboard, and it just wasn't working.

The other thing is be flexible. Be flexible about what's going to work with your teams and what kinds of things they're familiar with doing. In our case, because we were using Office 365, people were used to co-editing. For them to get in there and add their own comments was really nice, and it helped them be engaged in the process.

Jim Cuff: Josh, what was your takeaway? You started as all in and committed, but a little skeptical. As we went through the workshop, where did you end up?

Josh Berry: I think my eyes were opened. I think other teams were as well. Looking from the outside in, being from the service manager side, I wasn't aware of all the working pieces that came with provisioning an environment. One of the things this did for me is it made it clear just how big of a challenge was ahead of us.

When you start looking at all these individual teams, and they all have their very specific tasks, this laid it out front to back for the first time for me, where I could actually see what it took from the time that ticket went in to when it went out the door and was ready for a customer to sign in and use it. My eyes were opened, and it gave me a much bigger appreciation of what all these teams were doing. I knew they were working hard, and I knew they had all the right intentions, but I just didn't know how big it was until I saw this map.

Jim Cuff: Grounding that into the DevOps Enterprise Summit, the question is how this gets grounded in the DevOps pieces. I think what everybody saw was, for some folks, the first time, this notion of the full view of the system: moving beyond their process. Before you're going to improve a system, you've got to have an appreciation for the system and what it actually is. There were a lot of aha moments.

Tricia Burke: It was really an opportunity for folks to think about how they were doing their work and really look at it from an improvement perspective, which I don't think folks had necessarily had the time to take a step back and do. That was another really good benefit.

Jim Cuff: The other thing was we had these good instincts around self-improvement within functions, but we really got to focusing on the biggest end-to-end problems to tackle first, which I thought was super helpful.

So where did we end up?

Tricia Burke: Obviously, we felt like we ended up in a good place or we wouldn't be here talking to you all about it. Really, what we realized was that we needed to boil our whole process down to a single piece of automation, a single methodology, where we were doing things the same way all the way up the stack. That was something we realized wasn't happening.

Once we settled on that, we needed to think about the success rate. We needed to deal with quality issues, because the quality issues were causing a ton of rework and troubleshooting.

We went from it taking sometimes more than 20 or 25 or 30 days to lay down the base environment to being able to do that in less than five days, which is enormous. There are still other pieces in this process that we're working through and automating, but getting to that point has been enormous.

Then we started tracking what percentage of the requests were using the new automation we had created, and we're finding now that we're at about 86%, which is great, because we were at about 30% when we started. The success rate for the automation we do have has gotten up to about 95%. Just avoiding rework, avoiding troubleshooting, avoiding having to pull in a resource to answer a question and then waiting for that person to be free: all of those things, we really tightened those up.

Jim Cuff: Josh, how does it look and feel from a customer's perspective now?

Josh Berry: Those numbers are great on the screen, but the best way I can measure it is that, Tricia, we don't talk about it anymore as far as which environment are we going to provision. I didn't mention it earlier, but we had this spreadsheet that was several rows deep with priorities of which environments we were going to provision first, and I was doing that multiple times a day, every day.

I don't open the spreadsheet anymore because we now know we can confidently hit our SLOs with these environments. We don't talk about it because it just happens. It gets done. There's automation. I can set expectations with customers and know we're going to hit them, and that has impacts on when we recognize revenue. The customer experience is night and day different than what it was when we first started this exercise.

Jim Cuff: What about the people side of things?

Josh Berry: On the people side, imagine early on, if you have all of these teams and you're on this boat, the boat's taking in water, and everybody is focused on their bucket, trying to get water out of the boat, but the water is coming in as fast or faster than they can get it out. When that changes and somebody gets in and actually fixes the leak on the boat, which is what we did, then everybody can stop and appreciate what has happened.

Teams have now gone through this together, so now they're better for it, having worked together and gotten through this. Now they're able to focus on things that maybe they weren't able to focus on because they were so tied into a very manual process that we've now automated. We're taking these all-stars and actually utilizing them in the areas that we need them the most because we've now fixed this problem.

Jim Cuff: One of the things we wanted to wrap on, as we're engaging with the community here, is thinking about the ask and outreach. From my observation, Duck Creek was an organization that already had good teamwork in the sense of working together. But the fact that Tricia and Josh were accomplices on this, that they were in it together on this process, really helped make it succeed. Not just in terms of getting the engagement to get started, but also in terms of carrying through outcomes. Basically, if Josh and Tricia think it's a good idea, you should go along. Just trust me.

When you look at your technology projects, look for your partners. Look for the business problem and look at where it goes. Tricia or Josh, do you have anything you want to add on that point or the next one?

Tricia Burke: Moving on to the next point, I'm really interested in hearing from other folks or getting other people's ideas about tools they've used for value stream maps specifically. I'm a big proponent of them. I've used them in other businesses, and I feel like it really helps you understand where your constraints are and where you should be spending your time in order to get the value out of your processes.

I'm interested to hear from folks about how they've done these value stream maps when you don't have a whiteboard and a room full of people, to see if there's anything out there that we haven't explored that might be something we should think about next time.

Jim Cuff: I'll end on the piece about the instincts to optimize your part of the system. If you look at the notion of theory of constraints and look for the bottleneck and focus on that, there is also a piece that when you engage with the community, even if someone's not focusing on the biggest bottleneck, it's the right instinct. Encouraging culturally that notion of continual improvement is super important.

As a community, sometimes we can have that echo chamber of, "We need to elevate the constraint, and let me go throw my Goldratt's book at you," versus, "Hey, thanks for thinking about improvement. Let's engage on whether this is the right thing to start with." That'd be the last one I'd end on.

We've got our contact info out there. I just really worked on this project. Josh, Tricia, any final thoughts as we wrap up here?

Josh Berry: Just to reiterate, it was overall a wonderful experience. Skeptical at the beginning, but at the end, I was convinced. The results speak for themselves. It was a pleasure to be a part of it.

Tricia Burke: It really was, and it was great to apply some fundamental tactics that I had used in other organizations at Duck Creek and really see it in action. I highly recommend it for folks who are trying to work through some of these hard problems, especially when it's cross-team and cross-functional. I think it's really helpful.

Jim Cuff: Great. Thanks, everybody.

Josh Berry: Thanks.