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 teams 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.   Shovelsful 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.”

SoundBytes

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.

Full disclaimer: VersionOne has been a client of Enthiosys. We’ve helped them prioritize their product backlog with Innovation Games® online. Several VersionOne employees are trained Innovation Games® facilitators. And, VersionOne employees have also attended a variety of classes I’ve taught in my role as a Strategic Advisor on Product Management and Strategy for OpenView Partners.

More importantly, I appreciated exploring Bob’s vision for how this offering will evolve. Like all good product managers,  Bob has some excellent ideas on how to extend the initial version. His vision is compelling, and I was able to directly advocate for many of the more advanced roadmapping techniques that we use with our clients, including radar roadmaps and variable time scales. Bob absorbed all of this.

I am encouraged by what I saw and am looking forward to seeing how their offering will evolve.

Recent conversations at several clients highlight an often-repeated set of magical thinking: 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.

That gives us Mironov’s Roadmap Theorem #1: you can’t put something new into the current development plan without taking out something of equal or larger size. When stated this plainly, it should be as obvious as the law of gravity.  Hand slapped against forehead.  Doh!

(Agile translation: this backlog is very deep, already prioritized, and all of the upcoming iterations are strategic.  New items can’t jump to the top without pushing something down that’s more critical.)

But internal customers (Marketing, Sales, Support, Channels, executive staff) always approach this with some form of disbelief or negotiating position or magical thinking: that 10 pounds of development can fit into a 5 pound iteration.  I’ve heard all of these in the last week:

• “But it’s really important.”
• “We already promised it to a customer. (Oops)”
• “We’ve been talking about this for more than a year (so we must have assigned resources to get it done).”
• “Engineering should be more productive.”
• “We’ve gone agile (which should give us infinite capacity).
• “Your priorities must be wrong.”
• “How hard could it be?  A tiny fix, a few lines of code.”
• “It’s small enough to fit into one iteration.”
• “I’m sure your boss agrees how important this is.”

All of these are valid in an emotional sense.  Many represent good negotiating positions, assuming that product management is hiding extra engineering capacity under a basket somewhere.  That we assign resources based on the most incentive requests.   That “asking” immediately translates into “getting.”  That a convincing argument creates technical resources.

Would that it were so.  See theorem #1 above, though.  Product managers know that the list of demands is infinite, and the vast majority will never be addressed.

Here are two kinds of product management responses:

[1] Soft-pedaling the actual situation, avoiding conflict by being polite.

We often respond to requests with coded language, mush and euphemisms.  Instead of clear communication (“there’s no way this will get done in 2010” or “we have decent work-arounds” or “that channel partner doesn’t rate special treatment”), we waffle with:

• “I need to prioritize that against the plan (and hope you forget it later)”
• “Let me run that past engineering (who will tell me it’s huge)”
• “It’s in the backlog (which will take decades to work through)”

FYI, our internal counterparts are smart.   They quickly figure out if our kissy noises are just air, or if we really mean what we say.

Another approach…

[2] We keep some overflow engineering capacity for emergencies.

This looks like a better approach, since surprises and disasters always appear.  We can secretly conspire with development managers to pad schedules, or explicitly set aside 10-15% of engineering time for unplanned items.  Seems only prudent.

Which brings us to Mironov’s Roadmap Theorem #2: Everyone will find out about your emergency capacity. There are no secrets.  In practice, that means all of the above arguments are suddenly very valid.  Every sales rep has a strategic account, every unauthorized commitment must be met, and every channel partner has special needs.   This puts product managers squarely back into the political process: deciding which arguments rate serious consideration.

Emergency set-asides have the potential to derail your entire product planning process.  As “specials” and “one-offs” consume more and more engineering resources, your long-term projects get less attention.  (Don’t ever go above 20%.)  Your constituents may decide that emergency requests are the only route to satisfaction.  If that happens, your roadmap becomes a quarterly CYA exercise.

Sound Bytes

Our internal customers are not interested in why their requests are low-priority, only in how they can get things addressed sooner.  Clear communication about what’s really important, together with solid roadmaps and carefully managed overflow capacity, can ease the pain a little.

Jason Tanner, Enthiosys President, will be teaching a two-day course, “Innovation Games for Agile Teams: Serious Games for Market Research and Collaboration” at the Øredev Developer Conference in Malmö, Sweden this coming November. This interactive course outlines how Innovation Games can be used to enliven and improve many agile practices, such as retrospective, eliciting customer requirements, developing better release plans and more.

For more information on the Øredev conference’s complete program and to register, got to www.oredev.org.

Continuing a discussion that was raised in Tom Grant’s recent conference call with Saeed Khan, they (we) made a distinction between metrics about products that Product Managers use to monitor the world, and metrics about Product Managers for promotions and salary reviews.  Some additional thoughts of mine, along with a lightweight PM assessment tool…

Metrics About Products

For the most part, metrics track the health of products*.  We should be constantly monitoring things like:

• unit sales versus forecast
• average discount from list
• win/loss, close rates, or the portion of bids that result in sales
• customer complaints, support cases or bug counts
• actual development progress versus roadmaps or release plans

Etc.  There are, of course, dozens (hundreds) of possible metrics to choose from.  Importantly, these may indicate possible problems – but RARELY identify root causes or specific market change.  Standard metrics give us a starting point for more questions. “What might be driving customers from the high end to our mid-tier product?”  “Why is Europe reporting more installation problems?”

We (product managers) act as clinicians: interpreting the data and digging for real-world reasons why discounts have increased, or why the product mix has shifted, or why sales to retirement communities are suddenly accelerating.  The “why” that we derive from product metrics is a combination of clever investigation, good field relationships, experience, and dumb luck.

• Chase: X-rays confirm the fluid that almost suffocated her to death was from pulmonary edema.
• Foreman: Means the problem’s either in her heart or lungs.
• Thirteen: Tox screen’s clean for everything except the alcohol, and her B.A.C. was barely .05
• Chase: That means she only had one or two drinks, tops.
• House: And there’s no sign of trauma.
• Chase: How’d you know?
• House: Because if there was, Cuddy wouldn’t have needed me to take the case…