Laksh Ranganathan

I am Laksh Ranganathan.

Naomi Lurie

And I'm Naomi Lurie, and we're from Tasktop.

Perhaps before we start, before we dive in, we should explain the pop culture reference. After all, this is DevOps Enterprise Summit and not Comic-Con. So for those of you who don't know, Ant-Man is a Marvel superhero who is capable of shrinking himself down to the size of an ant. And us being a small company compared to some of the larger enterprises here, we thought us telling you our stories and our experience is like the Ant-Man perspective.

So just a little bit about us. While not maybe strictly a startup anymore, we are a rather small company. We were founded in 2007 in Vancouver, Canada, and today we have 160 people on our staff, always growing. But we do serve the likes of larger enterprises. We have 43 of the Fortune 100 amongst our customers. We have four product lines. We're a contributor to open source product as well. And one of the tenets and the core values of our company is that we are customer and partner-centric. That means that a lot of our roadmap is driven directly by our customer and partner requests.

So while we know we're small, kind of small, just like Ant-Man is here on the top of this Coke can, we do have a pretty large and sophisticated product suite. And we have taken the journey into value stream management, and perhaps our journey is kind of like a microcosm of what some larger enterprises would experience. And since there are a lot of organizations today that feel like Agile and DevOps isn't enough and are expressing the need for something larger than that, value stream management, we thought our experience doing it would be helpful for you guys.

So let's first define what value stream management is. This is one of the official definitions recently put out there by Forrester in a report that they did about value stream management, and it's a bit of a mouthful, but I'll read it to you guys anyway.

Value stream management is the combination of people, process, and technology that maps, optimizes, visualizes, and governs business value flow through a heterogeneous enterprise software delivery pipeline.

Whew. So in my own words, I would say that it is a practice for managing software delivery in a way that provides greater and greater value to your customers while eliminating delays, improving quality, and getting rid of some of the bad things like too much cost or employee frustration. And value stream management is end to end. It starts with the customer, and it ends with the customer. So anything that happens in that process is part of your value stream.

So to be honest with you, a few years ago, we felt like we weren't doing all of that very well. And there were three main factors to that.

One was that we had a really large growth spurt. We almost doubled in size in two years, and all the kind of intimate communication that was previously possible between the small set of people that comprised the company stopped working. We could no longer just have everybody on a call or send an email and get everybody on the same page. It was impossible.

And as a result of that, our leadership started to feel like they were losing visibility over what was happening in the company, the priorities that we were making, the decisions that we were taking. And there was a kind of a sense that that was kind of coming apart.

The second part was increased specialization. So as we were hiring more people, we had people coming in with different roles that we hadn't had before: more business analysts, more deployment consultants, technical account managers. And these different people had different needs.

So we went from a company where you had 40 engineers and everybody on Jira to having more and more tools to support the specialized roles. So to give you guys an example, our product owners, there was a team that was growing. We had more product owners and business analysts, and they didn't want to work in Jira. Jira wasn't working for them when they were having this constant barrage of competing requests, and they needed to triage them and prioritize them, and they didn't want to be working in Jira.

So as a result of that, we had this silo between product and engineering. They each had their own tools, and they were working separately. And then as a result, they had to do a lot of manual-- That's very distracting. A lot of manual copy-paste from system to system, or a lot of meetings and calls and status reviews to see where things were at.

And actually, our engineering manager said that he felt like the product secretary because he was the one that was having to keep notes and put all the different notes and outcomes of discussions inside the epic in Jira. So that was a total waste of his time, as you can imagine.

And the third thing that was happening was as we were becoming more successful, we had more partners, we had more suppliers, we had more subcontractors. So we were starting to have a bigger ecosystem to manage, and the stakes were growing higher, but we couldn't see those dependencies very clearly.

Okay. So we did find ourselves in a bit of a place of crisis. If you think about the three ways of DevOps, you have flow, feedback, and continual learning. So our flow was okay. We had a fully automated release pipeline. We had CI/CD. Everything was good. We released over 100 releases of our on-prem software per quarter. So that really wasn't our problem.

The problem was that our feedback loop to the business was broken. Okay. We had no way of keeping the business people informed about what was being released by engineering, and that resulted in the fact that no one really knew what was going to be in the release. Had something slipped? Couldn't communicate well back to the customers, and as a result of the feedback loop being broken, we couldn't continually learn very well.

So two years ago, we staged an intervention. We said we need to go back to doing what's important to us, which is customer and partner-centric innovation, but we can't scale the way we are now. Okay? We needed to put in place value stream management, right? We needed to put in place an automated, bi-directional flow from start to finish, from customer request until it was delivered, and then through the feedback loop. And we needed to have a set of metrics that would create visibility for our leadership to be able to prioritize for the company and to be able to optimize how we were delivering value to our customers.

So the solution that we set out to put in place was to connect our end-to-end tool chain so that all the tools that all the specialists were working on in the company to create that value were connected, and we had an automated stream of data and information flowing from tool to tool. And the benefit of that would be that we would reduce the waste and the overhead that the practitioners were having on a day-to-day basis. We would just eliminate that so that they could devote more time to generating actual business value instead of coordinating with colleagues and syncing up tools and copy-pasting from here to there.

And we knew that that would also improve employee engagement because once you eliminate even something simple like duplicate data entry, like copying something from your product owner's tool into Jira, if you get rid of even 20 minutes of duplicate data entry a day, you'll see a 20% increase in employee satisfaction. And engaged employees and satisfied employees then give more discretionary effort on the job. So you would see a kind of virtuous cycle of improved dedication and devotion from the employees.

The second thing that we wanted to do was to gather a traceable record of work as it flowed from tool to tool, so we can gather all those little digital footprints of how work was progressing and collect it into metrics and reports that would provide insight and management capability to our leadership.

And we wanted those metrics to not look just at deployment lead time or cycle times from code commit to release. We wanted them to cover everything from the original customer request until it was running in production. And then we wanted to do the same, we wanted to have metrics from the moment a ticket is open till it's resolved. Okay? So we wanted to have that full picture mapped out.

So we embarked on a seven-step process, and Laksh is going to take over and tell you about that. Thank you.

Laksh Ranganathan

So what we did was started by looking at what our value stream looked like for every one of our products. What you're seeing here is what it looks like for one of our products, Integration Hub.

A lot of you might be familiar with value stream mapping. You might have done that as part of your DevOps transformation. Now, what we were looking at was slightly different. We wanted to be able to identify and understand how each of our work items or artifacts manifest as they flow through our value stream.

We examined our customer-centric, value-adding work, and noticed that they have three key sources. We have customer requests that come through from our Salesforce system. We had defects through our ITSM system, Desk.com, which is now part of Salesforce. And we had features that are raised by our product owners to set the direction of the product, and that sat in Targetprocess.

And as we looked at it in detail, all of these artifacts, they related and manifested into other artifacts downstream. A feature request would eventually get related to a Targetprocess feature, which would then create a Jira epic. Stories and tasks would get created, get committed in Git, built and released in Jenkins. And if we had to be able to trace how workflows and value flows across, we had to be able to map all of these artifacts together and automate that flow.

As Naomi mentioned before, we had two goals in mind. We needed to automate our flow, but we also wanted to be able to get meaningful metrics so we can measure ourselves as we go along.

The pitfall of working with different systems and different types of work is it takes a lot of effort to munge them all together in Excel and bring them to a point where we can get similar metrics from the separate information points. And that wasn't something that we were keen on doing because we needed real-time metrics so we could work with them.

So we defined models which align back to business value, like features, defects, test cases, and mapped all of those artifacts that we had, or work items that we had, to these models. And by doing that, we normalized the data points so our metrics for similar items could be collected.

So if you had an incident, you had a case, you had a defect from a code scan, you had a defect coming in from internal tests, all of those would have the same data point, so we could pull out similar metrics from them. And what that also helped us do was eliminate point-to-point mappings and reuse the models, which meant integrating and maintenance of our synchronizations reduced, and the overhead reduced by about 80%, which also helped us along the line.

Now that we had an idea of what we needed to flow and we had the models ready, we had to start thinking about where do we start the integrations.

We started by looking at what we had at the moment. We were already okay on the CI/CD line, so we had integrated our Jira and our release pipeline entirely. So we had metrics like cycle times from code commit to release. We had already integrated ITSM to our Jira, which meant we had mean time to resolution for our defects. And we also were measuring our performance of the engineering team through metrics like throughput and epic burndown, and all that looks great.

The problem was all of these were quite focused on the engineering side of things, and they were siloed in that world, which meant they were not linked to business priorities and product priorities.

The other key thing that was missing was a sense of true lead time from the point where a customer raises a request and how that flows across, and how long does it take for us to fulfill that request.

So we started one step upstream and started with Targetprocess, because a lot of the frustration we had within the organization was because of all the overhead that it took to keep the product teams and the engineering teams in sync.

What that led us is with an integration for our features to epics, and as soon as we did that, it enabled the two teams to understand each other's priorities. There was better flow of information. And we were now able to track how long it takes for a piece of work from the point it was accepted by our product owner to the point it was released, and how does it perform across the entire process between product management and development.

And we call this flow time, and it became one of the key metrics that we measured at this point.

Secondly, as we examined some of these metrics, we realized we could break down all the value-adding work into four key categories: feature work, defects, technical debt, and risks. And we could map out our finite resources and understand how we're allocating between these four work items. And it would give the right data for our leadership to understand how we're allocating our resources now and provide direction to how that needs to be allocated going forward based on business priorities, product priorities.

And we did that for every one of our products, so we could define the direction depending on the priorities for each of those products at that point.

Having done all of that, we were still missing the key item there, which was the feedback loop to the customer. So the next step was pretty simple. It needs to be Salesforce.

As soon as we linked our Salesforce features to our Targetprocess feature request or Targetprocess features, we now closed the loop. We were able to provide our field-facing teams information about what's happening about a feature request, how soon will that be released. As soon as it is released, they were able to speak to our customers, make sure that they had those features available and were able to utilize them, and also feedback information about revenue generation.

If there was a deal-breaking request, our leadership had better visibility of what impact it would have on revenues if that feature is delivered. So that sort of helped, again, close that feedback loop, and we now had lead time from the point a feature was requested to the point we are releasing it.

As we examine these metrics, one of the key things we are now looking at is, are we visualizing this right? Are we missing out any outliers? Do we need to just stick with histograms, or do we need to look at it from a distribution perspective? Those are items we are trying to learn at the moment, but having closed that loop enables us to learn from our metrics and understand how we can improve on them.

Another key thing missing yet was our partner ecosystem. So we went ahead and integrated that as well. As we integrated to our partners' Agile tools, we will now not only be able to measure our own flow time, we were also able to measure flow times within those sections and optimize those processes as well and enable to remove any of the bottlenecks in those areas.

All that sounds simple, I guess. Let's see what that looks like.

Naomi Lurie

Thanks, Laksh.

Okay, so one of our goals was also to create a shared visibility. So this wasn't just something that existed in PowerPoint. Anyone in our company could come in and see our value stream.

So what you can see here is a view from the system where you can actually see all the little icons we showed you in PowerPoint. You can actually see those same tools and their connections laid out here in what we call landscape view. So the green lines indicate the tools that are integrated with each other.

What you see coming up the bottom is stuff that we didn't really talk about at length today, but these are various DevOps tools that are updating or creating artifacts in Jira. And you can see there's a database over there on the left side. That's where all the different tools are feeding their information into the centralized reporting database so that we can run the metrics off of them.

So what's really cool about this is that you can make it a little bit more complex. So you can also display which type of artifacts are being exchanged between the tools. So you can see, if you look at Salesforce over there, that requests are going from Salesforce to Targetprocess, and then in Targetprocess, they can either become requests that go to Jira, or they can become features that go to Jira. And you can see that Desk.com is sending cases to Jira when they need to be escalated for an engineer to resolve.

And then on top of that, we can layer even more information, which are the models. So for this one, I'm going to zoom in.

So we spoke before about normalizing the data. It's very important if you want to do real-time reports that your data is pre-normalized, and you don't have to touch anything to get meaningful metrics.

So if you guys look again, start with Salesforce, you can see that what's coming from Salesforce, we have something that internally we call it a highlighter, which is basically a customer feature request. So it is mapping to a Targetprocess request via a request model. And then from Targetprocess to Jira, we have features becoming epics, and they're normalized through the feature model. So that all allows us to do reports on each type of those models. That's really the essence of what we're looking for.

And this is the leadership dashboard that we created based on all this data that we've been accumulating. And it's all about flow. We want to capture how are we creating value for the business. So how is value flowing through our value stream?

So let's start to... I don't have a pointer, so I'll point with my finger. If you look on the top of the right, you see flow velocity. Okay? That says how many features are our customers getting in a three-month period. And you can see that it's categorized in those four categories that Laksh spoke about: defects, security issues, which is risk, stories, so features, and technical debt. So that's how much are we delivering in a feature, in a release, or in a three-month period.

If you look at flow distribution, that's what Laksh spoke about, is the question, are we putting the right capacity towards features versus debt versus tech debt versus risk?

If you look down below to the kind of line chart, the question there is how efficient are we? How much wait time do we have? So this is basically active time out of flow time. So we can see where we have bottlenecks and issues.

Then flow time is a calculation of how long it takes us start to finish to get something out, right? How long does it take a request to go through the system? And flow load is talking about how much load do our teams have. If there's too much load, then teams are thrashing and their ability to deliver goes down. So we want to keep them at not overloaded in terms of their capacity.

So that's like a top-level dashboard that we can look at to make kind of directional decisions and to identify problems and then to optimize. So if we see that there's a problem, flow time is going up, flow efficiency is going down, stuff like that, then we drill down into these reports, and we find where the problem is. We can find the bottlenecks.

Thank you.

Laksh Ranganathan

So as we went down the path of value stream integration, we realized that CI/CD was a good first step, but it was just the beginning of the journey. As we optimized our release pipeline and took care of all the bottlenecks in that area, bottlenecks, as they usually do, shifted upstream, and if we hadn't mapped our entire value stream, we wouldn't have been able to identify and rectify those, which were fairly upstream and where they spend a lot of time waiting.

The other key insight was we can get a lot of data from our tools, which have the ability to provide some real-time traffic map kind of metrics and kind of view of our software delivery. But being able to collect that information as soon as possible is quite important, and being able to normalize it in a way that will work now and in future is quite important.

We managed to achieve that with the models, which enabled us to build and adjust our metrics quickly.

Having said that, arriving at the metrics that we have right now was a process. We did not get it right the first time. But being able to pull that information and chart them out enabled us to learn from them and understand where some of the gaps were. For example, we were able to understand how that work related back to certain classifications and then pull and tag those classifications moving forward so we can get the right metrics going forward.

Having said that, do we have it perfect now? Of course not. But we are continuously learning, and what we have right now is providing the information that our leadership needs, and we will have to keep learning so we adapt as business needs and product needs change in future.

Having done that, though, we were able to provide our practitioners the ability to reduce the overhead and use their time with value-adding work they need to do and they like to do, and more importantly, improve the NPS rating and the happiness rating within our teams.

Our IT teams are now able to support best-of-breed tools that every one of the other teams need without having to worry about bringing new tools in, which might break a workflow. So for example, we are thinking about or reevaluating our ITSM tool, but we know that any new tool we bring in is not going to break the hard work that we've put in the last one and a half to two years.

And from a leadership perspective, they now have a better visibility of value creation across each of our products. And having closed that feedback loop means that we can continuously learn and react to customer needs very quickly and effectively, and optimize ourselves.

Naomi Lurie

Yeah. So just to conclude here, value streams are all about the customer. So you have the customer at the center, but if you zoom out of your software delivery processes, you can surely categorize them into four main phases. You have the ideation phase, then the implementation or the creation phase, then you release, and then you're into operations.

But if you drill down a little deeper, you'll see that you have many specific activities that are conducted by very specialized roles supported in multiple tools.

So in order to do value stream management, what you really seek to do is to connect all the tools that are participating in the value stream and close the loop between them and collect the data so that you can have a complete picture.

So now that if you're doing DevOps and CI/CD is working and in place, now's the time to start connecting upstream so you get the real end-to-end picture of value creation. So for us, being a small company, perhaps it was easier than for others. But we think that if you do it, you can start to do something like this on a smaller product set. Choose one product and try to do it, and hopefully, if you follow the same steps that we took, it could be achievable for you, too.

Yeah. So thank you. And if you all have any questions, of course, feel free to ask. Thank you.