Why Your New Development Methodology Didn’t Fix All of Your Problems

By Rich Mironov November 21, 2012

It’s very easy to confuse actual progress with intentions to make progress.

Why point out the obvious? I’ve had too many Agile conversations where executives 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.”

The Chinese philosopher Lao Tzu is credited with saying: “A journey of a thousand miles begins with a single step.” But that journey is still a thousand miles long—and even at twice your normal walking speed, be prepared for a very long slog.

Nearly every software development team would like to be more productive, ship better products and be innovative. Almost by definition, though, those with the biggest productivity issues are the furthest behind—with months (even years) of unmet customer requirements and technical debt, along with shovels full of postponed promises piled in a heap. Calls for better development processes at that point are usually in the context of big, ugly backlogs and long-suffering customers.

Here are the unstated questions in those meetings: 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 or a mulligan. Surely an outside expert or shiny new process will instantly catch us up.

So What Do We Do Now?

Let’s say you’re on a software team that sporadically ships products, 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.

Basically, you should find some improvements that you can make now and establish a trend. You might try some combination of these to do one small thing right:

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 more 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.

Ruthlessly prioritize. There are years of backlogs to address. But our newly hopeful development team can still only handle a few items at a time. Make sure that the next handful of small improvements is 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 executives and internal stakeholders. 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 and divert attention from yourself.

Most long-term issues are solved with incremental changes like these, not through one big fix.

And wear comfortable shoes. There’s a lot of walking to do. Because as another Chinese philosopher, Confucius, said: “No matter where you go, there you are.”

Rich Mironov

Rich Mironov

Rich Mironov is a seasoned software executive and serial entrepreneur. He has been the "product guy" at six tech startups including as CEO and vice president of marketing/products. He has also consulted to dozens of technology companies.

Rich founded the first ProductCamp and chaired the first product manager/product owner tracks at the Agile Alliance’s annual conference. He is the author of "The Art of Product Management" (BookSurge Publishing, 2008), which collects the best of his long-running Product Bytes blog about software, start-ups, product strategies and Silicon Valley product management.  Rich has a bachelor’s degree in physics from Yale (with a thesis on dinosaur extinction theories), an MBA from Stanford, and provides guest lectures at various business schools about the business of software. He can be reached at rich@mironov.com.

Looking for the latest in product and data science? Get our articles, webinars and podcasts.