Jake, the business analyst who creates business requirement documents (BRD); Sarah, the program manager; Janice, the VP of product who is responsible for managing and delivering projects and products; and others at the bank headquarters are familiar with The Lean Startup. They read it and acknowledged the merits; practically, though, they saw little use for it in their own work, however compelling the concept. In their mind, the agile delivery framework that’s in place coupled with the innovation lab that implements Lean UX to learn and create consumer experiences are the manifestations of lean startup.
In another part of the world, the development team in India is using the scrum method, an agile delivery framework, to collaborate and complete the user stories (a.k.a. requirements) appearing in Jake’s BRD. The team has a Scrum Master who is similar to a project manager in some sense and yet different in the way she interacts with the team and motivates the team to improve. The system engineer in New Delhi, India is also the product owner for the team; he translates the BRD that Jake provided into a backlog of user stories.
The development team sees little of the London-based innovation efforts. Occasionally they interact with the Lean UX innovation lab team and an external lean consultant from Boston, creating features and functionalities from disparate assumption validation exercises.
However, these segregated efforts are not part of the bigger development effort on which the product delivery organization is focused.
In this process-filled environment, leadership assumed that they were covered, so to speak, and that the features and products developed would be consumer-delighting MVPs. They were not expecting the colossal failure that emerged from Jake, Sarah, and Janice’s efforts.
What I Read
Lean startup as defined and described by Steve Blank1 and Eric Ries2 is the foundation of what I refer to as business agility. The Startup Way provides the engine for the process of ongoing experimentation, validation of business hypotheses with customers, and using the validated learning to decide whether the next step is to pivot (try other products, solutions, target markets, etc.; there may be multiple types of pivots based on customer feedback) or persevere in the business they would like to pursue. This is a brilliant concept. However, success in each individual case depends on how thoughtfully it is implemented: whether the right experiment is performed to validate the most foundational hypothesis, whether the right customers were identified and the number of the customers was “just right” (not too many, not too few), whether the right questions were asked and the right conclusions were made based on aggregated answers. This is a combination of data science and business intuition, market knowledge and active listening. In sum, it’s an art and a science at the same time. Lean startup is the glue that holds all this reasoning, analysis, and customer experience together.
As an actual example from my experience, we called 100 random people on the phone (identified by Amazon Mechanical Turk) and asked them if they would be interested in a new super-efficient weight-loss pill. Over 80% responded that they would like to try it. When the pill was produced and launched into the market at a relatively low cost compared with competition, sales were less than 1% of prediction. Why? The answer is easy: “would you like to try” questions are theoretical and do not require commitment. Thus, if you ask a question whether someone would like to try a product or service, especially the one that makes them more physically attractive or socially accepted, who would say no? Besides, the questions were asked to MTurks who took a low-paid job to make an extra dollar on a research call like this one; this is probably not the right audience because it is unlikely that MTurks would have money to invest in purchasing a new weight-loss pill and even if they do, there is tough competition on the market for low-priced weight-loss products. All of this invalidates the experiment and makes its results misleading.
In a big data company I worked with, one of the lean startup teams wanted to validate the assumption that “small businesses want to grow.” You do not need lean startup coaches to understand that this is a wrong assumption because most likely every small business would want to grow. What needs to be validated are their pain points and barriers for growth. Do they have trouble finding customers and suppliers? What specifically is the problem with the suppliers? Are the prices too high? Is reliability an issue? Distance? Quality of their products? And in each case, you need to be specific to the industry, business type, customer types, possibly geography, demographics, and so on.
Have you recently tried to buy a paper atlas in a bookstore? A few years ago you would have prefered a GPS to a paper map. Today, smartphones have replaced GPSs with their navigation functionality providing more convenience at a fraction of the cost. Does it mean that the business is disrupting itself over and over again? What does it mean for large, well-established enterprises? What is the right way for established businesses to use technological advancements to their advantage and integrate innovation into business success?
Lean brings in the concept of value creation and elimination of waste as well as personal accountability for the outcome.
Agile brings in the concept of team-based (no longer individual) iterative delivery of value to the customer while staying customer-centric. However, most implementations I’ve witnessed tended to silo agile to product development and engineering in particular. The relationship between lean and agile is complex. Some agilists do not even see a direct relationship. Even those who recognize that the agile mindset is based on lean principles of value delivery, reduction of waste, and system thinking frequently have a perception that while lean is a manufacturing approach that focuses on minimizing costs by eliminating waste and improving process efficiencies, agile is just the application of the lean mindset to software delivery with a set of processes around it. This is only partially accurate because agile, and specifically Scrum, bring two important concepts into lean: incremental delivery and cross-functional team-based execution.
Scaled agile aligns values across the enterprise and introduces multiple value chains, thus eliminating cross-team conflicts of interest and unmanaged dependencies governed by relentless prioritization based on value delivery and organizational objectives.
Design thinking and Lean UX3 bring in customer-centricity and a concept of minimum viable product into delivery cadence.
Lean startup (or “the startup way”) combine these concepts by creating a cohesive framework of experimentation based on validated learning (a new implementation of the lean build-measure-learn loop) while using metrics to drive decisions.
According to Version One’s The 2016 State of Agile Report , common corporate challenges include slow product delivery, inability to manage changing priorities, challenges with delivery predictability and visibility, all closely coupled with low employee morale and multiple difficulties related to managing a distributed workforce across cultures and continents. I experienced similar challenges at the companies I worked for, which affected our ability to quickly deliver products that delighted our customers and thus impeded business success. Examples included migrating customers to new platforms, onboarding third-party vendors, consolidating sales assets globally, and renewing service contracts with customers; in each case, we identified a need to simplify, automate, and streamline the process and make it delightful and productive for our customers, internal and external.
What Happened When I Tried Implementing in Big Corporations
The organizations I helped to create a lean startup engine already had a myriad of frameworks in place. Many were using agile as a delivery method, on top of which they implemented a scaled agile delivery to manage multiple delivery teams. In an internal system transformation at a Fortune 100 insurance company, they called their scaled agile delivery mechanism “the factory” and each delivery team used scrum to manage itself. At the same enterprise, they had UX experts and a Lean UX delivery team that had its own development resources. In addition, there was an ongoing DEVOPS effort to enable faster delivery of results across operations.
This familiar landscape exemplifies the well-known silos that impede the benefits that supposedly emerge from the various frameworks. I experienced agile and Lean UX initiatives that impacted parts of the organization without improving overall business outcomes. I knew that we had to take a different approach when creating a lean startup engine; otherwise it would become another failed improvement effort. The challenge we had, though, was that lean startup discusses a vision of entrepreneurship but fails to provide a guiding framework of how to get there.
Best Pratice
There are common mistakes with Lean Pilots (Eric Ries has a similar concept called a “Golden Sword”). First, clear expectation-setting is very important. Since the roles of Product Owner, Scrum Master, and being a member of a cross-functional team were new to the Pilot crews, we needed to have clear descriptions of what was expected, the time they should allocate to the initiative, and the ownership they would take. There were regular team “stand-up meetings” (the term comes from Scrum) where everyone was expected to participate; the absence of a team member slowed down the whole team. Team members owned results as part of their team, participated in team demos (a showcase of their work every iteration), and held retrospectives (regular continuous improvement sessions).
The second frequent mistake is overworking team members who do these pilots on top of their daily jobs. The team member’s managers must agree to a predefined time allocation and restructure their current deliverables so that this responsibility doesn’t come on top of the person’s existing job, thus creating unsustainable pace for the team member. We set a clear expectation from the outset of who should do what and of how much time to allocate to each of the projects–and of course, anyone could say “no”. It was our responsibility to create a safe space where everyone had a choice to join a Pilot crew or not.
We also learned that people really love working as part of a cross-functional and cross-level team. Once I asked one of our corporate lawyers who had just gotten involved with one of the teams whether she enjoyed working with other people and about her experience as a Product Owner on a Lean Pilot. She said, “I have always worked in the same way, mostly on my own, but working in a team has turned my world upside down. It shows me I am part of something bigger.” That was a big eye-opener.
It’s also important to recognize the value of combining lean, lean startup, and agile as a way to enjoy the “best of three worlds” and to create a system in which rapid validation provides a better chance to solve company-wide problems.
Finally, never forget it’s the problem, not the solution, that we need to “fall in love with.” If this is the case, when someone at the top of the organization makes a suggestion, the team knows they can be as open as they have to be when determining the feasibility of the suggested solution–aware as they are of what the data is telling them. It’s what I call being data-inspired.
What I Learned As I Adapted the Concepts at Corporations
Avoid the silo trap.
Focus on business outcomes.
Connect current disparate initiatives into a bigger picture where lean startup is the engine.
When I introduced lean startup in organizations, I avoided the silo trap by providing an end-to-end vision. Rather than invest in lean startup as a separate value-promoting initiative, I focused on the business benefits of an integrative solution that included agile, scaled agile, Lean UX, design thinking, and other so-called legacy methods in place such as Six Sigma. I constructed a strategic operating model that abstracted the relationships between the various frameworks used in the organization.
As an example, at an insurance company I worked alongside the leadership team to integrate the various frameworks they had in place, such as Six Sigma, Agile Scrum and Kanban, Scaled Agile and Lean UX. They were contemplating introducing Lean Startup into the mix. We ideated and synthesized the unifying model and offered a comprehensive design of framework relationships and interface deliverables. We aligned the deliverables with the lean startup engine that was implemented.
Best Practice
What is your strategic operating model? Lean startup as a delivery mechanism can succeed only once a strategic operating model has been synthesized; otherwise the disparate silos frameworks will collide and clash, and the transformation will fail.
The following is an example of using this framework in a large big data company. This company wanted to research opportunities in streamlining processes, delivering results cross-functionally across multiple groups and departments. Another goal was to improve customer satisfaction and automate processes as much as possible. There were also ever-increasing regulatory requirements, like the European privacy rules on how data on businesses and individuals can be obtained and stored, which represented an ongoing opportunity for this business. The objective was to provide the highest value customer service in the most efficient way. The company created an approach of empowering employees in solution-finding while maintaining continuous and close relationships with the customers.
In this company, I launched a framework to deal with enterprise-wide challenges; we called it Lean Pilots. At first, we set out to apply lean Six Sigma principles and practices (it seemed the most natural structure for problem solving), but when we realized we needed a faster way to deliver change and an immediate feedback loop, we decided to introduce elements of agile. In essence, we ran bounded experiments with combining the two methodologies. Finally, we introduced lean startup ideas–a direct result of us realizing our aim was to learn as much and as quickly as possible from our customers.
Our Lean Pilot framework implemented lean Six Sigma DMAIC4 cycle at cadence using a Scrum framework. DMAIC is a data-driven quality strategy used to improve processes. It is an integral part of a Six Sigma initiative, but in general can be implemented as a standalone quality improvement procedure.
From the Scrum perspective, it meant that for every iteration (sprint), one or more high priority feature from the improvement backlog (may be related to business process improvement, process automation, or product enhancement) was implemented and then measured to define whether the result met Lean Pilot’s success criteria. This is where the lean startup experimentation concept came into play. If the measure brought performance to a predefined level, we persevered; if the result was unfavorable, the hypothesis was invalidated and the team pivoted the next sprint to implement the next highest priority measure. This provided a safe and fast way to fail and ensured high efficiency in validating any assumptions.
This combination, coupled with the cross-organizational and cross-functional nature of modern-day impediments, made this lean-agile framework so powerful.
The first step in the framework was the creation of a cross-functional team, to whom we gave the power to make decisions. To prioritize the work, we used lean (in particular, the Pareto 80/20 rule), while we relied on an agile framework Scrum to give the team the ability to define milestones and deliver value at regular intervals.
Tip
Brainstorm with your team to identify the biggest opportunities within your company where the Lean Pilot framework would be applicable. Get buy-in to launch such a pilot within your enterprise to apply lean startup principles in practice. Relentlessly prioritize and measure results as you go, and you will be surprised with the outcome.
Our lean initiatives were a join-by-invitation, which meant that we could spread the methodology organically across the business. Besides self-organizing team members who were empowered to plan and execute their work, we maintained two other Scrum roles: Scrum Master and the Product Owner.
Product Owners who were subject matter experts and influencers within the corporation led teams and prioritized the work that had to be done, in collaboration with a large group of stakeholders. Scrum Masters were servant leaders who supported the team from an execution perspective; they established the cadence, provided tools, maintained process, and removed obstacles of any kind to enable the team to deliver smoothly and collaboratively. Both Product Owners and Scrum Masters were well-respected across the business and could be considered change agents within the company.
Multiple business goals were achieved by the Lean Pilot teams. One of our Lean Pilots focused on contract automation and making doing business with us easier for our customers. We wanted to increase the number of contracts signed electronically, and indeed in five months we saw a spike in the number, from 31 to 56%. Another example was the vendor management process with decreased cycle time from vendor onboarding from 17 to 9 days in nine three-week sprints (“sprint” is an iteration in Scrum) and then going down to 6 (industry standard is 10). Other Lean Pilots included compliance, procurement, global rollouts, and the core of our business, the data. We then implemented this framework in optimizing the product launch process, from ideation and development to marketing and sales. There is no limit to areas where the Lean Pilot framework proves to be beneficial.
In sum, Lean Pilot provided a way for us to rapidly resolve internal inefficiencies and to provide long-term solutions. Normally, the Lean Pilots we ran were related to process inefficiencies, customer dissatisfaction, or multiple types of waste in end-to-end processes. In each case, these pilots included analysis and ongoing experiments performed by self-organizing teams and were measured in short intervals to decide whether the team should pivot or persevere, a direct link to the lean startup practices.
Best Practice
Value stream mapping is an undervalued lean technique that allows for alignment in addition to process optimization. It visualizes the “cost of delay:” the cost of not doing something vs. the cost of doing it. It helps to surface gaps in analyzing efficiencies and workflows (in other words, the whole process may take hours but handovers and related wait times take weeks and even months).