I’m a fan of Agile software development. But there’s one big thing that bugs me about it. The underlying assumption seems to be that the business knows what it wants, and can articulate the required “user stories”, and prioritize these correctly. And that even before we talk about user stories, Agile assumes that the business people are pointing the business in the right direction, strategically, and that your product roadmap is more or less correct (at least at a high level), and so the adjustments you make at the start of each sprint are pretty incremental to the company’s overall product strategy. Well, that ain’t always the case, and I’ve seen a lot more money wasted by the business being incapable of settling upon workable and consistent strategies, than by software developers who write bad code. So using your product development efforts to validate the direction in which the business is driving is vital, particularly in cases where the business is unable to prioritize user stories correctly because there’s so much uncertainty about the business direction and strategy.
I like Eric Ries’ “Lean Startup” approach in cases like this. Ries says that when you are in startup mode (and in his definition of startups, he includes any team that is trying to fire up a new business concept around a software product or service, so you could include teams working in larger companies who’ve been given this challenge) the business typically has little idea what’s going to work and what’s going to fail. They may think they do, but the reality is they may be mucking around in the right area, but they don’t know what will work, and their chief assignment is to learn what works and what doesn’t, and what is important to customers and what isn’t. In Ries’ view (and I agree with him), you don’t go out and do some market research to find out the answers (at least not right away), since if you’re inventing something very new the people you interview will have no idea what you are talking about and might mislead you. And you don’t get senior management in a room with a white board to map it out either, since they may have known enough to get the startup funded, but don’t know all the answers either. Instead, Ries tells you to perform a series of rapid experiments with customers (and prospects) and figure it out scientifically. You test how users respond to a feature, and whether they use it. If they don’t use it, then go talk to them–find out why. Now you can have a useful discussion with them, not a theoretical discussion. If nothing’s working, you might need to consider pivoting towards a new strategy that (hopefully) will work better. But ideally, make any adjustments or decide to pivot as soon possible, so you don’t spend two years “perfecting” your product based on your own ignorant idea of what the product will be, only to have customers later tell you that you were way off target. Even if your idea was mostly right, it will benefit from some contact with the customer as soon as you can get this. If your idea was mostly wrong, it’s best to learn that before you waste a lot of time and resources.
OK so if you buy the idea that being a startup means you need to do the best you can to have a rapid feedback loop from learning something in the market, to implementing some changes in your product based on those market learnings, you’re going to need to invest to develop your product in a way that supports that learning process:
1) Build an infrastructure for running A/B tests on users (Ries’ approach sounds a bit consumer-oriented, and not enterprise software-oriented, but we can take some inspiration from the idea and find ways to apply it to an enterprise world)
2) Ensure you gather useful metrics on user behaviors, so you can analyze what they really did with the product, and have objective discussions about what’s working and what’s not
3) Have a capability for frequently deploying incremental new releases (e.g., test automation is going to be critical here)
4) Have a process that supports quick reaction to market feedback (in terms of feature prioritization)
When you consider these factors, 3 & 4 are provided by an Agile process, but 1 & 2 really aren’t. Agile doesn’t provide an approach to figuring out your strategy, and quickly testing what’s working and what’s not when you are in startup mode. And Agile doesn’t tell you that you need to do experiments on customers to figure out what they want, and what they are willing to pay for. When you’re in startup mode, learning those things are the most important things you can do in order to apply your resources to what’s working. Unfortunately, Agile doesn’t really tell you that.
So if you have a relatively mature business, and you’re not in startup mode, you don’t really need to be Lean. You understand, more or less, what you’re doing, and you can run an Agile development process with a backlog of requirements, and prioritize user stories at the start of each release cycle, and be relatively confident that you’re going to add value with each release. In fact, you’ll be much more confident than if you were using a waterfall-type process. Even if you mis-prioritize the requirements in one release, there’s another release following soon after, so you’ll get to those requirements then, and it’s not a disaster. But if you are starting up something entirely new, whether it’s an entirely new company, or a new product line for an existing company, and you can admit that you don’t know what’s really going to work, and whether customers will even buy the product you envision, then Agile isn’t sufficient. A Lean approach and an Agile development process are complementary and support each other, and you’d benefit from using both.