How To Speed Your Team Up (By Slowing Them Down)
How To Speed Your Team Up (By Slowing Them Down)
How to control development velocity within your team by decreasing the cycle time and WIP for new features or products.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
As a Silicon Valley product manager, I was told nearly every day that my team wasn’t delivering fast enough. My response to the pressure was to ask them to cut corners on quality, work longer hours, or just try to work “faster” — meaning more frantically, I suppose.
The result? A steady stream of low quality features and unstable code — which slowed us down further by creating system outages and integration problems each time we shipped. This, of course, led to unhappy customers, team members, and executives.
We gave up our quality of life to create products our customer didn’t like and the sales team couldn’t sell, all while making our own jobs more difficult. Eventually, I realized that what we were doing to speed up wasn’t working, and if we were going to survive as a team and business we’d need to find another way.
Cutting quality, feeling frantic, and working long hours are not the keys to speed, but they are the keys to personal misery, crappy products, and team attrition.
I’d like for you to learn from my mistakes, so you can avoid making them yourself. It’s remarkably easy to to influence your team’s productivity, but not by blindly applying a process. Once you understand the principles of speed you’ll begin to see opportunities everywhere.
What is Speed?
If you look around, you’ll notice that the most productive people are almost always the most deliberate and calm. This is not a coincidence.
Your team can move faster, but only as a result of conscious engineering, and you have to be willing to do the work. Maximum speed and productivity can be achieved, but only through awareness, applied smarts, and disciplined process.
It may seem counterintuitive, but to speed up, the first thing you have to do is slow down and learn what speed is.
Speed is not just one thing, it’s actually made up of two conjoined elements: throughput and cycle time.
These elements of speed hold true whether we’re talking about a team building a product, you cleaning the house, or wildebeests migrating across the Serengeti.
- Throughput is how much work you are able to do in any given time period, and
- Cycle Time is how much time it takes to complete any single item of work.
You can optimize both, but not before you understand them. If you’re not careful, improving one element can create unwelcome side-effects, often damaging the other.
Confused? OK, let’s break each down.
Imagine a stretch of highway. The throughput for this piece of road is the total number of cars that go from beginning to end in a given time period.
Maximum throughput is the largest number of cars this stretch of highway is capable of handling. In order to measure it we need a time element, so our metric becomes something like cars per hour.
We are also bound by safety concerns, not just out of a sense of humanity, but also practicality. If we speed things up too much we’ll create accidents and inevitable traffic jams. Trying to make the cars go faster will not only scare and injure people, it will also cause the entire system to break down and lower throughput.
Software teams operate in a similar way. They are able to process a certain amount of work safely — meaning at an acceptable level of quality. But cutting corners inevitably introduces errors that cause the whole system slow down or even crash.
Unfortunately, “normal” for most teams means a frantic effort writing substandard code, which creates crashes, which in turn creates more time pressure and more frantic effort. If this describes your team, you’re not alone, but it’s also a clear sign you need to slow down and figure out a new way of doing things.
Like Tiger Woods having a slump year when he made changes to his swing, this will impact your team’s performance in the short term, but dramatically improve things in the long term. Unlike Woods, you can re-engineer things in a couple of months and experience the payoff this quarter.
I’ll cover how to do this in a minute, but first let’s talk about cycle time.
You may be getting a lot of “stuff” done — e.g. your throughput is through the roof. However, you have to put yourself in the place of the individual customer and consider his or her wait time, which corresponds to your cycle time.
Cycle time is a measure of how quickly something you say you are going to do actually get’s done. Another way to think about it is how responsive your team is to requests or how long your “line” is.
To visualize cycle time, it’s helpful to imagine the line at a coffee shop. Cycle Time is the average amount of time it takes a customer entering the coffee shop to get their beverage.
If the wait is too long, then customer experience is bad–no matter how good the coffee is or how many drinks the barista is making. Maximizing quality and throughput has no real impact on the performance of the shop, as long as cycle time continues to be too long.
In software development, you can think of each feature request as a person in line. It may be some combination of customer, salesperson, and stakeholder, but someone is definitely waiting for you to finish something.
Short cycle time is especially important if you’re taking a test-and-learn approach to development, which you really should be. To make a lean approach like this work, your team needs to be able to respond to customer insights easily and without drama — e.g. short cycle time.
Speeding Things Up
Now that you have a solid grasp of the two elements of speed, let’s talk about how to make things better. And yes, it’s all about slowing down.
The good news is that there are only a few ways to impact throughput and cycle time. By encouraging your team to change some of their habits, you can start increasing your speed and improving your customers’ experience.
Limit WIP to Increase Throughput
When you’re trying to improve overall throughput on a highway, the most effective thing you can do is limit the number of cars on it. This avoids traffic jams and accidents, which are the main causes of slow downs. Such slowdowns are the reason no one wants to drive on a road that looks like this.
Drivers want to move fast and so does your team. You may think they don’t, but everything we know about human motivation says otherwise. People want to do good work. What we need to do is enable them to actually do it.
Too many cars on a highway overloads the physical roadway, and too many jobs in flight will overload your team’s cognitive ability. I’m not being mean here.
We all wake up in the morning with a limited amount of brainpower and need to be very conscious about how we apply it. This is one reason high-performers often wear the same thing each day. It decreases their need to make decisions and push a new “car” onto their mental highway.
If a team is working on too many things at once, they’ll have to keep track of too many details, and inevitably some will fall through the cracks. This can be fatal for software.
Not only that, but switching between items has a cost — you have to re-find your place in a project, remind yourself of what you were doing, and get started again each time you switch. We call this switching cost, and just like in-app purchases in freemium games, it adds up quickly. For someone writing complex code, staying focused on a single problem until it’s complete is a huge time saver.
The secret to maximizing throughput for your team is to limit the number of things they are working on at any given time. We call this limiting Work in Process (WIP).
To limit WIP, you need to:
- Decide what the limit is,
- Put a gate at the beginning of the pipeline and a sensor at the end, and
- Only let a new item into the pipeline when an old one has left it.
This creates a self-regulating system. For software teams, the only people with enough information to limit WIP effectively are on the team itself. This means they need to be able to say “no” loudly, definitively, and regularly. More on this in a minute.
Shorten Queues to Decrease Cycle Time
At our coffee shop, if we want to shorten the average wait time, we could ask the barista to work faster, but this will lower quality and probably increase barista turnover. This means our only real option is to somehow make the line shorter.
Lean theory tells us there are only two things we can do to shorten a line. We can add capacity to the system and split the line in two (adding another barista for instance), or we can keep people out of the line in the first place.
For software teams, this presents a problem. Adding capacity is expensive and difficult. Hiring more people for a project will increase your run rate, and it will add to the complexity of your team.
Big teams by necessity have complicated communication patterns. A team of more than ten people tends to move slower than one with fewer. Also, new members need to be brought up to speed, which often slows things down further [see Brooks’ Law]. So, while we could consider adding capacity, the easiest and most effective move is to keep items out of the line — i.e. off your backlog — in the first place.
At a coffee shop, our line is kept short organically, as each person coming into the shop decides for themselves whether it’s worth sticking around or not. A software team needs to consciously make the same assessment each time they commit to something. Essentially asking: “Is working on this item the most valuable thing we can do with our time?”
This value assessment is best made as close to the moment you start working on the item. The longer you wait to commit to something, the better your information will be.
Once again, this is about the team saying “no” or “not yet” effectively. That said, the team should also take external needs like conventions, analyst reports, and market windows into account, and may also need to call their shots further in advance than they are comfortable with.
It’s ultimately up to the team lead to give their team members the necessary encouragement and latitude to create limits that will shorten queues.
Making Speed a Habit
There are many processes and tools — like a value-based backlog, relative economic prioritization, team retrospectives, and cadenced recursive planning — that will help your teams Limit WIP and keep their queues short. But all of these will be only marginally effective without the most important tools: empowerment and trust.
As a leader, I had to learn the hard way that my teams really wanted to do a great job and that they often knew way more about what we were building than I did. Famed management theorist Peter Drucker noted 20 years ago that a knowledge worker was someone who knew more about their job than their boss did.
The essential element I needed to learn — and I hope you do too — is that for my team to do the best and fastest work possible I needed to build a process that allowed us to trust each other. My team needed to trust my ability to make decisions and stick to them, and I needed to trust my team’s ability to deliver. I needed to do this even when they hadn’t yet “proved” themselves to me.
This meant creating small teams of talented people and giving them clear direction about the purpose and goals of the project and then getting out of their way.
This was, and continues to be, a difficult learning process for me. I needed to get better at making decisions and prioritizing work. This, in turn, meant I needed to learn how to keep my attention focused on customer needs, not my own personal opinions and agenda.
What You Can Do
There are a few specific things you can implement that will help create an environment where you can trust your team and help them trust you. Blind faith, after all, is not empowerment, but a recipe for disaster.
You and your team need a way to view your product in terms of customer value. Most companies state the broad intent of their product and then too-quickly break this down into minute technical and functional details.
What’s needed, and often missing, is an interstitial layer that allows technical and non-technical people to speak the same language when talking about what specific capabilities will be added to the product.
It doesn’t matter whether you call this your agile backlog or requirements stack. What does matter is that it be in a language your user understands and that it’s broken into very small chunks — that should take no longer than a couple of weeks to develop — which can be grouped (or rolled up) into larger features.
Cadenced Face-to-Face Planning
A cadence is a balanced and rhythmic flow, and that’s the way we need to think of our planning. We don’t do it only when we “need” to, we build it into the fabric of our team.
This is important because finding the right product strategy isn’t like punching an address into google and blindly following directions. It’s more like backcountry four wheeling without a map. You need to be able to course-correct very regularly — in fact, course correction needs to be a habit.
A combined technical and business team should meet at regular intervals to get situational awareness of the project and plan immediate next steps.
If, like ours, your teams are small, have worked together a long time, and are very experienced, you can handle much of this organically. But for troubled teams who are trying to improve, I recommend committing to a specific set of meetings until this kind of fluid communication becomes reflexive. Here’s the minimum viable set:
- Daily Standup
- Weekly Tactical
- Quarterly Release Planning
- Yearly Roadmapping
You can give a team true autonomy only when you all are clear on the guardrails they operate inside of. Cadenced planning allows for a regular syncing up, but it’s also helpful for the team to have a clear sense of what they are accountable for and where their autonomy and authority ends.
These accountabilities should be kept in a living document that’s reviewed regularly — hopefully in the regular retrospective meetings that precede Quarterly Release Planning and Yearly Roadmapping.
Decision Making Process
If a team is to be collectively accountable, then that means they’ll be making decisions together, as a community. Without a clear process, they’ll get mired down. I recommend Holacracy’s Integrative Decision Making, but there are others to choose from.
Teams that know each other and care about each other are better communicators and are faster and more effective at their work. It’s helpful to instill opportunities for people to get to know and like each other on a personal level. This can be as simple as sharing a meal or as complicated as an off-site “team building” trip. This is especially important if teams are diverse, gender balanced and cross cultural, and/or working remotely.
Learning to trust also required that I learn internal discipline. I had to trust our process and our ability to solve problems, and this meant quieting my fearful mind and increasing my own focus. Diet, exercise, meditation, and conscious unplugging all help with this.
Speed is Not a Number
I know my team is motivated, but it’s only when my team is engaged and empowered are they able to focus on a few high-value items at once and deliver them quickly.
Maximize throughput and minimize cycle time. Working with an empowered team is an ongoing, nuanced conversation, not a series of commands.
As for my team in the valley? We put together a pretty effective planning and delivery pipeline. We became more creative, more friendly with each other, and more productive.
Our product went on to do pretty well, too.
Published at DZone with permission of Bob Gower , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.