A Journey of 1000 Miles is Still 1000 Miles Long

ConfuciusIt’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. Continue reading

Magical Thinking and the Zero-Sum Roadmap

Recent conversations at several clients highlight an often-repeated set of magical pull rabbit from hatthinking: beliefs by internal clients that development resources are infinite, and beliefs by product managers that prioritization can convince anyone otherwise.  Both are wrong, but seductive.  Here goes…

The starting point for this conversation is the typical product roadmap: crammed full of prioritized work and heavily negotiated with the development team.  Almost every optional item has been postponed, and there’s still some risk of delay.  This is a product plan with no “white space,” no large chunks of unallocated engineering capacity, no slop or slush funds or hidden treasure. Continue reading

Review: “Adapting Configuration Management for Agile Teams”

I’ve had the chance to read an early version of Mario Moreira’s new book, “Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed.”  Mario is a long-time champion of software configuration management (SCM), agile development models and IT governance. Continue reading

Mo’ Beta

At some time in every product cycle, the executive team wants to help product management “improve” its customer beta process.*  This is generally because the last beta took too long, didn’t get enough useful customer feedback, or failed to prime the revenue pump for a post-GA sales blitz.  Notice that these three goals are mutually exclusive…

One way out of the beta dilemma is to recognize the different audiences and objectives for a beta cycle, then structure different programs for each.  Here, I’ve sorted beta prospects into three camps: the Loyal Opposition, the Overcommitted, and the Reluctant Volunteers. Continue reading