Lean Startup is Agile by another name - and that's okay.

There's a lot of buzz building around the Lean Startup model lately; it's been around for a few years but we're starting to see mention of it in places like the WSJ and the boardrooms of major enterprises. To some degree the sentiment is that Lean Startup will deliver us from the morass of failed Scrum implementations littering the software departments of the world. Agile is over; Lean Startup is king.

Or, as The Who so eloquently and noisily put it: Meet the new boss. Same as the old boss. Lean Startup doesn't replace Agile development; it is Agile development.

This is no bad thing. Agile done well is a beautiful thing. The only real problem with Scrum is that very few people ever did it properly, not helped by the organisations that did do it right often ending up inventing something more like their own unique process after enough cycles of reflection, introspection and self-improvement. Failed implementations happen because Scrum is easy to misunderstand, and it's not always easy to point at what the leaders do right. Lean Startup may be only another variant of Agile development at heart, but what it brings is a way of stating the process in a way that's harder to misunderstand in that way, and generic enough to see the patterns of success.

In other words, Lean Startup evolves Agile development by correcting the mistakes Scrum made about communicating the process. But how did those mistakes get made in the first place?

TPS Reports and Deadlines

First, we need to go back to the industry's brief and all too limited dalliance with Extreme Programming, or XP. Software development in the '90s was ruled by the cult of managerialism. This is the world that spawned Dilbert and the movie Office Space. If something good happened, it was because a manager had willed it so. If something bad happened, that was the fault of a seditious team not doing what their manager had told them to.

Programmers, designers, testers and the like were just the poor saps who had to work until late at night and give up their weekends to meet arbitrary deadlines and implement pointless features. Project management was by fiat: it has been written that the thing will be ready by this day, therefore it will be so - or it's your fault.

What this resulted in was twofold. Teams working at an unsustainable pace took shortcuts and made mistakes that compromised the quality of their software. Managers (who answered to no-one but other, more senior managers) took decisions divorced from clients or customers, resulting in software that didn't do what the users wanted even when it was working.

This situation sowed the seeds for Extreme Programming: a set of technical practices based around producing low-risk iterations and getting customer feedback, concentrating on what's needed today.

XP never really took off in the wider programming world. A large part of that is down to XP being extremely prescriptive. You must pair program. You must release on each iteration. This made it scary to adopt for people wanting a lazy, low-effort silver bullet. XP stated up front that it was going to be a lot of effort, and needed a lot of commitment to do well.

The Manifesto

Some people were prepared to put in the work to use XP though, and did so to great success. At the turn of the century a few of these leading lights of XP, Scrum and similar processes got together and wrote an abstracted view of what made their ideas work where managerialism had failed. They saw the following common elements:

• Valuing people and interactions
• Collaborating and getting feedback
• Responding quickly to change
• ...and actually delivering the software

Sound familiar? Those are the key tenets of the Agile Manifesto. This was the first toll of the bell for managerialism. Things didn't exist because a manager had said they should be so. They existed because a group of people got together and worked hard to make them happen.

The manifesto itself didn't make agile development take off by itself though. That came with the rise of a process that had been around for nearly a decade prior to the manifesto, but utterly espoused its principles. A process that didn't feel scary and complicated like (at the time) more well-known XP did: Scrum.

As Scrum rose in popularity, its practitioners learnt from XP's limited reach and didn't try to push technically prescriptive practices into it to cater to the software industry. Instead it remained centred around a set of general philosophies (feedback, response to change and focused planning) with a bunch of friendly, fun-sounding ceremonies that anyone could understand, without needing to be a programmer. Some of the top Scrum firms were so agile and empowered they didn't even bother with all the ceremonies!

Scrum done properly was and remains a very effective way to manage projects of any type, not just software - not least because it doesn't detail those technical, industry-specific practices. But as I've oft bemoaned, something unusual happened. Because the ceremonies had snappy names and simple ideas, and canny consultants started selling them as a silver-bullet playbook rather than a stepping stone to a philosophy, people started adopting the names and maybe a gist of the idea, but not the thing. We got Enterprise Agile:

• A daily status update driven by the project manager.
• "Weeks" as a unit of measurement replaced by "sprints"
• A per-sprint planning session in which the project manager tells the team what they're going to do next sprint.
• A per-sprint retrospective in which the project manager tells the team what went wrong and how they must all work harder next time.
• A single release at the end of a project.

Now, are those the goals of the Agile manifesto? Or is that more like managerialism's reanimated corpse shambling around?

This is Scrum's big weakness. The ceremonies and the jargon are not the process - but they're the thing people latch on to.

Learning from mistakes

Lean Startup has learnt from Scrum's ceremony-centric presentation. It doesn't focus on the day-to-day behaviours, it starts with the strategy. But just because the process is stated at a different level doesn't mean it's something new entirely. At its core are three big principles:

• Frequently release minimum viable products.
• Measure the outcome against predetermined hypotheses
• Be prepared to pivot - to radically change direction based on your measurements.

Look again at the Agile manifesto. Deliver working software. Respond to change. Get feedback. Lean Startup isn't a replacement for Agile; it's merely a new way of presenting the ideas - but in a way that's learnt from Scrum's weaknesses and strengths.

The big difference is that Lean Startup doesn't emphasise rituals. It emphasises results. It does so in a way which is clear and easy for anyone to understand and has some nice, snappy terms like "splits" and "pivots" that can be bandied round the boardroom. Rather than being able to say, "we're doing okay, we have stand-ups and organise our work into sprints" while still practicing some kind of pant-seat/waterfall hybrid, you need to get to a point where you can state results. Yes we have multiple, frequent releases. Yes we measure the outcomes of those releases. Yes we change direction in response to those measurements.

Lean Startup isn't a replacement for Agile development; it's Agile development re-stated in terms of its end results, explained in a way which is harder to misinterpret or misunderstand. But unlike Scrum, in which it's easy to fool yourself into thinking a few rituals and buzzwords constitute the whole of the process, it's much more obvious whether you're there or not. Here's to Lean... and the next decade of Agile development!

_{Original image by RebbseCC-SA 3.0}