Sunday, February 2, 2014

Building business sustainability: why Agile needs Lean Startup principles?

In his book on leadership titled On Becoming a Leader, Warren Bennis wrote: "Managers do things right while leaders do the right thing". This quote can help explain why Agile needs Lean Startup principles.

Toward Product Leadership


Lean Startup is about Product Leadership. In business, the ultimate goal of the enterprise is to eventually generate revenue and profit and that requires having enough customers who are willing to pay for a product or service. This is the key to sustainability in a free market system. The concept of the Lean Startup was first introduced by Eric Ries in his book titled: The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Steve Blank wrote an article in the Harvard Business Review last year titled: Why the Lean Start-Up Changes Everything.

Agile is about the management of Product Development. When applied properly using techniques such as Test Automation and Continuous Delivery, Agile (and its various flavors like XP, Scrum, or Kanban) is a proven methodology for successful software delivery. However, a purely ceremonial approach (daily standup, sprint planning, review, retrospective, story pointing, etc.) may not yield best results.

Having the best software developers in town and building a well-designed and well-tested software on time and under budget will not necessarily translate into market success and business growth and sustainability. So what is the missing piece? How do we ensure that Agile is delivering a product that users are willing to buy? How do we know that the software itself and the many features that we work hard to implement every sprint are actually going to be needed, paid for, and used by our customers?

How Agile projects can become big failed experiments


Agile promotes the use of cross-functional teams that include business users, subject matter experts (SMEs), software developers, and testers. There is also the role of Product Owner in Agile teams. The Product Owner and the business users help the team define and prioritize backlog items. The issue is that most of the time, neither the Product Owner nor the business users are the people who are actually going to sign a check or use their credit card to buy the product. This is the case when the product will be marketed and sold to the market at large. Implementing the wrong design and building the wrong product can be very costly to the enterprise. So the result is that the design and the features that are being implemented by the development team are just assumptions and hypotheses (by so called experienced experts and product visionaries) that have never been validated. Not surprisingly, many Agile projects have become big failed experiments.


Untested assumptions and hypotheses


What we call vision and strategy are often just untested assumptions and hypotheses. Yet, we invest significant time and resources pursuing those ideas. A deep understanding (acquired through lengthy industry experience) of the business, customers' pain points, regulatory environment, and the competitive landscape will not always produce the correct assumptions about a product. This is because the pace of change has accelerated dramatically over the last two decades.

Traditional management processes and tools like strategic planning and the Balanced Scorecard do not always provide a framework for validating those assumptions. Even newer management techniques like the Blue Ocean Strategy taught by business schools to MBA candidates contain significant elements of risk and uncertainty when confronted with the brutal reality of the marketplace.

This reminds me of my days in aviation training. Aviation operations are characterized by a high level of planning. The Flight Plan contains details about the departure time, route, estimated time enroute, fuel onboard, cruising altitude, airspeed, destination, alternate airports, etc. However, pilots are also trained to respond effectively to uncertainty. Examples of these critical decision points are the well known "Go/No Go" decision during takeoff and the "Go-Around" during the final approach to landing. According to the Flight Safety Foundation, a lack of go-arounds is the number one risk factor in approach and landing accidents and the number one cause of "runway excursions".


The following is how the FAA Airplane Flying Handbook describes the go-around:

The assumption that an aborted landing is invariably the consequence of a poor approach, which in turn is due to insufficient experience or skill, is a fallacy. The go-around is not strictly an emergency procedure. It is a normal maneuver that may at times be used in an emergency situation. Like any other normal maneuver, the go-around must be practiced and perfected.

 

Applying Lean Startup engineering Principles


A software development culture that tolerates risk-taking and failure as a source of rapid learning and growth is actually a good thing. The question is how do we perform fail-safe experiments early and often to validate our assumptions and hypotheses about customers' pain points and the business model (how money is made), quickly learn from those experiments, and pivot to new ideas and new experiments until we get the product right? The traditional retrospective in Agile usually involves discussion about what went wrong and how we can improve with a focus on the activities performed by team members. The concept of pivot in Lean Startup engineering is different. The pivot is about being responsive to customer feedback and demands in order to build a sustainable and resilient product and business. The pivot has significant implications on the architecture, design, and development of a product. As Peter Senge wrote in his book titled The Fifth Discipline: The Art and Practice of the The Learning Organization:

The only sustainable competitive advantage is an organization's ability to learn faster than the competition.

The Lean Startup recipe is to create Minimum Viable Products (MVPs) that are tested early and often with future customers of the product. An MVP can be created through rapid prototyping or by incrementally delivering new product features through Continuous Delivery, while leveraging cloud-based capabilities such as a Platform as a Service (PaaS) to remain lean. Testing MVPs requires the team (including software developers) to get out of their cubicles or workstations and meet with customers face-to-face whenever possible to obtain direct feedback and validation. MVPs can also be tested through analytics, A/B testing, or end-user usability testing. Actionable metrics like the System Usability Scale (SUS) should be collected during these fail-safe experiments and subsequently analyzed.

These fail-safe experiments allows the Product Owner and team to refine the product vision and business model through validated learning. Lean Startup principles are not just for startups. They can also make a big difference in established enterprises where resource constraints combined with market competition and uncertainty can render the traditional strategic planning exercise completely useless.

No comments: