1,000% improvement is a statistical outlier

Share

This cautionary tale came up a few times at Agile 2010 (yes I know this may be old news!) – including one of the keynote speeches.

“For a million dollars we’ll make you Agile.

Here’s a list of previous clients whom we helped achieve a 1,000% performance improvement. Lead times halved, profits doubled and everyone was AWESOME!.

Here’s some REAL DATA …”

A graph going "up and to the right"

Axis titles shamelessly acquired from a recent company presentation

What you’ve not been told is that those testimonies are statistical outliers!

These are the top 1-5% of companies that have successfully undergone a major transformation. (or the bar was set very low to start with) There are thousands of companies out there that don’t reach these lofty heights.

The journey is longer and harder than the marketing will ever tell you but that’s fine as long as you know what you’re investing in and why.

Your organization is unique. There are many factors about your organization that will make significant improvements hard to achieve and most of them will not be technical. The forces of resistance will be many and will be a mix of institutionalized and personal.

Let’s replay this with a more realistic conversation…

A consultant visits your site, and does a “free” one-day Agile Assessment of your teams.

“OK Boss. Right now you suck at developing software. Give us a million dollars, a year of your time and a willingness to drop productivity for a while and we can make you suck a bit less.”

Furthermore, they won’t actually be able to tell you just how much less you can suck and by when.

Why not?

Back to all those forces of resistance – how many of those can you really prod, assess and quantify in a day or even a week?

Every company, organization and site differs.

The investment may still be worthwhile but it’s time to manage expectations better. Those assessments should highlight where unexpected limitations lie. Maybe they could offer alternative higher priority areas to tackle (rather than up-selling scope).

If product development and software engineering was like cutting coke cans, there really would be a “one true right way” of producing software products.

Moreover. There wouldn’t be a thousand consultancies promising you the moon on a stick, there wouldn’t be conferences on improving the state of the art and there wouldn’t be hundreds of books full of great ideas on how to do/be agile or perform software engineering a little bit better.

In fact chances are there wouldn’t be a competitive software industry.

Or would there?

• Maybe there really is a one true way and the entire software, consulting, authoring and conference industry is in on the joke.

• Maybe all those leading lights on their skiing trip a decade ago came up with one of the world’s greatest “Long Cons”

• Oh and they invited 3M to the party and agreed to promote stickies in the 21st century in exchange for a marketing budget.

Probably not…

There are no “best practices”. Stop looking for them, stop asking consultants and Scrum Masters to implement them.

There are only “best known practices for your current state, knowledge and context”.

When your state, knowledge and context change, it’s time to look at what’s next and more importantly – what’s beyond your current focus – what have you missed or not considered yet?

What did you discard previously because there were constraints or issues preventing them working? (I learned a great term for this from Chris Matts &/or Dan North – I can’t remember which – “Idea Wombling” – seeking out great ideas that were previously discarded)

You may reach a point where your organizational immune system (politics and process) blocks progress.

Sometimes you’ll need outside help to see what’s “better” or learn new ways of working. That outside help can often be more effective at delivering hard truths than you can yourself. It’s worth investing in “straight-talk” from strangers sometimes.

Figure out what is holding larger improvements back (and where) and determine who you could pair with either externally or in a different part of the organization to make a real difference!

Manage Your Product Portfolio Like an Investor

Share

A bit of a ramble on portfolios.

Every time I return to the draft of this post I tweak, rewrite, remove and add. Today I decided it’s better to ship “good enough” and move my investment elsewhere. I hope this still delivers enough value to you as readers…

Even with a good investment, wouldn’t you want to increase your chances of success?

I’ve been involved in annual and bi-annual portfolio reviews of varying quality over the last 7 years and been in the fortunate position to change and improve how many of those have run. With every review I think about how we can do a better and quicker job.

If your portfolio is anything like those I’ve seen in both my current and last employer you’ll have a mix of “no-brainers” and speculative work. Often those are run through the same process with mixed results. You may even have the luxury of standing teams from some areas.

When a project or bid reaches review, on the surface it’s in the proposer’s personal interest to minimize the level of scrutiny their plans receive. They’re busy trying to deliver a business and want to get their project moving fast.

I regularly see plans proposed at portfolio review that magically change within 2 weeks of starting and again within a single quarter. I’ve even seen plans delivered “late” and miss large parts of a review cycle and yet still be approved.

A cynic might say that the owner has secured their funding, now they’re free to change! Less cynically, this is simply what happens when early-stage plans and new projects hit reality. With the review cycle over the same apparent due diligence no longer comes into play.

With peer reviews of code, good reviewers are well-practised in what to look for and may even have checklists and standards. What tools, checks and support do reviewers of your portfolio have? Do they really work?

I frequently see other portfolio “smells” too.

  • Where a project is a continued investment in an area already in progress, these are often a shoe-in for the next cycle. This can turn into sunk cost behaviours.
  • If a project is recently started, we may simply assume that because the project is only just under way that we need to “leave it alone” and that it may be unfair to re-scrutinize a business case and plan.
  • Large revenue increases are predicted against short time scales on the promise of a new release. The time for these increases to actually occur is much longer. Furthermore, these are usually single-point commitments without agreed tolerances or ranges.

I’ve had the luxury in the last couple of years of being in a company that has a track record of actually shutting down projects early (occasionally not early enough) when claimed benefits fail to materialize or overruns occur, Yet even when those projects were set up, bold forecasts were made and operating tolerances against those forecasts were not negotiated.

I’m torn. Proper due diligence on all investment decisions seems obviously right but the case for funding a standing team to continue driving a nascent or even successful product forward is strong. As my CEO said to me recently – “It’s very hard to resist the man with the plan”.

The “VC” Investment Philosophy

Consider your product development organization as a Venture Capital company.

Every year you review funding and invest in a variety of options. Like VC, a smart portfolio and balance of risk/reward is important. You make some investments to sustain cash flow, some for organic returns and you hope to find the occasional (and mythical) “hockey stick” growth curve.

Balanced risks and a mix of investment durations is needed for a sustainable business and a regular review of those decisions is vital to your operating health. You may choose a multi-year investment in a loss-making area believing it’ll come good in future or drive sales for other products.  A year later the climate may have changed or the market may not have materialized. Do you kill the investment or ride it out? You can’t answer this question without understanding the context of the rest of your portfolio.

If it were lightweight enough and delivered better decision-making, I assert you’d want to your review your investment much more frequently. In my simplistic view of the world it’s like the different between a basic index tracker and the increased cost (for potential better return) of buying into a managed fund.

So.

Treat your portfolio like a VC investor, consider taking every new product release (including new releases of existing products) like you’re going back to the dragon’s den to bid for another round of funding.

Don’t commit all your capital on an annual basis unless there is a truly sound reason to do so. Seed your investments with an option to increase investment in future or kill it early if it no longer looks valuable in your portfolio  (Real Options anyone?)

Picture this rather extreme “Dilbert” conversation…

- I want to improve my existing product, can I have some money to take these improvements to market?
– Sure what’s your business case
– Well the product is already in the market and profitable, I don’t know who all my customers are but I have lots –

 

I can’t tell you exactly which of my products is bringing the money in because we package it all up together under a single product line but all those existing customers give me support money every year.

 

They raise enhancement requests that they never expect to get fixed because we take so long to deliver and all new features we deliver are never on their version anyway.

 

Most of them don’t have any immediate plans to upgrade so basically we’re making millions from fixing defects and taking support calls. But I’ll make you a personal commitment to 1000 new customers as long as I can get every “must have” feature in the backlog implemented in a year.

 

And if I don’t meet my numbers it’s because we didn’t get all the features implemented
– Ok, I’m feeling flush and can’t be bothered to visit the race track this week – here’s a year’s funding,  I’ll see you in a year.

Let’s try again on some sounder (but still not perfect) footing…

- I want to improve my existing product, can I have some money to take these improvements to market?
– Sure what’s your business case
– Well, we have 200 customers on out of date releases. They have no immediate incentive to upgrade as what they have meets their needs but upcoming regulatory requirements plus opportunities in their markets mean that they will need to change and add the following 10 business processes.

 

Right now these are manual or slow and cost them on average $1M with a 3 month cycle time.

In order to take a viable upgrade to market we need to show a return on investment to our existing install base.

 

We believe with the right level of software support we can halve their costs and reduce cycle time to 4 weeks for the top 3 of these processes.

Providing this ROI to our existing install base will preserve M&S revenue.

 

Moreover, here’s the list of RFP responses we can’t compete on (and their value) due to these processes not being supported right now.

 

If we modularize these features and deliver them sequentially, here’s the first round of prospects we’ll be able to work with – plus we can charge an additional premium for some of these features.

 

Based on current team velocity and backlog, we’d like to focus on delivering a minimum marketable feature set by the end of next quarter to meet the top priority business processes however there’s some viable value-add work that we want to move forward on, can we have 6 month’s funding now and an option of a further year if we’re successful?
– Ok, I’ll tell you what. Here’s 4 months funding. Let’s have a checkpoint review in 3 months and assuming you’re within 20% of your target we’ll immediately release a further 3 months (7 in total).

If you can deliver on those, I’ll make sure you’re on the fast-track priority list for the next round but if things aren’t going well at the end of 6 months we’ll need to either shut the work down or push for a hard reset.

How soon can you have something to show me?

I’m grossly exaggerating and over-simplifying. It’s an extreme example to illustrate a point but which is a more compelling business case and conversation?

  • Which has clear priorities, measures of success and is believably achievable?
  • Which would you invest your personal million dollars in?
  • Which is more likely to be set up for success?

The impact of governance on portfolio and product management

Let’s assume your governance system is broken and you can “get away with” the first case. There’s more to explore!

Let’s imagine both of the above were products in the same active portfolio…

Scenario 1:  – Portfolio resourcing and opportunity cost
I have a constrained resource – developers. I can choose to invest those staff across all products in parallel and deliver slowly or focus on a smaller set, deliver faster and then move onto the rest. I know I want them all but surely there’s an absolute priority. Considering the business cases above, which will allow me to prioritize better?

Scenario 2:  – Portfolio investment in a downturn
We’re in a big economic downturn, our numbers are looking bad and we need to start cutting investment fast. Looking back at the business cases for our existing portfolio, which should I take out first and which should I keep?

Scenario 3:  – Portfolio collaboration in a tight market
We’re in a business team where each of us owns a given product or number of products. Again, the market is tight. Ours was the first business case above.

We have a choice. Fight our corner for our product’s success or collaborate with our peers to set up the best selection of new product releases based on overall market trends, install base, requests etc.

If we fight our corner, we risk sub-optimizing around personal goals at the expense of the entire group’s success. If we collaborate, we won’t get a new release for our product this year.

Which is the “right” thing to do?

Scenario 4:  – Improving product quality through your business case.
I’m a developer on a team. I’ve been working with the same product for 5 years adding new features continuously.

I like my job and want to stay. I don’t question why we’re adding new features, I’m sure there’s a good reason and I’m told that’s up to “the business” to decide.

I’m now halfway through writing a new feature and I don’t know what the user is actually trying to achieve.

Given the above business cases:

  • Which is most likely to have backup information that allows me to make a sound implementation decision quickly?
  • Which one has users I can talk to?
  • Which is the more motivating product to work on?
  •  Which one am I likely to actually care about any deadlines or commitments for?

 So What?

A sound business case** is just as vital to an agile team’s success as it is to our portfolio decisions. How many times are engineering teams really engaged in the business case for the product they’re working on – or are even able to challenge parts of it?

**When I say sound I don’t just mean it has great projections, I mean it stands up to truly solid testing – try the 200 questions technique for testing a proposal.

  • In your organization is it their place to do so or none of their business?
  • Is it more cost-effective to keep them out of the loop?
  • Really? How’s that working out for you?

We need to understand and explain what really meets our customer’s and our own business needs. Did the last release fail to solve their problems or do they have new issues?  It’s not just what “features” (and how many) the next version of the product should have. It’s who do they impact & how and should we even have a new version of that product right now relative to other priorities.

Time to re-check your governance systems and start thinking like a VC. Set up your funded start-ups for success, actively manage the portfolio without wasting resources, engage experts in decision making and business support and where a real new opportunity is seen, don’t just fire a single shot, try a spread bet on that market.

Beyond the initial investment, good VCs offer support, mentoring and critical feedback. They don’t just hand over money and quietly hope their horse will come in at the end of the race.

If you’re on any kind of portfolio review, do a proper job, ask tough questions and make sure your business is making sound decisions.

All of us as reviewers are empowered to do so, don’t let precedent or pressure erode your business sense. It’s our responsibility to test, challenge, verify and make sure we’re investing in the right spread of activities.

Be brave.

If you can’t see the value in an investment or feel your money is better spent elsewhere, tackle those issues head-on.

Some thinking for you.

  • Are your portfolio reviews being gamed because of a poor periodic funding cycle?
  • What operating tolerances have you agreed for each of your investments?
  • What would need to happen for you to be able to easily review your portfolio more frequently?
  • In your current portfolio are there any investments that smell bad?
  • Is your portfolio a good balance of risk, reward and cycle time?
  • If you had to shut down 10% of your projects next week, which would they be and where would you reassign that investment?
  • What critical questions do you (or should you) be asking of any investment?
  • Do those questions change depending on the type and scale of investment you’re making?
  • Are you truly “empowered” to change any of these things?
  • Who do you need to discuss this with?
  • What would really happen if you tried?
  • If you could change or improve 3 things in the way you review your portfolio, what would they be?
  • What’s truly stopping you pushing for those changes?

Creativity

Share

The best software developers I’ve worked with so far (in the last 20 years) are a particular type of person. They tend to blend the creativeness of an artist with the technical adroitness of a scientist and the clear-thinking of a businessperson.

That’s quite a lot to personalities to fit in one head.

The trouble with creative types is that sometimes we’re a bit needy.

Almost gone are the days when you could have a great idea and code away with your mates on the next “killer app”. Those success stories and startups you read about are outliers, many markets are saturated. You need a genuine differentiator to succeed and it’s a long and painful road to get there.

In many successful (and unsuccessful) companies it’s a rare luxury to work on genuinely green field software development projects. Legacy code is the every day reality for most of us.

That new and shiny creativeness is a different beast in large-scale or legacy software development. Step back and take time to recognize that your needs are being fulfilled – but in ways you may not be open to seeing.

For those of you who live in the harsh reality of “normal”, when truly creative opportunities come up, relish them but don’t cling to them.

Embrace it, make it work for you and remember how every genuine improvement you make is one more step along the road to “better”. And that in itself is creative.

There is art in refactoring

There is love in fixing bugs

There is rare beauty in using coding standards

There is satisfaction in fixing broken tests

There is joy in shipping release 29.5.36 of your successful but old product.

Stay creative.

Legacy Code Vs Legacy Product

Share

Some old gems I picked up at Agile 2010 from “Agile Test Automation Strategy for the non-Technical” by Gerard Meszaros (Author of xUnit Test Patterns).

These are still as relevant today as they were 5 years ago.

First, there are 2 critical definitions to provide context…

  • Legacy code: Code that does not have automated unit tests.
  • Legacy products: Products that contain legacy code.

However – a legacy product does not have to contain only legacy code.

Now, considering the differences between legacy product & legacy code think about your work on “legacy products”.

  • If you are adding new code, where do you add it and what testing do you do?
  • If you are modifying legacy code, how do you treat it and what testing do you do?

Here’s a quick refresh of the testing pyramid concept…

testing pyramid

The (grossly simplified) ideal world view is that you have a large number of automated (fast) unit tests as a safe platform upon which you build a suite of automated and manual functional tests and at the peak you have your broader system tests.

Most legacy products and systems have this pyramid inverted with heavy investment in system test and UI automation, insufficient small functional tests and few if any unit tests.

Great. So What?

Stop trying to “Correct” the testing pyramid.

 Rather than wasting our constrained capacity trying to automate everything, we must understand that legacy products have a testing “sweet spot”.

Focus testing and test automation strategy and investment on the areas of highest risk and highest ROI.

Even at the uppermost level, automate the things that steal most of our time first.  This frees us up to do more value-added work.

Do not try to retrofit unit testing into legacy code.

 To paraphrase Gerard, I distinctly remember him saying “Don’t waste your time unit testing legacy code”.

Instead, invest in the middle layer – the small automated functional tests.
This is because for the volume of code you are working with and its maturity, small functional tests will provide you a far higher return on investment than the same effort spent unit testing legacy code.

Given this is from the guy who literally “wrote the book” on unit testing this surprised me at first. It all becomes clearer in the next 2 points he makes!

(This is where the difference between legacy code and legacy product is key)

If you’re adding new code to a legacy product, unit test it.

Add a procedure or method call from the legacy code to the new code and then treat the new code as independent new code.

This practice also encourages better coding & architecture practices with greater readability.

Whilst the ROI on retrofitting unit tests to legacy code is low, the unit test effort for new code is recovered in prevented defects, less review issues, faster build & test feedback and simplified code maintenance.

Legacy code modifications should be refactored into new code.

 If you are modifying legacy code, use good refactoring patterns to turn it into new code.

Now it’s new code, it’s small, unit test it!

The “Extract Method” refactoring pattern is of particularly high value here. Essentially you have a fragment of code within a method to fulfil a particular purpose. Pull it out into its own short well-named method and treat it as new.

Avoid merciless or repeated refactoring.

This point came from Naresh Jain during his time working at Industrial Logic but fits here…

Refactoring is a discipline, don’t get carried away.

Understand what refactoring really means, study the patterns involved and use them with caution.

Wholesale rewrites are not refactoring.

I’d argue that all developers will work on legacy code in their careers so I strongly recommend a complete read of these…

There’s also a great cheat-sheet on code smells to refactorings here.

Negative User Stories and Email Subscriptions

Share

When I first joined Red Gate nearly 4 years ago my first major project was working on a replacement system for managing marketing and transactional email for our customers.

Yes – email marketing – and boy did we suck!

Back in summer 2011 I kicked-off some team research, analysis and story activities on one major enhancement we wanted to develop – “Subscription Management”.

This sounds pretty straightforward right?

Hell no!

This is a sensitive area involving a series of tensions between international compliance & standards, good end-user experience, the working lives of a marketing team and ultimately the reputation of the company.

Let’s put this into context of a few major groups of users (this is just a subset)

1: The “Customer”

I bought your software once, I pay my annual support & maintenance, I’m reasonably happy with what I have. Let me know when there’s a free upgrade or my renewal is due but don’t sent me any more damn marketing or I’ll report you as a spammer.

2: The “Tourist”

I attended an event sponsored by you at some point in my life and since this I seem to sporadically receive mails from you or one of your affiliate companies. I’m interested in the community stuff and freebies so I might read some of the mails you send but if they’re not directly relevant to my interests I want to get off of whatever list/sub-list I’m on fast.

3: The “Fan”

I bitched about your company when you acquired a free product and turned it into a paying one but I’ll concede you guys have done an awesome job and I already used a few of your other tools anyway.

I’m always on the lookout for things that make my life easier and I’m not averse to finding out about the new developments you have in the area I work in.

If you send out something interesting I’ll even share it.

These people are worth looking after & listening to but they’re a fickle bunch – use with caution.

4: The “WTF”

How the hell did I get on this list? I’ve never heard of you, stop sending me spam!

It turns out they attended an event or downloaded some freebie from an affiliate site an their details found their way into the system or into the hands of a marketer who moved project, role or teams but kept their contact “because it was closely related”.

5: The “Prospect”

Yup, that’s right – you might actually be sending mails to real prospects!

What are they trying to achieve right now and what’s the most useful thing you could offer them?

If that’s not in the mails you’re sending, expect an unsubscribe. Staying in there inbox “to keep them aware” is probably not going to improve their opinion of your products.

6: The Marketer

I’ve been sending mails to this specific subset of the company-wide install base for years. I have my campaigns carefully planned with content, timings, massive target audience etc. I’d love to see the campaign convert into direct revenue but I’m more interested in getting it out of the door as one small part of my overall marketing strategy for the quarter.

This should be the easy bit, right?

What do you mean everyone unsubscribed because half a dozen other marketers hit them with irrelevant stuff over the last month as well?

 

Yup. That really used to happen here.

So the great thing is that with a little research, designing a great user experience around email subscriptions is surprisingly easy. There’s a basic set of users with competing and/or overlapping needs but more importantly. When someone doesn’t want your marketing mails, that doesn’t mean they hate you. It’s not a break-up, it’s not the end of a beautiful relationship, it’s simply someone asserting their needs.

So many companies manage to screw this up because they focus only on the needs of the marketer.

Make opting out a positive experience and chances are if a contact has a reason to talk to you (or someone like you) again they’ll be in touch. If they don’t – well, there’s no point in them being a contact still, right?

Spend a bit of time thinking about the more negative interfaces your customers, users and prospects have with your company.

What small steps can you take to raise the bar on these?