Competing on the Basis of Speed
For those not familiar with the ideas behind Lean software (and even for those who are!), please check out Competing on the Basis of Speed, a talk given to Google by Mary Poppendieck in 2006.
One of my work goals for 2010 is to compete on the basis of speed. Specifically, I want to help my team:
- identify tech debt, defects, or process problems that are increasing lead time
- minimize or eliminate the creation of new defects and tech debt
- convince stakeholders 0f the value of delivering fast to get customer feedback
I think I’m already off to a good start. The aim of the project I’m currently working on is to add functionality to our product that makes it easier to integrate into customers’ existing infrastructure. The technical requirements are known to us, and we’ve finished implementing the functionality. However, we’re at a point where we’ve hit a bit of a wall – no one on the team has any experience as a consumer of this functionality (that is to say, none of us are IT administrators), and it has been difficult to get focused feedback from others within our organization who have such experience. What it comes down to is that we’ve got a feature that is technically correct (follows RFC specifications, has been load tested, etc.) but has not been tuned to customer environments.
This is not an uncommon situation in software – in fact, it’s part of the reason why “Have an embedded customer representative on the team” is a practice in Extreme Programming. However, it’s not always possible to find internal “customers” (we call them Product Managers) with extensive experience with every particular area of the field. For larger projects it may make sense to train the Product Manager in the specifics of the new functionality by having them consult heavily with paying customers, but for smaller projects this is not always feasible. My current project is less than a month old and we’re code complete, and much of the time was over the Christmas holidays with our Product Manager (and most of our customers) on vacation, so consultation wasn’t much of an option.
So, here we stand – a mostly finished project that can be release-ready within 2 weeks but that has not been fine-tuned to meet all customer requirements (as such requirements are unknown). What to do? The traditional approach within the company has been to do a beta, but these don’t necessarily solve all problems. Our betas are opt-in, and often contain very few members (less than .5% of our customer base). Feedback can be hard to gather as beta systems are often put into non-production situations. There is also quite a bit overhead involved in coordinating and communicating with all of the customers involved.
Instead, I’m pushing towards getting this thing released to all customers as early as possible. The more people playing with it the better. The code is not buggy (we hope!), it just may be lacking some specific features or compatibility. Rather than wait around for 2 or 3 months as we do research and try to completely accurately model customer scenarios (a process that’s inevitably difficult and fraught with errors), we’ll get the code out into the field.
The best case scenario is that everything we’ve done so far is adequate for the market, and there are no future requirements. This means we’ve starting recognizing value 2-3 months earlier than if we had waited and done more market research, and we haven’t sat around gold plating the project for a quarter. The most likely scenario is that our code is adequate for some, but others will need some enhancements before it will work for them. We can then prioritize these enhancements based on some sort of financial metric (renewal date of customers who need the feature, likelihood that the enhancement will bring new customers, etc.) and deliver them over the next little while.
The worst case scenario is by far the least likely to happen – that would be where customers get the new feature, find that it’s not quite up to snuff, and because of this decide to overhaul their IT infrastructure and rip out all of our company’s products because of this. That’s so unlikely that it’s barely worth mentioning. Something like this is more likely in the case where we’re changing an existing feature instead of adding a new one, but even then it’s a slim slim chance, and would be the result of a decision on the customer’s part based on emotion rather than reason.
If you presented a customer with the choice between the following two options:
- a rudimentary version of Feature X now, with improvements to come soon afterward
- a “complete” version of Feature X several months from now
… I’m willing to bet that most customers would pick the first option. The choice would be even easier once the customer realized that the “complete” version from the second option would likely have to be followed up by a release or two afterward containing improvements that the developers / Product Management failed to identify in the first go-round.
I’m excited that there seems to some buy-in to this approach so far – hopefully it pays off for us!
January 10th, 2010 at 10:31 am
In my experience the problem I run into in this kind of situation is where we ship the minimally functional pieces, and then the business moves on to other feature sets and we don’t return to do that tweaking & polishing for a long time. From the business perspective, it can be very tempting to move on.
January 10th, 2010 at 11:15 am
@luke Absolutely – and that’s not necessarily the bad thing. It’s a fine line – you need to make sure the feature you ship is good enough to get people using it. Ideally it would drive sales, though with a very experimental / proof of concept feature this may not be the case.
The thing is, if the business looks at it and says “We have a $1 million sale riding on developing NewFeatureY, and only $250k riding on improving OldFeatureX”, then they are entirely justified in not going back to tweak and polish. In business, everything (including development) should be looked at from the business perspective – that’s one of areas that Lean stresses and that is sometimes left out of descriptions of Agile.
Now, if the business guys are just ignoring customer pleas to improve OldFeatureX in spite of it making business sense to do so, you need new business guys
January 10th, 2010 at 11:19 am
Right. I guess what’s hard to measure is the cumulative effect of leaving areas unpolished. I would argue it’s way way easier for the business to always choose “new feature X” over incremental improvements to old features. But then you can get to a point where the unpolished parts start dragging down customer satisfaction (not very tangible) and team satisfaction (eg: proud of your work, again not very tangible).
Having said that, I don’t disagree with your analysis. We can’t do everything, right?
January 10th, 2010 at 12:35 pm
I’ve now remembered where I’ve heard a lot of this before – see Eric Ries’ article on validated learning (http://www.startuplessonslearned.com/2009/04/validated-learning-about-customers.html).
January 21st, 2010 at 7:33 pm
From a business point of view, I’d have to say you may be jumping to conclusions about whether a business would want the rudimentary FeatureX now or the complete FeatureX in a few months. I’m not saying this is true for ALL businesses, and I don’t know the context that you’re coding for. All I know is, a business decision maker would sometimes prefer to have a known quantity complete but have to wait a defined period of time. The problem with having a rudimentary thing is that it involves an extra update later; your people may not get what you want so you have to be bothered back-and-forthing with the developer to get it right. Sometimes you just want the whole enchilada in one go, and a bit of an extra wait is worth it.
I’m not saying this is true in all cases, but it might be true in enough cases to scotch your assumptions.
January 21st, 2010 at 7:35 pm
Now I note that your next paragraph suggests that the complete FeatureX a few months from now might not be complete anyways. What’s the point then? If these were my choices:
- rudimentary FeatureX now that doesn’t have what we wanted, with updates later
- complete FeatureX later with oops we weren’t quite complete before updates later
Sorry, but I’d have to go with C, none of the above. In this case, you should have done more market research ahead of time!
January 21st, 2010 at 10:28 pm
Thanks for the comments, Sue!
I guess there’s a few problems I see with your reasoning. In your first comment, you mention that the back-and-forth between developer and customer is a “bother”. For software that can be very precisely defined (math computations, etc.), a single up-front specification from the customer can be sufficient to deliver an acceptable package. But if you sat down and describe how you wanted a website to look, and then I went away for 3 months and built it, and then showed you the final result, it’s almost guaranteed that you’re going to find some issue. Perhaps you under-specified something. Maybe you thought that purple and blue would look good together, but they don’t. Perhaps you just changed your mind on something! If you had been going back and forth with me, where I showed you interim bits, we would much more quickly converge on something that you find acceptable.
Option C in your second comment would be great, if it was always applicable to software, but often it just isn’t. If you plan something for 6 months, and then build it and it doesn’t line up with what people want, market research won’t always help. Sure, reading up on a target market is important, and getting people to fill out questionnaires can help, but it’s still just speculation. Getting *paying customers* on a product gives you real, live validation.
Of course, there’s examples on either side of this. You may say “Well, Apple goes dark for a while, then comes out with awesome software / hardware – why can’t you just do that?” Well, sure, that’s one data point. Microsoft does the same thing – how did you like Vista? Google routinely does the early release thing (think Gmail’s 5 year beta).
This is greatly eased when there’s an easy flow of communication between developers and customers. Developers *should* be close to customers, otherwise the back-and-forth really does become a bother. If one our customers wanted to have an improvement to our new feature, they don’t have to call some outsourced tech support, working their way up the chain until they reach an ombudsman, who will relay a version of the request to a senior product manager, to a technical product manager, and so on down to a developer. If they did, the gist of the customer’s request would be totally changed due to all the handoffs! As a development manager, I see customer requests as written by the customer. I have their phone numbers and email addresses. We have the power to deploy specific versions of our software to specific customers, helping us validate features without impacting others. Our customers see this as a *fantastic* thing, and anything but a bother.
Software is different in a lot of ways than other product development. If you’re interested in learning more about it, I’d have a look at the Agile Manifesto as a start, watch the video above, and, of course, ask me more questions! If you really want to see an extreme version of shipping fast, have a look at Eric Ries’ idea of continuous deployment. His company (and a growing number of others) ship code to customers up to 20 times a day – every change gets shipped! He’s made a whole lot of money doing this, and his customers don’t see it as a bother either.