Realizing your potential “Velocity”The origin story of UrbanCode Velocity

- 2 -

IBM and HCL’s statements regarding their plans, directions, and intent are subject to change or withdrawal without notice at IBM and HCL’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Information is confidential and must not be shared or redistributed without permission from IBM and HCL.

UrbanCode is a trademark of IBM Corporation, registered in many jurisdictions, and is used under license.

DISCLAIMER

- 3 -

Innovation happens naturally when trying to solve your own internal problems. At least, that has always been the case within UrbanCode.

- 4 -

Almost twenty years ago, UrbanCode created one of the very first continuous integration servers, Anthill (which later would be renamed AnthillPro in 2006), when we needed to solve a simple problem for ourselves.

The problem? Associate a set of code changes to the artifacts that were produced from the build. At the time, we didn’t know that we had stumbled upon the groundwork for an enterprise CI solution, we were simply scratching our own itch.

- 5 -

Fast forward several years to 2017, and again we found ourselves trying to come up with a practical solution to our own problem. This problem was a result from all of the commercial success we had experienced in the DevOps market.

We needed to figure out how to balance planned work; work which is in-scope for an iteration, against unplanned work. For us, unplanned work manifested itself in the form of critical customer situations that needed technical assistance from our development team, and routine L3 technical support.

We were struggling to complete all of the planned work for a given sprint, and the feedback from our developers was consistent… they couldn’t possibly complete all of the development work and be asked to put out support fires.

- 6 -

We tried several approaches to solving this problem.

- 7 -

Attempt #1 – more bodies, more productivity

The first solution was to simply hire more people. If we hired a dedicated support team, we could free our developers to focus on what they are getting paid for - writing code and delivering business value.

The main challenge with this approach is that for an enterprise software product such as ours, the L3 level of support requires deep technical knowledge of the product. We found that it took at least 6 months for a new hire to be somewhat useful.

Even worse, someone had to train these new hires, and that often fell to friendly developers who had the product knowledge, but also already had way too much on their plate. In many ways, this exacerbated the situation. Developers had their day to day work, plus they needed to help with L3, and now they needed to help educate new hires.

Were we drastically more productive? No.

- 8 -

Attempt #2 – divide and conquerIn parallel to hiring, we tried to split the team into two working factions; one group would be fully dedicated to development, and the other would be focused on support.

The plan was to rotate developers through these two teams, so that nobody was left on the support group for too long. As we quickly learned, “the road to hell is paved with good intentions.”

What we had basically done was cut our development team in half, and therefore we could only deliver half of what we promised the business and our customers.

As we pushed ourselves to meet critical business deadlines, we found ourselves keeping our senior developers on the development group longer than anticipated, and therefore team members were stuck within the support team for longer than intended.

Did it solve the problem of addressing planned vs. unplanned work? No.

- 9 -

None of what we were doing was sustainable. We were out of ideas. One day, the team was at a retrospective meeting when someone said, “there is just so much support, we can’t keep up.”

Then someone asked, “how much support work do we actually have?”

- 10 -

That was an interesting question.

Could we track the ebb and flow of our support? What would be learn?

Over the next few weeks, we started tracking how many support tickets we had. We were tracking things like how many closed tickets compared to new tickets.

Were we closing them any faster than they were coming in? Were there times of the month that were heavier support days than others?

- 11 -

The idea was simple: If we can track it, maybe we can plan for it.

We started giving a few developers free time to explore new technologies and continue working on our little incubation project to start to track our unplanned work.

- 12 -

Within a few weeks, we were coming up with all sorts of cool ideas.

“Wouldn’t it be neat if we could track how a support ticket moves from L2 to L3? We could track it against our SLA’s, so we know if a ticket has languished for too long.”

We started to visualize a support ticket as a simple little dot on a screen. That dot had a handful of information associated with it, including the customer name, the summary of the ticket, when it was created, who updated it last, etc.

- 13 -

We were not inventing anything new; instead, we were simply aggregating the data available to us and visualizing it in a way that was useful to our team.

- 14 -

More ideas came forward.

“What if we could see how many tickets each person on the support team has assigned to them? Then if we get a really challenging ticket, it would be clear who can take on more work. More importantly if a developer needs to drop existing tickets to put out a larger fire, we can easily identify what they are currently working on.”

As a team, we were learning so much. We could take this data and compare it with the data in our agile tooling that was tracking our sprints and story points. We could easily align our developers to critical value.

It gave management the ability to see where the majority of the teams’ time was being spent. It also allowed us to surface the most needful customers, which meant we could put client advocacy plans in place and start to be proactive instead of reactive to their needs.

- 15 -

What we had done was take something as simple as a support ticket and plotted its adventure from creation to closure. We knew how long it spent at each stage of the cycle. We knew when it became held up, or when it moved repeatedly between different states.

What we had done was plotted the value stream of that support ticket. That support ticket represented customer value. Now that we knew about its journey, we could try to improve how long it takes from creation to closure.

- 16 -

This is when the lightbulbs really started to go off. If we were able to apply these principals to unplanned work, something that previously had extremely limited visibility, why couldn’t we apply the same strategy to planned work - something we know a ton about?

Our team was exited to try it out, after all, we had all the data we needed. We had pull requests, build times, deployment statistics, backlog stories, and more to create a robust picture of how our team is developing software.

We started to visualize our entire backlog and gained information into just how long some stories can atrophy. We noticed that often times developers would have four or five stories in-progress at any given time and that it was contributing to a work-in-progress (WIP) problem. With these discoveries came more excitement. What else could we learn?

- 17 -

At some point during all of this innovation, the business came back to us with specific questions around new functionality that we were in the process of developing for an upcoming release.

“How far along are we with the new UI updates for third quarter release?”

Previously we would have given an honest answer, but it wouldn’t have been very specific. We would have said something similar to “the work is in progress, and we don’t have any issues at the moment. We seem to be on track and feel pretty good about the delivery date.”

But things were different now. We didn’t need to simply say it was in development. We could pull up the dots view and search across them for all UI related stories that were planned for the third quarter.

- 18 -

Instantly we could see what was still in the backlog, what was being tested, and which ones were test complete.

We saw one that was rejected in test and sent back to development for additional work. The details were not as rosy as, “we feel good about delivering on time,” but we had the information to give the business. We also knew exactly what needed to be done to get that work across the finish line.

- 19 -

This new tool, internally named “dots,” started to bring immense value to the UrbanCode team. We quickly realized that other organizations could benefit from seeing their software value stream details in the same way.

- 20 -

So here we are today with our latest enterprise tool, UrbanCode Velocity, a value stream management tool that can help your teams visualize their everyday work.

For those of you flashing back to high school physics, here’s the very-scientific definition of velocity:

The velocity is the time rate of change of displacement. If ‘S’ is the displacement of an object in some time ‘T’, then the velocity is equal to, v = S/T. The units of velocity are m/s or km/hr.

- 21 -

Or in other words, Velocity is a measure of how fast something moves in a particular direction. And because UrbanCode Velocity is designed to help move teams and their business goals ahead faster than ever before, we thought the most straight-forward name was the most fitting.

- 22 -

So, after lots of late nights of imagining a way to do DevOps better, we’re so excited to introduce UrbanCode Velocity to the market.

UrbanCode Velocity is a management tool that helps ensure the work your organization is doing is aligned to business value.

It fits in with all of the tools you already use today, ready to aggregate the data, and visualize it in such a way that you can truly know the DNA of your organization. Finally, you can fully understand how value is delivered, from idea to customer deliverable.

- 23 -

UrbanCode Velocity

• Transformation leaders realize the value of hidden continuous delivery data by making it visible and actionable

• Development teams have a single view for all of the team’s Pipelines

• Release teams can move to more frequent releases with light-weight release management

• Delivery teams go beyond traditional Agile views to provide end-to-end value stream transparency

Optimize flow across your software value stream. UrbanCode Velocity optimizes software delivery beyond automation by providing visualization, insights, and orchestration across the value stream

- 24 -

Want to give it a try for yourself?

Visit UC-Velocity.com to download a free trial of UrbanCode Velocity today.