Traditional big budget game development methodologies such as Waterfall; milestone based, heavy on the feature collection, and documentation have to change.

Follow @alanodea

Breaking video game project down into Alpha, Beta and so on have been around for a very long time and on the surface appear to be control oriented and logical. This Waterfall structure is all about delivering in large increments of art, animations and code that theoretically deliver great game play experiences.  That is, write up what the entire game is; write up all the technical requirements, art and animation needs, designs, story, etc.  and then break this all down to a week to week schedule and ultimately into a hopefully a bug-free demonstrable working product we can call a game.

Stakeholders (the business), and if there’s a publisher involved, the publisher are used to and even like this arrangement as they are paying for deliverables that are forecasted (if you will) but only after they are delivered.  In simple terms, milestone “A” reads XYZ, when deliverable “A” is XYZ, you get the signature and a check. The Lawyers like this too, it’s a defensive position just in case the developer has not been completely honest or just not able to deliver the experience they sold at all the pitching sessions. The Accountants especially love this arrangement, as you get paid for demonstrable results. The fact that you get paid for the work and costs (and let’s not forget about opportunity costs) you’ve already accumulated over that past few or several weeks or months, a constant cash flow challenge is not a problem for them at all. Developers are used to this as well, give the boss or publisher the features and tasks, lock it down and estimate the man-months.

The Producer plugs it all into a spreadsheet and gantt chart and rolls it all up and this usually takes weeks of work. So why do we need to change anything? The obvious answer is that in the real world there are unanticipated issues. There are issues such as changing technology, hiring new people or restructuring team members, contractors, estimation errors, general  HR issues, and even culture issues. Internally and external to the team there are disruptions such as feature creep, dropped features, bugs, change requests, and the dreaded – “It works, it’s just not fun.” Ultimately can we expect to be consistently successful with this Waterfall approach? Generally speaking, I think there’s a ton of luck whenever a great game is produced from this development methodology.

If you think about it, with this Waterfall approach you’re sort of doomed from the beginning given that you are essentially asking your team to gather all the game’s features and requirements that they want for the game, all the game features and requirements that they may want, as well as gather all the features and requirements they think they may want. To top it off, you are also asking them to do this at a time when they know the least about the design, art, technology, and team member’s abilities and without the benefit of play testing and focus groups. If there’s a paying publisher involved, repeat all of this or times 2. If there’s a license, repeat much of this again. If it’s a F2P or MMO there are also a multitude of Live Operations requirements for CRM, business development, technical operations, live operations and development, PR and marketing as well. Honestly, it’s always impressive to me when anything comes out on-time and is fun to play when this is the methodology used for creating the game.

As mobile and web technologies continue to evolve rapidly, as well as micro transaction platforms and the need for games to be connected to a digital platform there is added pressure to develop and deliver games and content in weeks instead of months or years. The basic principle of Agile methodology is to keep things simple and avoid un-necessary overhead. However, for many developers transitioning and successfully adopting a new methodology is easier said than done. Hopefully this will provide some good high-level information about why you need to be (not do) Agile as well as provide some understanding about why it works. Agile has been around for about 10 years now and most companies have difficulties transitioning to it because it really is a culture change – top to bottom bit needed today than ever.

The Standish Group is based in Boston and is in the business of assessing risk, cost, return and value for Technology Investments.

Waterfall vs. Agile project and success

An Agile approach to development is an empirical control method or a process of making decisions based on the realities observed in the actual development project. By using frequent and first-hand inspection for the work in real-time you can make better decision about your project, not to mention better decisions about the money you’re spending every day as well as the opportunity cost. Simply put, Agile is a collection of core principles, all of which can work well for big and small budget games:

• Ensure satisfaction by frequently delivering working software – no more milestones that take months to deliver
• Empowered, cross-functional and self-organizing, teams – no silos around programming, art, design, this will expose weaknesses and dysfunction
• Use of hi-fidelity communication preferably face-to-face to promote team collaboration – daily stand-up meetings where everyone takes daily responsibility
• Simplicity by design – the focus is always on delivering, with automated testing every night
• Use of feedback loops and other continuous improvement principals to ensure the process stays self-correcting – bottom-up, not top-down and again this is an exposure model

Following an Agile approach, I prefer to focus on the Scrum framework which is sometimes confused with Agile methodology, empowers you and your team to build a more successful game, cheaper and on-time. It allows you to get instant feedback by working with the customer (gamer or stakeholders) instead of working against the clock, budget, and business infrastructure. It’s a win-win situation but cultural changes are needed and usually the biggest roadblock to going Agile. In the long-term, experiencing a trusting partnership (measurable and verifiable in real-time) between customer, stakeholder and or publisher and the development team leads to the building of trust; and trust leads to higher efficiency, more creativity and effectiveness which increases your chance at a having a successful game. So what does this all look like and how does it work to “the boots on the ground”?

Stage 1: Vision

I think creating the game’s vision can be the easiest part; we’re all pretty good at this with the game’s “X” or essence statement and the vision usually come to life during the pitch process. This is really because there are instant feedback loops with the team, marketing, and others.  Components of effective vision are:

• The Game’s “X” or elevator pitch – the game’s goals in the context of the marketplace and gamer
• A vision that is strategic – there’s a strategic nature to the story, IP and so on
• Is owned by the Executive Producer or Game Director (in Scrum terms, the Product Owner)
• Is updated and on a formal basis, quarterly or annually
• Must be communicated throughout the development and company – provides context of how the development supports the overall goal

Stage 2: Have a Roadmap

Game and Technical Design Documents are good as long as they’re not used as a recipe. In Agile, there is a need for a roadmap, a formal written template of features, design, art vision and gameplay. The aim is to have a backlog of features that can later be estimated by the team that needs to do the actual work. The team needs (key word!) to be cross-functional. This is usually one of the first areas where you find out if your culture supports going Agile or not. Is everyone on the team able to honestly say everyday “Yes” to the following questions; “What can I contribute today?” and “How can I expand my contribution in the future?” Direct accountability to delivering and a little team competition is everything in the trenches. The roadmap should include:

• A holistic and digestible view of features that enable the game’s vision
• Enables features to be established and gaps to be identified
• General release timing for the game’s features
• Highest to least priority features identified so the most valuable game features will be built and released first
• Produced and owned by the Executive Producer or Game Director
• Prepared and revised bi-annually with the aim of creating a “Product Backlog”

Stage 3: Release Planning

Now that there is a roadmap, it’s time to break this down into a release schedule, with the most important features first. Initially, this creates two very important things as getting started can sometimes be the most difficult and critical stage of any development project. First, this gives the team something to rally around. Secondly, getting the most important features done first will let you know if the game should continue or be cancelled, and knowing this as quickly as possible is critical. After all, we live in the first to market world with greater importance given to opportunity cost than ever before.

Once the team has a plan and is participating on the estimation of work process you’ll quickly get a sense of their estimation abilities as well as the knowledge of just how fast or slow you’ll be able to deliver what you promised. Release planning usually includes:

• An initial focal point for the team to mobilize around and attack
• Target a minimal set of important gameplay features
• Plan and focus on one “Sprint” at a time, or 2-4 weeks of work not future features
• Owned by the Executive Producer or Game Director

Stage 4: Sprint Planning

If your Release Planning points to 2 week Sprints (the amount of time the team needs to deliver done, working, releasable bug free software) than you should allocate 2 hours each week for Sprint Planning, or one hour for each sprint week. This is where the team, facilitated by the “Scrum Master” will estimate the work to be done. There are a few ways to do this but the Scrum Master needs, above all to be in control and assertive so these sessions are productive. If this meeting starts to feel like a reality show, with drama then you’re losing it. This is another area where your culture will be on full display as far as which team members are going to work well, and which are going to be a challenge throughout the project. Sprint Planning is:

• One hour for each week of Sprint
• The team, with the Executive Producer or Game Director sets the Sprint goals and the subset feature backlog to work on
• The team figures out how to achieve the Sprint goals and Sprint backlog to be worked on
• The Scrum Master is facilitating, not the Executive Producer or Game Director

Stage 5: The Daily Scrum

Most are familiar with the daily stand-up or the daily morning meeting and unfortunately some think this is what Scrum and Agile are all about – short meetings with no chairs. Also, over the last few years, the word ‘transparent’ has been used more than the line, “…at the end of the day…” but here no one hides, no-one bloviates, no-one is better or worse than anyone else. The only focus of the daily Scrum is; “This is what I did yesterday, this is what I’m doing today, and these are the things impeding me.” We are building stuff people and nothing else matters. The goal is face to face updates and communicating issues and problems that the Scrum Master needs to solve. The Daily Scrum components are:

• Usually done standing up mainly to emphasize it’s not a typical meeting
• Only 3 statements are made by each team member; yesterday I…, today I… my roadblocks are…
• Generally a 15 minute meeting
• For coordinating and communicating within the team, not problem solving
• Real transparency everyone and anyone in the company is invited to listen in, but only the team talks – including the Scrum Master and Executive Producer or Game Developer
• The Scrum Master is facilitating, not the Executive Producer or Game Director 

Reference: Platinum Edge, Inc.

This is the classic view of the Project Team (Scrum Team), Stakeholders (business) and Agile Mentor or Coach (recommended during cultural transformation from Waterfall to Agile) and Product Owner (Executive Producer or Game Director).

Stage 6: Sprint Review

After a completed Sprint, there is a need to formally demo the work. There’s a lot here behind the scenes about automated testing, architecture, how and what a definition of a done feature is, given the goal of every sprint is to have a bug free, completed working product that can be demonstrated to the Executive Producer or Game Director. Further, this is theoretically or realistically releasable to the marketplace. Obviously this methodology is being used more and more on mobile, F2P and Casual where there are on-going needs for updates, content, features and live operation’s needs. There is no pageantry here, no PowerPoint’s, no mock-ups or hard coded stuff – just running code. The entire meeting should take about 20 min. to an hour. Sprint Reviews are:

• Starts with the EP presenting the Sprint goals and what the team accomplished
• The team demonstrates the work
• Should always feel informal, no frills, no slides or decks
• Has a theme of inspection and adaptation
• The Scrum Master is facilitating, not the Executive Producer or Game Director

Stage 7: Sprint Retrospective

After the review and given there’s been essentially nothing but coding going on, against the backdrop of having a Scrum Master running around keeping distractions away from the team, there is a need to step back and ask, “What went well?” and “What didn’t go well?” This is again usually where cultural issues arise around people and politics as this methodology doesn’t really fix problems, it exposes them. However, the focus is really on what’s working, what’s not working and what needs to change. The lists of possible issues are virtually endless, could be art is too slow, could be design issues and so on. There are burn down and velocity charts to show the team’s performance and other challenges to the project. The purpose of the Sprint Review is:

• Answer the big 3 questions – What went well, What would we like to change, How can we implement changes to make future Sprints more successful
• Is action focused, not rationale focused – this is not the place to air dirty laundry
• Generally 45 min for each week of Sprint
• Done after every Sprint
• Has the entire team participating, the Scrum Master is facilitating this one as well

Now, start the next sprint because while the team has been coding, the leadership has been refining the Road Map and Planning…

Reference: Platinum Edge, Inc.

A truly Agile approach encourages organizations to move away from yesterday’s traditional Waterfall approach and to develop a culture as well as structure at all levels that continually asks what’s best for the gamer, the game, the IP, partnerships and the organization. By constantly challenging the status quo on your Agile game projects you will reach new levels of efficiency and team productivity by having the customers receive working features quicker. Since this methodology is about frequent delivery, this also means that you get working features into the hands of customers and other stakeholders as quickly as possible. This ensures that the development team will receive informative, immediate feedback on necessary changes before it’s too late to change them. This will also help determine whether the project team is headed in the right direction in terms of the game’s essence, features and future tasks. Teams can quickly validate if they can proceed in a given direction, or if there is a need to make major or simply minor adjustments. This principle stresses the importance of embracing change on your projects. On Agile projects, you welcome change at all times, even late in development. Change helps you ensure the gamer will get exactly what they want or need, as well as gaining a competitive advantage over similar games or competitive titles.

There are naturally other considerations and disciplines to engage in all of this. Given company cultural issues such as the Lawyers, Accountants and business people, the internal empires and silos, the best approach is to start with qualified outside help and formal training and assistance. The bottom-line here is that when development team members get to choose their own tasks, the end result is maximum quality, creativity and team member collaboration. The productivity of the team as well as the quality and value of deliverables increases exponentially.

Source - http://gamasutra.com/blogs/BrianDreyer/20130408/190077/Going_Agile__The_7_Simple_Stages_of_Why_and_How_to_Get_it_Done_Im_not_saying_easy.php

Launching a new enterprise—whether it’s a tech start-up, a small business, or an initiative within a large corporation—has always been a hit-or-miss proposition. According to the decades-old formula, you write a business plan, pitch it to investors, assemble a team, introduce a product, and start selling as hard as you can. And somewhere in this sequence of events, you’ll probably suffer a fatal setback. The odds are not with you: As new research by Harvard Business School’s Shikhar Ghosh shows, 75% of all start-ups fail.

But recently an important countervailing force has emerged, one that can make the process of starting a company less risky. It’s a methodology called the “lean start-up,” and it favors experimentation over elaborate planning, customer feedback over intuition, and iterative design over traditional “big design up front” development. Although the methodology is just a few years old, its concepts—such as “minimum viable product” and “pivoting”—have quickly taken root in the start-up world, and business schools have already begun adapting their curricula to teach them.

The lean start-up movement hasn’t gone totally mainstream, however, and we have yet to feel its full impact. In many ways it is roughly where the big data movement was five years ago—consisting mainly of a buzzword that’s not yet widely understood, whose implications companies are just beginning to grasp. But as its practices spread, they’re turning the conventional wisdom about entrepreneurship on its head. New ventures of all kinds are attempting to improve their chances of success by following its principles of failing fast and continually learning. And despite the methodology’s name, in the long term some of its biggest payoffs may be gained by the large companies that embrace it.

In this article I’ll offer a brief overview of lean start-up techniques and how they’ve evolved. Most important, I’ll explain how, in combination with other business trends, they could ignite a new entrepreneurial economy.

The Fallacy of the Perfect Business Plan

According to conventional wisdom, the first thing every founder must do is create a business plan—a static document that describes the size of an opportunity, the problem to be solved, and the solution that the new venture will provide. Typically it includes a five-year forecast for income, profits, and cash flow. A business plan is essentially a research exercise written in isolation at a desk before an entrepreneur has even begun to build a product. The assumption is that it’s possible to figure out most of the unknowns of a business in advance, before you raise money and actually execute the idea.

Once an entrepreneur with a convincing business plan obtains money from investors, he or she begins developing the product in a similarly insular fashion. Developers invest thousands of man-hours to get it ready for launch, with little if any customer input. Only after building and launching the product does the venture get substantial feedback from customers—when the sales force attempts to sell it. And too often, after months or even years of development, entrepreneurs learn the hard way that customers do not need or want most of the product’s features.

After decades of watching thousands of start-ups follow this standard regimen, we’ve now learned at least three things:

1. Business plans rarely survive first contact with customers. As the boxer Mike Tyson once said about his opponents’ prefight strategies: “Everybody has a plan until they get punched in the mouth.”
2. No one besides venture capitalists and the late Soviet Union requires five-year plans to forecast complete unknowns. These plans are generally fiction, and dreaming them up is almost always a waste of time.
3. Start-ups are not smaller versions of large companies. They do not unfold in accordance with master plans. The ones that ultimately succeed go quickly from failure to failure, all the while adapting, iterating on, and improving their initial ideas as they continually learn from customers.

One of the critical differences is that while existing companies execute a business model, start-upslook for one. This distinction is at the heart of the lean start-up approach. It shapes the lean definition of a start-up: a temporary organization designed to search for a repeatable and scalable business model.

The lean method has three key principles:

First, rather than engaging in months of planning and research, entrepreneurs accept that all they have on day one is a series of untested hypotheses—basically, good guesses. So instead of writing an intricate business plan, founders summarize their hypotheses in a framework called a business model canvas. Essentially, this is a diagram of how a company creates value for itself and its customers.

1. Sketch Out Your Hypotheses

The business model canvas lets you look at all nine building blocks of your business on one page. Each component of the business model contains a series of hypotheses that you need to test.

Source: www.businessmodelgeneration.com/canvas. Canvas concept developed by Alexander Osterwalder and Yves Pigneur.

2. Customer Development

Second, lean start-ups use a “get out of the building” approach called customer development to test their hypotheses. They go out and ask potential users, purchasers, and partners for feedback on all elements of the business model, including product features, pricing, distribution channels, and affordable customer acquisition strategies. The emphasis is on nimbleness and speed: New ventures rapidly assemble minimum viable products and immediately elicit customer feedback. Then, using customers’ input to revise their assumptions, they start the cycle over again, testing redesigned offerings and making further small adjustments (iterations) or more substantive ones (pivots) to ideas that aren’t working. (See the exhibit “Listen to Customers.”)

During customer development, a start-up searches for a business model that works. If customer feedback reveals that its business hypotheses are wrong, it either revises them or “pivots” to new hypotheses. Once a model is proven, the start-up starts executing, building a formal organization. Each stage of customer development is iterative: A start-up will probably fail several times before finding the right approach.

1. Founders translate company ideas into business model hypotheses, test assumptions about customers’ needs, and then create a “minimum viable product” to try out their proposed solution on customers.
2. Start-up continues to test all other hypotheses and tries to validate customers’ interest through early orders or product usage. If there’s no interest, the start-up can “pivot” by changing one or more hypotheses.
3. The product is refined enough to sell. Using its proven hypotheses, the start-up builds demand by rapidly ramping up marketing and sales spending, and scales up the business.
4. Business transitions from start-up mode, with a customer development team searching for answers, to functional departments executing its model.

3. Agile Development

Third, lean start-ups practice something called agile development, which originated in the software industry. Agile development works hand-in-hand with customer development. Unlike typical yearlong product development cycles that presuppose knowledge of customers’ problems and product needs, agile development eliminates wasted time and resources by developing the product iteratively and incrementally. It’s the process by which start-ups create the minimum viable products they test.

Quick, Responsive Development

In contrast to traditional product development, in which each stage occurs in linear order and lasts for months, agile development builds products in short, repeated cycles. A start-up produces a “minimum viable product”—containing only critical features—gathers feedback on it from customers, and then starts over with a revised minimum viable product.

When Jorge Heraud and Lee Redden started Blue River Technology, they were students in my class at Stanford. They had a vision of building robotic lawn mowers for commercial spaces. After talking to over 100 customers in 10 weeks, they learned their initial customer target—golf courses—didn’t value their solution. But then they began to talk to farmers and found a huge demand for an automated way to kill weeds without chemicals. Filling it became their new product focus, and within 10 weeks Blue River had built and tested a prototype. Nine months later the start-up had obtained more than $3 million in venture funding. The team expected to have a commercial product ready just nine months after that.

Stealth Mode’s Declining Popularity

Lean methods are changing the language start-ups use to describe their work. During the dot-com boom, start-ups often operated in “stealth mode” (to avoid alerting potential competitors to a market opportunity), exposing prototypes to customers only during highly orchestrated “beta” tests. The lean start-up methodology makes those concepts obsolete because it holds that in most industries customer feedback matters more than secrecy and that constant feedback yields better results than cadenced unveilings.

Those two fundamental precepts crystallized for me during my career as an entrepreneur. (I’ve been involved with eight high-tech start-ups, as either a founder or an early employee.) When I shifted into teaching, a decade ago, I came up with the formula for customer development described earlier. By 2003 I was outlining this process in a course at the Haas School of Business at the University of California at Berkeley.

In 2004, I invested in a start-up founded by Eric Ries and Will Harvey and, as a condition of my investment, insisted that they take my course. Eric quickly recognized that waterfall development, the tech industry’s traditional, linear product development approach, should be replaced by iterative agile techniques. He also saw similarities between this emerging set of start-up disciplines and the Toyota Production System, which had become known as “lean manufacturing.” Eric dubbed the combination of customer development and agile practices the “lean start-up.”

The tools were popularized by a series of successful books. In 2003, I wrote The Four Steps to the Epiphany, articulating for the first time that start-ups were not smaller versions of large companies and laying out the customer development process in detail. In 2010, Alexander Osterwalder and Yves Pigneur gave entrepreneurs the standard framework for business model canvases in Business Model Generation. In 2011 Eric published an overview in The Lean Startup. And in 2012 Bob Dorf and I summarized what we’d learned about lean techniques in a step-by-step handbook called The Startup Owner’s Manual.

The lean start-up method is now being taught at more than 25 universities and through a popular online course at Udacity.com. In addition, in almost every city around world, you’ll find organizations like Startup Weekend introducing the lean method to hundreds of prospective entrepreneurs at a time. At such gatherings a roomful of start-up teams can cycle through half a dozen potential product ideas in a matter of hours. Although it sounds incredible to people who haven’t been to one, at these events some businesses are formed on a Friday evening and are generating actual revenue by Sunday afternoon.

Creating an Entrepreneurial, Innovation-Based EconomyWhile some adherents claim that the lean process can make individual start-ups more successful, I believe that claim is too grandiose. Success is predicated on too many factors for one methodology to guarantee that any single start-up will be a winner. But on the basis of what I’ve seen at hundreds of start-ups, at programs that teach lean principles, and at established companies that practice them, I can make a more important claim: Using lean methods across a portfolio of start-ups will result in fewer failures than using traditional methods.

What Lean Start-Ups Do Differently

A lower start-up failure rate could have profound economic consequences. Today the forces of disruption, globalization, and regulation are buffeting the economies of every country. Established industries are rapidly shedding jobs, many of which will never return. Employment growth in the 21st century will have to come from new ventures, so we all have a vested interest in fostering an environment that helps them succeed, grow, and hire more workers. The creation of an innovation economy that’s driven by the rapid expansion of start-ups has never been more imperative.

In the past, growth in the number of start-ups was constrained by five factors in addition to the failure rate:

1. The high cost of getting the first customer and the even higher cost of getting the product wrong.
2. Long technology development cycles.
3. The limited number of people with an appetite for the risks inherent in founding or working at a start-up.
4. The structure of the venture capital industry, in which a small number of firms each needed to invest big sums in a handful of start-ups to have a chance at significant returns.
5. The concentration of real expertise in how to build start-ups, which in the United States was mostly found in pockets on the East and West coasts. (This is less an issue in Europe and other parts of the world, but even overseas there are geographic entrepreneurial hot spots.)

The lean approach reduces the first two constraints by helping new ventures launch products that customers actually want, far more quickly and cheaply than traditional methods, and the third by making start-ups less risky. And it has emerged at a time when other business and technology trends are likewise breaking down the barriers to start-up formation. The combination of all these forces is altering the entrepreneurial landscape.

Today open source software, like GitHub, and cloud services, such as Amazon Web Services, have slashed the cost of software development from millions of dollars to thousands. Hardware start-ups no longer have to build their own factories, since offshore manufacturers are so easily accessible. Indeed, it’s become quite common to see young tech companies that practice the lean start-up methodology offer software products that are simply “bits” delivered over the web or hardware that’s built in China within weeks of being formed. Consider Roominate, a start-up designed to inspire girls’ confidence and interest in science, technology, engineering, and math. Once its founders had finished testing and iterating on the design of their wired dollhouse kit, they sent the specs off to a contract manufacturer in China. Three weeks later the first products arrived.

Another important trend is the decentralization of access to financing. Venture capital used to be a tight club of formal firms clustered near Silicon Valley, Boston, and New York. In today’s entrepreneurial ecosystem, new super angel funds, smaller than the traditional hundred-million-dollar-sized VC fund, can make early-stage investments. Worldwide, hundreds of accelerators, like Y Combinator and TechStars, have begun to formalize seed investments. And crowdsourcing sites like Kickstarter provide another, more democratic method of financing start-ups.

The instantaneous availability of information is also a boon to today’s new ventures. Before the internet, new company founders got advice only as often as they could have coffee with experienced investors or entrepreneurs. Today the biggest challenge is sorting through the overwhelming amount of start-up advice they get. The lean concepts provide a framework that helps you differentiate the good from the bad.

Lean start-up techniques were initially designed to create fast-growing tech ventures. But I believe the concepts are equally valid for creating the Main Street small businesses that make up the bulk of the economy. If the entire universe of small business embraced them, I strongly suspect it would increase growth and efficiency, and have a direct and immediate impact on GDP and employment.

There are signs that this may in fact happen. In 2011 the U.S. National Science Foundation began using lean methods to commercialize basic science research in a program called the Innovation Corps. Eleven universities now teach the methods to hundreds of teams of senior research scientists across the United States.

MBA programs are adopting these techniques, too. For years they taught students to apply large-company approaches—such as accounting methods for tracking revenue and cash flow, and organizational theories about managing—to start-ups. Yet start-ups face completely different issues. Now business schools are realizing that new ventures need their own management tools.

As business schools embrace the distinction between management execution and searching for a business model, they’re abandoning the business plan as the template for entrepreneurial education. And the business plan competitions that have been a celebrated part of the MBA experience for over a decade are being replaced by business model competitions. (Harvard Business School became the latest to make this switch, in 2012.) Stanford, Harvard, Berkeley, and Columbia are leading the charge and embracing the lean start-up curriculum. My Lean LaunchPad course for educators is now training over 250 college and university instructors a year.

A New Strategy for the 21st-Century Corporation

It’s already becoming clear that lean start-up practices are not just for young tech ventures.

Corporations have spent the past 20 years increasing their efficiency by driving down costs. But simply focusing on improving existing business models is not enough anymore. Almost every large company understands that it also needs to deal with ever-increasing external threats by continually innovating. To ensure their survival and growth, corporations need to keep inventing new business models. This challenge requires entirely new organizational structures and skills.

Over the years managerial experts such as Clayton Christensen, Rita McGrath, Vijay Govindarajan, Henry Chesbrough, Ian MacMillan, Alexander Osterwalder, and Eric von Hippel have advanced the thinking on how large companies can improve their innovation processes. During the past three years, however, we have seen large companies, including General Electric, Qualcomm, and Intuit, begin to implement the lean start-up methodology.

GE’s Energy Storage division, for instance, is using the approach to transform the way it innovates. In 2010 Prescott Logan, the general manager of the division, recognized that a new battery developed by the unit had the potential to disrupt the industry. Instead of preparing to build a factory, scale up production, and launch the new offering (ultimately named Durathon) as a traditional product extension, Logan applied lean techniques. He started searching for a business model and engaging in customer discovery. He and his team met face-to-face with dozens of global prospects to explore potential new markets and applications. These weren’t sales calls: The team members left their PowerPoint slides behind and listened to customers’ issues and frustrations with the battery status quo. They dug deep to learn how customers bought industrial batteries, how often they used them, and the operating conditions. With this feedback, they made a major shift in their customer focus. They eliminated one of their initial target segments, data centers, and discovered a new one—utilities. In addition, they narrowed the broad customer segment of “telecom” to cell phone providers in developing countries with unreliable electric grids. Eventually GE invested $100 million to build a world-class battery manufacturing facility in Schenectady, New York, which it opened in 2012. According to press reports, demand for the new batteries is so high that GE is already running a backlog of orders.

The first hundred years of management education focused on building strategies and tools that formalized execution and efficiency for existing businesses. Now, we have the first set of tools for searching for new business models as we launch start-up ventures. It also happens to have arrived just in time to help existing companies deal with the forces of continual disruption. In the 21st century those forces will make people in every kind of organization—start-ups, small businesses, corporations, and government—feel the pressure of rapid change. The lean start-up approach will help them meet it head-on, innovate rapidly, and transform business as we know it.

Source - http://hbr.org/2013/05/why-the-lean-start-up-changes-everything/ar/3

It’s important for founders to understand the background of Lean Startup, since it helps evaluate the strengths and weaknesses of the various approaches around it.

Follow @alanodea

They often seem incompatible or counter-intuitive, so this history will help you make sense of it and hopefully make more informed decisions. While Eric Ries, who coined the term Lean Startup, is preparing for the 3rd annual Lean Startup conference, he tweets out a link to “Standing On The Shoulders Of Giants” by Eliyahu Goldratt – a testament to the great thinkers we founders are learning from, whether we know it or not! 

As the founder of Leancamp, I’ve been a proponent of Lean Startup and it’s related approaches since 2009. I’ve been lucky enough to spend time and work with some of the different leaders in the Lean Startup world. Here’s how I’ve seen things go down.

Lean Startup, Toyota and Lean Thinking 

Lean Startup comes from Lean Thinking, which was a management approach famously applied in Toyota’s factory production system, as they rose to prominence. The term Lean itself was coined by American management academics, themselves great thinkers, as they studied Toyota. 

Since then, Lean Thinking has proven useful in a lot of different areas. The Healthcare and Construction industries have had their own Lean movements.  In the 80s and 90s, you might have heard about Supply-Chain Integration or Total Quality

Management. These were corporate movements also based on Lean.  A version of Toyota’s approaches  have been central to GE.  (Remember the Six Sigma jokes on 30 Rock? Jack Donoughy is Lean!) Lean has even been employed in software – for over a decade! Lean Startup is the latest addition to the family. 

There are a few key principles at the core of Lean Thinking, and they manifest differently in these different contexts. Three central principles to Lean Startup are the goal of minimising waste, the culture of continuous improvement and the importance of measuring the big picture. These underpinned Toyota’s innovations and echo all over the Lean Startup world in different ways. 

Lean Startup and Customer Development 

Before Eric Ries was a talking head, he was a startup founder in his own right. He co-founded a chat startup called IMVU in a technical role, and there he found Lean Thinking unhooked a lot of pervasive problems. (IMVU, like many Lean Startups, had a killer growth engine but was largely unknown outside of its target market.) Eric was a student of Steve Blank, who had risen to fame by seeing e.piphany to an IPO and was now an investor and teacher at Stanford. 

Steve himself was also a startup iconoclast. As he was hustling for e.piphany in the 90s, he had noted that the conventional startup thinking at the time was basically, close your eyes and put the pedal to the metal. He moved towards a more customer-savvy approach, even when faced with the long cycles of enterprise sales. Customer Development was born. 

This is where concepts start to overlap. Eliminating waste sounds great in principle, but how you define waste matters. Both Eric and Steve had noticed there was a lot of waste, both in product development (building stuff customers won’t use/buy) and in marketing it to those customers. 

In the early days, Eric had defined Lean Startup as a combination of Agile and Customer Development, and building on pre-existing systems to eliminate redundant effort, but as he and the community evolved, it became clear that there were a range of approaches, both nuanced and radically different, that were also useful in pursuing these Lean principles in startups. As Lean Startup gained popularity and broadened conceptually, these concepts started to be repurposed to a wider range of startups and businesses. From there, Eric wrote The Lean Startup.

Lean Startup and Agile 

Agile was a pre-existing movement in the software world that focused on continuous or fast-cycle releases of code to users, working together face-to-face and other principles. Agile is where the idea of iterative development comes from.

It’s worth noting that quite of few of these fundamental principles are different from Lean. There is often a tension between Agile and Lean, and unless you’re dealing with an old expert who’s sick of the holy wars and understands it’s all about context, you’ll often see a bias.

Lean Startup and Business Models 

Meanwhile, in a far off land called Europe, well beyond the borders of Silicon Valley, Alex Osterwalder was tackling the non-sensical aspects of “business models.” At the time, it was a buzzword that had no common definiton, and at best stood for complicated financial spreadsheets that MBAs and analysts would produce. 

Alex had started this a decade earlier, with his PhD focusing on finding a common framework for understanding and communicating business models. He then started to create the discipline of business model design – bringing know-how from the design world to the grey boardrooms of all kinds of companies, from startups to multi-billion dollar corporates. 

One of the biggest outputs of this work, polished from a decade of inputs from many directions and a purposefully diverse community, was theBusiness Model Canvas. It was the first big picture tool for businesses that allowed easy understanding and communication of business models. It became a common language between different business communities and disciplines. (And completely independently of Toyota, Alex arrived at business model design approaches that most closely resemble Toyota’s design process – wide, lo-fi prototyping to explore the option space, followed by convergence.) 

By 2010, there were only a few people deeply connected to both Lean Startup and Alex’s work with Business Model Generation, and Leancamp in London was the first time the communities came together. From that, there were a slew of canvas variants, first The Startup Toolkit by Rob Fitzpatrick, thenHackFWD’s application system created by Tom Hulme of IDEO, and then theLean Canvas created by Ash Maurya. Each was focused on a more specific context for the canvas, but the trade-off is the well-rounded, big picture perspective and a large chunk of the canvas-based techniques that have emerged from the community over the decade.

Customer Development and Business Models 

In Steve Blank’s first book, Four Steps To The Epiphany, the business model section was a vague single page, but purposefully so. I’ll paraphase – once you know you’re solving a real customer pain, make sure your business model will make you money! 

Steve had yet to find a robust way to describe how to do this. As the momentum followed from the Lean Startup and Business Model Generation communities  coming together, Steve and Alex were drawn together as collaborators – turning into an eye-opening duo. Their work led to Steve’s updated book The Startup Owners’ Manual, Stanford curriculum, the reworked Startup Weekend Next, and more.

Lean Startup and User Experience 

The User Experience (UX) Design community had also been growing in it’s own right, independently of startups in general. UX is a natural evolution of product management, ethnography, industrial design and software usability, and has a massive arsenal of tools and techniques for understanding customer needs and designing solutions for them. 

There were two catalysts of this connection – Leancamp in London, and LUXr in San Francisco.  Leancamp was actively connecting the UX scene to the Lean Startup world, and was steamrolling onto a colossal community mashup. Leancamp co-founder Nicky Smyth from BBC R&D, was inviting many people from the local design community to join the conversation.

This was no easy feat, as the feeling at the time was that Customer Development and UX were competitive. UXDs would claim that they were already doing Customer Developent, and startup founders were still skeptical that anyone who called themselves a designer could be of strategic value. The inclusive attitude of Leancamp prevailed! This lead to our invitation to share with the first European Agile UX retreat by Johanna Kollmann and Anders Ramsay. (I’ve personally found Johanna’s work has since proved to be one of the most practical bridges between UX and Customer Development.) 

Meanwhile in San Francisco, Janice Fraser, an Adaptive Path founder, got a call from an investor friend who had a few startups that “need UX help and love this Lean Startup thing.”  Janice designed a short program for those few founders, which was the precursor to LUXr.  LUXr now runs regular Lean UX intensive program for startups in SF and New York. 

The Leancamp and LUXr crowds were quickly connected through Agile UX community, but we’ve still barely tapped the potential of repurposing UX techniques for startups, and bringing startup know-how to other areas of UX.  Most of what we see today is the Agile UX world becoming more Lean – moving towards techniques that are lighter, more accessible, and help with bigger issues than those related to the product.

There are also different versions of Lean UX, some which have very little to do with Agile. Ian Collingwood in Barcelona has a Lean Usability method, for example, that always keeps the team on the biggest problem. 

This is a big space – there’s more to come.

Lean Startup and Innovation Accounting 

In the early days of Lean Startup, Eric and Dave McClure were a hilarious duo.  I met Dave McClure at the first Lean Startup Smackdown in a basement bar at SXSW, where a foul–mouthed Dave would play bad cop to Eric’s good cop – dishing out rapid-fire abuse at startup founders who were wasting their time by building stuff without input from their customers. (Dave picked on me first, dragging me on stage and asking me the definition of Lean Startup, but not realising I was the guy who had written the wikipedia page on it. When he couldn’t fault my answer, he promptly told me to fuck off and forgot me!) 

At the time, Dave was fast-becoming the most prolific angel investor out of the Paypal Mafia, largely because he had identified 5 simple, big picture measurements that startups could use know if they were on the right track, which he called Pirate Metrics. Like many of us, he discovered Eric’s Lean Startup view and saw that it put Pirate Metrics in a robust and easily understood framing.  Pirate Metrics was a natural fit with the Lean Startup ideals of measured improvement, and big picture understanding. 

But Eric realised we were scratching at the surface of something far broader, a more practical way to look at startup numbers in general. He expanded the scope, defining Growth Engines and Innovation Accounting. 

Dave went on to create the 500 Startups accelerator. 

Making the pieces work for you 

Eric has been a great convenor of the Lean Startup movement, building bridges and being very inclusive, even in circumstances where he was challenged. (You’ll notice, for example, that his book The Lean Startup is very high-level and communicates concepts and principles over process, while Ash Maurya’s Running Lean is criticised for being dangerously prescriptive. Yet, they still collaborate.) I think this inclusive attitude has largely allowed us to draw from the best of many worlds, and I expect the future of Lean Startup will continue with connections into many other spaces. 

I have had the luxury and honour of meeting and working with many of these leaders through Leancamp. Everyone who I’ve engaged with is someone who is actively trying to improve entrepreneurship for everyone and they’ve made huge personal contributions. 

They don’t all agree with each other. That leaves us with the responsibility of understanding their priorities and the weight they place on various concepts. Otherwise, we run the risk of misunderstanding and misusing their approaches, or using the wrong tool for the job. 

I’ll leave you with 3 thoughts: 

1) As you pick up tools to get your startup to traction and beyond, it’s worth taking a little extra time to understand your options, when they’re best used, and the trade-offs between them.  First, seek to understand. 

2) This stuff has been super-useful for many founders but the most useful way I’ve seen to take it onboard has been to understand the big principles, and make it your own in a realistic way. (I think Giff Constable and Rob Fitzpatrick are the best exemplars for not over-engineering things, keeping it simple and actionable.) 

3) The Lean Startup journey doesn’t stop here! With Leancamp we’re reaching out to new communities so we can learn more from each other. I’m looking at these 9 areas for the future  of Lean Startup – ranging from Disruptive Innovation to psychology – to bring us the next evolution of entrepreneurship. 

Original Post –  http://www.saintsal.com/2012/12/the-history-of-leanstartup-and-how-to-make-sense-of-it-all/