Full Stack Friday: Understanding speed for product delivery teams

What is fast?

The need for speed in product delivery is real. How do you know if your product delivery team is fast? It’s not velocity.

The perceived value of a product delivery team's capability varies from one technology leader to the next. A CTO accelerates through architectural maturity. Meanwhile, a CPO navigates with data-informed decisions. Yet, the goal is the same for all parties: fast delivery.

Hear from Devbridge Managing Director, Raymond King.

Watch the talk:


Hello. Welcome. We are here in sunny London. Thank you so much for joining us on this virtual Full Stack Friday event. My name is Raymond King. I'm the local MD here for Devbridge in London. I'm coming to you from our socially distanced office here in central London, where life seems to be getting back to normal. So that's great. I hope that you and your families are doing well and are getting ready for the weekend just as much as I am. The reason why we're here today is to talk about fast. Specifically, what is fast and what does that really mean for you and your delivery teams? Well, right off the bat, I'm going to be very clear that fast does not mean velocity. Having a team with high velocity does not necessarily mean that you are fast. In fact, given the context fast means a lot of different things to a lot of different people.

So as I was preparing for this talk, I did what we all do I Googled it. I Googled what does fast mean drink products and delivery. And as you can imagine, it was not very helpful. Now, the good news is that further validated the reason why we need to have this conversation. So in priming for this, the best way I knew how to define this was to draw a parallel to a sport that I followed very, very closely. And that is Formula One. See for those of you that follow Formula One, you know, that fast is when you are able to drive 155 miles an hour in the rain, you're able to change four tires in under two seconds. Fast means having the best car running seven years in a row and as a result, being on the most podiums ever. See, I'm a fan of F1. Since moving here in the UK over the past few years, my passion for the sport has been rekindled.

F1 to me is the ultimate team sport. While you do have 20 individual cars, that are lined up on the grid, each car with a different goal, for some it's to actually win the race. Whereas for others, it's to maybe finish in the first ten, maybe go past a competitor and in some cases it's literally just to finish the race. Because of that, it's a sport that's focused on delivery and delivery usually means you have a team behind you. The team has to build against a set of constraints, which in the case of Formula One, it is against FIA regulations. However, each team has a cross-functional unit behind it that pulls up a plan and enables the driver and the team as a whole to execute that goal.

To visualize this, imagine that the car is the product and then the driver is the client. This means that everyone else that's surrounding that team is trying to make sure that that client, AKA that driver, can deliver a result using the product, AKA the car. So the geek in me finds is very exciting and it's a good way to hook into a sport that I find fun but also tie us back to today's topic. Fast is a state, by itself it is not an indication of value. Being fast is actually an enabler. Being fast is having a clear plan and being able to effectively execute that plan so that you can achieve a result. So in summary, fast is results. That is the time it takes to efficiently deliver a goal or an idea to market. Setting that context helps us understand that we don't really want to focus on celebrating timescales when instead celebrating results when talking about fast delivery.

Now, why does this matter? Why does being fast in product delivery actually matter to you, your customers and obviously your delivery team? Well, for those of us that have been involved in deliveries, we know that the need for speed is real. We know that every stakeholder that I have ever worked with has always had the question of how fast can this be delivered. And that's because being fast is the difference between winning or losing market share. It is the difference between meeting your customer's expectations and actually making them feel good about your product. Being fast, enables you to maintain your relevance in your industry. Being able to deliver that feature, that piece of functionality that delivers a result for you and your customers. Most importantly, however, being fast is important because it helps you efficiently use for resources.

A quick anecdote story about a client that we have here in the UK. And this is PWC. Hopefully you've heard of them. Specifically with PWC, we engaged with their forensic services group. What this group does is they work with clients, large organizations, corporations to help them respond to regulatory or legal matters. PWC helps them find analyze assemble data that is needed as evidence against these large cases. So as you can imagine, the scale of work for this team is huge. You have large cases, a lot of data that needs to be passed through in order for these cases to have evidence that's ready to go to court. The problem that PWC had is similar to what a lot of our clients run through, which is, how do you do more while maintaining the same level of quality with the same or less resources in this case? Because again, in their world, we're talking about legal cases here where failure actually would lead to disastrous outcome. So the key here was maintaining quality while scaling up the amount of work that you could do.

It's hopefully very obvious by now that the need for speed, the need for fast delivery for this business unit was obvious. That is, they had to use speed, being fast in delivery to efficiently use their business resources. Working with Devbridge, we brought in our culture of work, our maturity and practices, the tooling that we built over the past 12 years and the processes that we follow to make us successful, to ensemble a nimble team that actually delivered a value and a result for PWC and their team.

The result is, we built a bespoke solution that digitized their workflow and automated the manual task that they have to do for the product and we actually had to result for them. We brought in 26 times efficiency in the ability to process case files and we did so in eight weeks. Now, this is fast because we got a result. Yes, we did it in eight weeks, which by conventional wisdom is also fast but if we had delivered the product within six weeks and that product did not really bring any efficiency or solve the core problem, would that have still been fast? The argument we're making here is that being able to do something in a short period of time and not providing value in that same time span, it's not necessarily fast. And I think that's one of the things I want to have you take away from today, which is being fast, is having results.

Now, we can't talk about fast without talking about slow. And I think simply put, given that fast is results, slow is frustration. Slow is missed deadlines, slow is unmet results. Slow is ineffective use of your resources, which can be a waste of time and the waste of time, ultimately is a waste of money for those of us that are in business. So for today's talk, I want to basically drop five areas that can increase speed for your delivery but maintain that speed so that you have fast delivery results for you, your clients and your customers.

So to do so, what I want to talk about first is one of the heroes in the sport that I follow, which is Enzo Ferrari. For those of you that know Enzo, he was the creator of one of the most iconic brands in the world. One of the brands that just by hearing their name, you think of the word fast. See, Enzo understood fast and granted he never defined it in the scale of product delivery, the concepts behind how he worked to build the Ferrari brand is very anagolous to what it is that we're trying to do as product professionals. It all starts with focusing on clear goals. Once you have clear goals, helping your team actually incrementally deliver on those goals while adjusting to the environment that obviously creates changes and dynamic reasons for your team. As you do so, don't forget to optimize for the whole. And as leaders to help your team go fast is to make sure you distribute decision-making.

These five areas are what Enzo effectively brought into F1 and that's why he and now all F1 teams are seen as a definition of fast. My role is to run through these five steps, give you a definition of what they are and give you three specific actions of each on how you can bring these into your team and onto your organization. To get started let's talk about focus. See, focus is basically emphasizing for the team to finish work rather than to start new. Now, what this means is you want to complete work that meets your definition of done. I'm not saying to linger on until things are perfect. It's for you to set a focus for your team to understand what done looks like and then letting the team actually finished done before moving on to something else because the alternative is when your team's interrupted with new priorities, when they got bogged down with task switching, a lot of activity's created but value is not being delivered.

So the advice that I have for senior leaders and stakeholders is protect your teams from distractions and can do so by providing clear priorities, refraining from shifting direction during iteration periods. Again, for those of us in delivery, we know that the worst thing you can do to your team is change your requirements mid sprint. Add stories, remove stories, change acceptance criteria, mid sprint. That lack of focus means your team will not be able to deliver. And the last and most important piece here is set and adhere to work in progress limits. Now at Devbridge, we adopted this method called 333. And what 333 means is it's basically you set three categories. So any three categories and within these categories, pick three priorities.

So at this point you have three categories, three priorities each and to make these meaningful set, three success measures across all of each. This helps you make sure the team is working on the most specific things to want to work on and they know very, very clearly what good looks like. The way you can also report on this and ensure it's actually happening is to actually incorporate a Work Item Aging chart. Now, on the surface, this chart does the complicated but what this chart tries to do is show three major things at once.

First, what your working progress limits are for each step in your process. Second, where each work item is on the journey to being completed. And third, and I think the most important, what your team's duration versus expected outcome looks like. Ideally, a smooth line here helps you know that, A, your team is focused and that you're getting the results that you probably want. That's the first one, maintaining focus.

The next one is predictability. In F1, it's important to know that, the ultimate sprint deliverable is a lap time. Having a team or having a race car that's able to do predictable lap times across different conditions, builds confidence towards a result. The same is true for your product delivery teams because not having predictability creates uncertainty. Uncertainty of a team's capability creates anxiety. Slippery slope argument, where anxiety created stress, stress creates bad results you can keep going down this slope as much as you want to go. The point here is you don't want to have uncertainty. So this one is directly for the product delivery team. You have to create demonstratable piece of work every single time, that is predictable to your leadership.

The way you do this is, break down larger tasks into smaller measurable increments of work. Tying it back to F1 real quick. An F1 lap actually is made up of at least three sectors. Each sector is further divided into either straights or turns. What an F1 driver and an F1 team do is they maximize for those small increments of work. Doing so enables them to be predictable. They also timebox how they run through each of these segments. And the same is true for you. If you're running Scrum or Kanban, you measure and you timebox your delivery period.

At Devbridge, we pick two-week sprints as our preferred way of working and this gives us enough time to know what we can deliver within each predictable matter. And the third here is consistent ways of working or consistent working agreements. Just making sure everyone's on the same page and everyone knows what to expect enables you to minimize your volatility. And that sprint volatility chart actually is a good way to show a trend and help you understand how predictable your team is.

Now, I pulled this example from one of our projects that's been running for about four months and what you'll notice that after the initiation period, the team's delivery cadence actually flattened out and we actually had a predictable team of volatility, even though in some cases, the team delivered more or less for sprint. And again, and that's the point here, we can make guesses, we can make assumptions if the team has predictable delivery.

The third is pace and pace basically means you want to maintain a steady speed as you get towards the finish line. The picture behind this deck here is actually a Lewis Hamilton from the 2020 British Grand Prix. On the last lap of the race, spoiler alert, Lewis blew out his front right tire. So you have Lewis Hamilton, six time world champion blowing out a tire on the last lap of a race and partially was because of conditions but also it's because of the pace that he kept throughout the race. The point here being, peaks and troughs will always introduce quality problems. Starting and stopping is bad for an engine, starting and stopping is definitely bad for your tires. So the idea here is, maintain a smooth burndown of work by actually planning your sprints based on previous performance.

So here's where I would raise my hand and say, velocity actually helps you out with this because knowing your team's previous velocity and your team's current or previous delivery rate actually helps you plan for your future performance. So the team on average does about 30 points to maintain pace, please don't put more than 30 points in your upcoming sprints. The other point here is prioritize your tasks with larger dependencies. Do the big stuff up ahead so that you're not left rushing at the end of the sprint trying to get it done.

Also, working in product delivery is a team sport. Rally around blockers, make sure that we keep the tires rolling and end up with a sprint burndown that looks something like this. The ideal burndown, while again, as a unicorn is ideal, it rarely ever happens. However, having a smooth burndown enables you to represent pace and actually encourages you to make sure that you're working on the right things. So we've talked about focus, we've talked about being predictable, we've talked about having a steady pace.

The last two have to do with automation, which is bringing in tooling. The reason why F1 car has actually changed four tires in two seconds is because they have a tire change gun, which is automated removing all the bolts and screws that hold the tire in place just like that. So the idea here is not having your team complete repeatable tasks manually, is not really a good way of using their time and also does not add any value to your business or to your delivery timelines. So bring in tooling to shorten deployment, bring in tooling to help you release continuously and bring in tooling to remove all of the manual unnecessary tasks.

The way we do that is as such. All of our teams, and I recommend you do the same on your side, is maintain all functional teams, not cross-functional because I think the term cross-functional actually has been bastardized to mean, well, I have an engineer and I have a product manager and maybe have a designer, so I'm cross-functional. What I'm saying here is bring all functions required to run your product delivery team. And in most cases, that means having test engineering and DevOps, who are the ones that are going to help beef up your automation.

Having those two functions in your team actually helps you build your delivery time and your delivery pipeline from the start. One of the things we try to do is we try to make sure our end to end delivery pipeline is built and tested with each team release so that we know the pipeline works and we end up with a mature delivery pipeline that looks like this. So whether it's in development, to staging UAT or have production, we're able to automate whether it's unit tests, end to end tests, bills and whatever else they may be. So the point here is this is a very complex slide, I'm not going to go through it all but we can send this out as a lead behind for you to look at later.

The last one I'll go through of those five is decentralized command. Your ability to have agility in decision-making, allowing your team to make decisions and knowing that when that decision fails, they can make another decision to fix it and enables you to be fast. Because one thing we've learned is hierarchical decision making is actually a bottleneck to progress. There's a term in the industry called the HiPPO. The highest paid person's opinion. And typically what happens in some large organization is the HiPPO has to make all decisions. So effectively what you have is a team that may be running really, really fast, is all of a sudden met with a large bottleneck of thiS HiPPO, who is probably very busy and not as engaged in your delivery. So the idea you want to do here is enable your team by allowing those that are closest to the problem to make decisions, especially when it comes to practical. Obviously define your goalposts, give the team space to operate but bounds that it cannot go past and make sure that data becomes King.

A story that I have is, we at Devbridge do these Lean Requirement workshops that is usually a day or two, where everybody from senior stakeholders to business users are involved in planning. We talk to through the vision, the context and ultimately a story map of what we're supposed to build. This picture you're looking at actually is from a live workshop where we had senior stakeholders participate in the privatization process. This is the goalpost setting that I was talking about. You want to have senior stakeholders there because you want to make sure everybody understands the scope and the vision. However, when it came to actually building the solution, the stakeholders stepped back and the core team took over and did tactical decisions based off of that vision.

So to quickly wrap up, the goal to being fast consistently is not to worry about speed but instead is to maintain focus with clear goals, break down work, so it can be incrementally completed, adjust to an ever-changing environment, optimize and automate as much as possible and bring in decentralized command. Now, to benchmark all of this and to know that it's actually working, we love metrics and I think metrics is how you want to do that. So the enablers are the five distinct things I just talked about. Focus, predictability, pace, automation and decisioning.

However, there are a myriad of metrics, which I'm sure we can do a whole other talk on that can help you benchmark your teams. So for example, if you have two teams working in your organization, working on either different tracks of the same product or different products at all, a sure-fire way of knowing which team is 'faster' is by first of all, looking at the results they're creating but second looking at the different pieces that they use to get to those results. This is a sure-fire way of defining fast for your team and also understanding what your team is doing.

One thing that I want you to take away from this talk today is to please not use velocity as a key metric for speed. Do not use velocity as a key metric for defining fast. Velocity is a metric and like every other metric can be manipulated. So please, if nothing else do not use velocity for this. So in closing, I want to basically set it up fast is a sum of all the parts. I've used F1, hopefully that has resonated with you. Fast is not only having strong team but having that partnership to work dynamically. Your team needs to be adaptable, your team needs to be focused. The point behind being fast is to deliver results and ultimately that's why we're here. I hope that this talk has been useful to you. I hope that this talk has given you a different frame of mind when it comes to thinking about fast. I hope that we now frame fast as more and more as an enabler towards the result. And I hope that when you go into your next meeting, velocity is not what everyone focuses on.

Before I go, I want to quickly talk about ... we'll be doing this all over again a month from today, on October 23rd, Devbridge Co-founder and President Aurimas, will be doing a talk on risk management techniques for product managers. So mark your calendars, it will be around the same time, we would love if you join us then. I really want to thank all of you for joining me and indulging me through this analogy of Formula One. I was really excited when I got the task to talk about speed and fast because I actually got to talk about F1 for once at work. So thank you again for hanging with me. I hope you have a good Friday and a good rest of your weekend. Cheers.

About the event:

Full Stack Friday: Understanding speed for product delivery teams

Full Stack Friday is a monthly meet up hosted by Devbridge where we share insights on product development, design, and process. The talks focus on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.

Aurimas Adomavicius

24 June 2021 | ProductCon 2021

Data Democratization: Making data available & understandable across the organization