Q and A on Velocity, part X

In the last installment we talked about communication between managers and employees, efficiency notions, and other key continuous improvement ideas.

This installment let's pick up on the idea of doing great work quickly.

A: You have said several times that something has to change for work to be done faster. Skills and stuff to make the work easier. Is that the right way?
B: If and only if the bottleneck is actually in development, it will help.

There is some good material here from A. In fact, skills and tools and knowledge can make the work progress faster. A developer with deep knowledge of their tools and stack can get work done in a tiny fraction of the time it takes a less knowledgable developer to figure out how to get a result.

This is often misinterpreted as "a 10x developer" but really it's a 1x developer surrounded by other 1x people who just don't know the stack, the code base, or the tools as well. If you like a 10x devs, invest in helping them learn to go faster. This is expressed in Modern Agile as "Make People Awesome", and in the Agile Manifesto as "give them the environment and support they need."

But let's move on...

A: Okay, then. Let's assume the bottleneck is development. What do we change?
B: Whatever makes it difficult or risky to delivery working code now.
A: How do we know what that is, or what to do instead?
B: Experiment. Some changes help, some not.

Since I've started this blog series, I have had a series of workshops where I ask the team "what makes you go slow?" It really isn't a difficult question to ask. In the right (blameless) environment, teams are happy to tell you where the problems are.

Most of the time, teams don't know how to fix the problems, or they don't know how to acquire the time and support they need (see Agile Manifesto principles, again) to solve the problem so that they can go fast. Here a manager can make a real difference.

Supporting experiments and other efforts to relieve bottlenecks isn't just good agile practice, or good empiricism, or good Modern Agile ("experiment and learn rapidly"), it's good management and good business. Leaving people stuck with drag-inducing problems while exhorting them to move faster isn't good form. Better to be effective, right?

A: We can't afford to do that. I told you our schedule is tight. Can we only do things that work and not waste time?
B: If you can't afford to experiment & learn, you can't improve. Do the best you can with the velocity you have. Order work by value. Descope.

If we can't afford to learn and experiment, then we can't afford to go faster. Full stop.

Is it okay to be seen learning and trying things at work? What happens if you try something and it doesn't work? How does that line up on the annual review?

We hope an experimental and informative, mindful approach to software development is seen as a positive by the organization. It has happened, though, that speed is rewarded and knowledge is rewarded, but no concession is made to the acquisition of speed and knowledge. This makes retaining motivated people very difficult.

A: We can't descope. We can't miss the date. We can't experiment. What else do you have?
B: Fail as well as you can. Give the best result you possibly can, considering that you'll fail.

We have referred to "the best possible failure" as a goal for timeboxed work. We slice work into pieces and then slice the slices. We find that if we can put a bunch of little slices into the timebox, ordered by importance/priority, then when time runs out and we're not fully finished we will have the most important work finished and integrated.

The worst failure is to have 100% of the work 90% done. Nothing is deliverable or useful. It's a mess.

To have 90% of the work 100% done is a qualified success. It's not 100% successful, but that 90% functionality is usable, functional, demonstrable, sellable. It may not satisfy everyone, but it can help some people. It gives partial value, and that's a damned sight better than zero value.

If you can't go faster, then make the best of the speed you have. Fail as well as possible.

A: Is that all?
B: No. Remember development may not be the bottleneck.

Organizations are shocked and upset to find that their 45-days-to-market lead time can't be improved (much) by speeding up programming because programming isn't the primary consumer of time in their case. 

In some cases halving coding time, if even possible, would produce results in 44 days instead of 45.
Software work spends most of its time waiting in queues. 

• Approval queues. 
• Prioritization queues.
• Review queues. 
• Waiting for other work to finish first. 
• Waiting for testing. 
• Waiting to be repaired. 
• Waiting until the current production crisis is over. 
• Waiting for an expert to answer a question or become available to consult on it. 

And it's worse than it sounds because these queues are wrapped in loops. 

1. Code waits for the programmer to be available, b/c they're busy on something else
2. Programmers work on the code
3. The code waits for a code review, b/c the reviewers are busy 
4. If the code review sends the code back to the programmer for changes, goto 1
5. The code waits for a testing build on an official testing server, b/c servers are busy.
6. The code waits for a tester to be available, b/c testers are busy.
7. The tester waits for the code to be built and installed on an official testing server because the server has just been made available to the freshly-available tester and has to be prepared.
8. The testers test the code.
9. If any anomalies or improvements are noted, goto 1
10. Code waits in a batch with other code to be deployed.
11. If there is a problem with deployment, goto 1 for troubleshooting and remediation.

What if a change cycles at 4, then 9, then 4 again, then 9 again, then 9 one more time?  How long are these waits? 

If, as is often the case, 95+% of the time is waiting then programming twice as fast may yield you a 2.5% improvement in time-to-market. Whee. Not very impressive is it?

But if this is your situation, then it is very good news. 

You don't have to be a technical genius to fix human waits and queues. It only takes someone with some managerial chops and some systems thinking. 

You can do it. You can make the BIG difference in time to market.

You can give your staff the environment and support they need. Is it training? Information? Thought leadership? Faster computers? Learning to prevent defects? Learning to use their programming stack more effectively? Eliminating silos (working together with people rather than queuing)? 

You can change the system. You're a manager. You have skills and latitude.

Isn't that good news?