A Journey of 1000 Miles is Still 1000 Miles Long [Rich Mironov]

It's easy to confuse actual progress with intentions to make progress.

Why point out the obvious? I've just come out of another agile conversation where prospective clients confused "we want to build better software faster" with "we hope that some new processes will instantly catch us up on years of slipped deadlines and missing features."

So paraphrasing Confucius, "A journey of a thousand miles begins with a single step, but is still a thousand miles long. Even at twice your normal walking speed, be prepared for a very long slog."

For context, nearly every software development team would like to be more productive, ship better product, and be innovative. Almost by definition, though, those with the biggest productivity issues are the furthest behind - with months (years) of unmet customer requirements and technical debt. Shovelfuls of postponed promises piled in a heap. Which means that calls for better development processes are usually in the context of big, ugly backlogs and long-suffering customers.

So the unstated question in these meetings is "how do we catch up to where we were already supposed to be? Can a better process (in the future) also erase our previous shortfalls?" Stated that baldly, it seems naive. Yet the emotional logic is very real. Everyone wants a fresh start, a reset, a mulligan. Surely an outside expert or shiny new process will catch us up. Or not.

So What Do We Do Now?

Consider a hypothetical software team that sporadically ships product, has run up a stack of technical debts, missed some customer commitments, and needs a series of process improvements. Business needs are pressing, so there's no option to halt development for a radical retooling.

You might try some combination of these:

Pick one small thing as a demonstration, and make it successful. For example, if we're having trouble planning and estimating, then identify one very small project for careful planning and estimation. Focus the team on completing just that - mostly on time and reasonably on spec. This becomes our existence proof for improvement: having done a better job once on something small, we can do it again. (After all, a journey of a thousand miles...)

Ruthlessly prioritize. There are years of backlogs to address, and our newly hopeful development team can still only handle a few items at a time. Make sure that the next handful of small improvements are truly the most important. For everything else, 'nice to have' translates to 'not this year.'

Don't confuse small with big. As soon as a few tiny things start arriving on schedule, internal stakeholders will be lobbying for massive overhauls. ("If the engineering team can rewrite a report in a week, can't they re-architect all of our business processes in a month?")

Be transparent. Explain your 'do one small thing right' strategy to all internal stakeholders. (To be fashionable, you can call it 'agile.') Remind everyone that we still have 998 miles to go, but we're picking up the pace.

Share small improvements with customers. They are likely to be hungry for any good news, and eager for you to succeed. Gather some applause for your team. Customers don't really expect you to fix everything at once, but need some sense of progress.

Do your math. If we have two years of backlogs to work through, and we double our development speed, then it may take a year to catch up. Avoid magical thinking.

Celebrate the positive. Regardless of the starting point, your teams need a sense of progress and optimism. Highlight small triumphs, applaud people who are doing the right things, divert attention from yourself.

And wear comfortable shoes. There's a lot of walking to do. Because Confucius also said that "no matter where you go, there you are.

SoundByte

Find some improvements that you can make now, and establish a trend. Most long-term issues are solved with incremental changes and successes, not through one big fix.

Crossposted at http://www.mironov.com/1000miles/

Rich Mironov is a serial entrepreneur, product management thought leader, and agile “product guy.” He’s the author of The Art of Product Management, and writes about software, startups, organizations and technology customers at www.mironov.com .