Posted on 01 Oct 18 by Brian Poleykett – Director, Projects & Planning
This is the second in a series of Blog posts focussed on how KZN Group prefer to deliver projects. Start with my first post on Understanding Agile.
Many of our customers have heard of Agile but few truly understand how an Agile project - one which adheres as closely as possible to Scrum whilst embracing Lean - differs from the traditional “waterfall” project they may be familiar with.
In this post I’ll introduce the concept of Lean and explain how it works with Agile to deliver the maximum value in the shortest time.
Lean is a systematic way of working which strives to maximise customer value while minimising waste. Although its origins lie in the physical manufacture of cars in Toyota’s factories, Lean thinking has now been adopted in many diverse industries.
In order to be eliminated the waste must first be identified and measured. Utilising the scientific method a hypothesis is drafted, a plan formulated then executed, and the outcome measured and reviewed. The individual parts of a process must be optimised as well as the overall process flow.
There are many excellent resources on the Internet which provide insight into Lean’s origins, its philosophy and practice. I’ve provided a bibliography at the end of this post if you’re keen to learn more.
In this Blog post I want to describe how Lean and Agile make a perfect pairing, and how to approach a Lean-Agile project.
Agile is by definition a Lean methodology. Both Agile and Lean strive for continuous improvement, to identify opportunities to streamline work and eliminate waste. In an Agile methodology such as Scrum a ceremony is held at the end of each and every Sprint, the Retrospective, whose very purpose is for the team to reflect on their own performance in order to identify where incremental improvements in process can be made. Scrum does not assume that all members of a new team are equally knowledgable, or equally experienced, and provides the Retrospective to allow teams to storm and norm until they perform.
However this overt focus on continuous improvement during the Retrospective often distracts from the other ways Scrum is Lean.
The Scrum Guide states that Scrum employs an iterative, incremental approach to optimise predictability and control risk. The Scrum Team deliver products iteratively and incrementally, maximising opportunities for feedback.
Incremental and especially iterative delivery of a project’s primary and intermediary products is inherently Lean. Delivering only part of, perhaps a simpler version of, a feature or product gives everyone - developer and Product Owner alike - the opportunity to learn by doing. Future Stories can be written which refine this outcome.
By taking these incremental and iterative steps, waste is eliminated in two ways:
Lean Startup is a variant of Lean focussed on building nascent products and bringing them to market. Its focus is to answer the question: Should this product be built? Lean Startup promotes the build-measure-learn loop, a variant of the continuous improvement cycle mentioned above. However in Lean Startup the focus is not at the feature or function level as described in the previous section but views the product as a whole. How much of the product do we need to build in order to learn from our customers what they value and what they do not? The answer is the minimum viable product or MVP.
The textbook definition of MVP is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Once again Scrum’s incremental and iterative nature fosters thinking about the MVP. What functionality must the product have in order to be useable by any customer? Are we uncertain of the value of any functionality, and if so how do we provide just enough to determine whether our customers will use it? These features are candidates for the MVP. Any feature which does not aide in our goal to learn about the customer’s needs is not MVP and is therefore deferred to a later release.
The MVP should be viewed as an experiment, with the hypothesis that features offered by the MVP can be built, and are valued by the customer. The experiment needs methods; actions to be taken and measures to be gathered which will be analysed to determine whether the hypothesis was true or false. An MVP should not be released to customers and promptly forgotten as the Scrum team moves onto building the next release. The lessons learned from the MVP need to be collected, analysed and fed back into the project backlog as soon as possible. Only then will the team know whether to focus on a new feature or to iterate on a previous one which was poorly received.
I believe the concept of the minimum viable product is poorly understood. In their hearts most customers hear “minimum viable product” but think “minimum marketable product” or MMP. The MMP is a similar concept to MVP but it delivers a product with “just enough functionality to be viable – to launch, market and sell the product successfully” (Pichler, 2011). The emphasis is not on learning about the customers’ needs but instead on producing a product which can be advertised and sold.
Roman Pichler in his article “The Minimum Viable Product and the Minimal Marketable Product” suggests there is a relationship between the two, that one or more MVP releases could occur before the product is considered to be MMP. Only at this point would advertising begin.
What does this all mean for those embarking on an Agile project using Scrum and guided by Lean? My recommendation is to keep the following pointers in mind:
Applying Lean thinking to your project will help you maximise value whilst minimising effort. Sometimes it’s a challenge for those working closely on a project to step back and take a pragmatic and Lean view of what needs to be achieved. KZN Group can offer consulting services to help you get started on your Agile journey, or to refocus an existing project. Get in contact, we’re happy to help.