I attended a talk by Natalie Hollier back in September on Lean Product Management for Enterprises: The Art of Known Unknowns, when I saw a slide from her presentation that blew my mind.
It wasn’t that the slide had beautiful visuals or fancy transition effects, but what it had was a simplicity on how it communicated on a high level the differences between the 3 most common product development processes: Waterfall, Agile and Lean.
This image/slide was so great, I had to ask Natalie for it, and luckily she sent it to me asap!
Without further adieu, here it is…
*wipes tears* Isn’t it beautiful?
One of the main differences between the three processes, and arguably the most profound and distinguishing difference, is when the product gets into the marketplace when creating a new product. With both Waterfall and Agile, the customer/stakeholder/end user gets the product at the end of the project – so essentially you have to build the whole product using these two processes.
However, with Lean you are mostly focusing on building a small subset of features (hopefully the most critical features) and getting that MVP (or mini-product) to your customers and the market a lot sooner. The quicker delivery helps Lean eliminate more potential waste than Agile as you’ll be able to get a quicker reading if your building the right product. If you aren’t, then you can abandon ship sooner thus saving two precious resources: time and money.
Another insight I got from this slide was that the Lean product development process is a very very very scaled down Waterfall project IF you look at it on a phase level and not at a deliverable level as shown below:
In Lean, you usually release an MVP at the end of the cycle but you have to go through a number of steps first, similar to Waterfall. Now of course there are other differences in these three product development processes, but we’ll leave that discussion for another time.
UPDATES: Changed the first image to reflect Market feedback instead of customer feedback (you should always be able to get customer feedback), and edited article to reflect getting product into the marketplace (12/2).
I don’t understand why the picture doesn’t show Scrum getting customer feedback more often. Every sprint has a Sprint Review where customer feedback CAN be obtained. Even in the diagram it shows releases and those are certainly times when customer feedback can be obtained.
It appears someone is deliberately saying the Scrum implementation is just “dumb” and not using any sort of intelligence at all. Just because there is nothing that says “get feedback here” doesn’t mean it shouldn’t happen. In fact it should and does for any reasonably effective Scrum Team.
I don’t think anybody was trying to make Scrum seem “dumb”. I apologize if that was the case. I love Scrum and want to take a deep dive into it to help my companies use it effectively instead of “ceremonially.”
I believe the image is representing the case where you are starting a new project, so if you look at Scrum case, customer feedback and market feedback will usually come at the end since you are developing a larger product than you would with Lean.
Lean has feedback earlier because you developing smaller product – you are concentrating on the fewest features possible to have a working product. You can definitely do the same with Agile, I actually recommend doing your product development using Lean and your software development with Agile to get the best of both worlds.
If this was a project on improving an existing product, then customer feedback in Scrum would come a lot sooner as you pointed out.
In a way you could say comparing Lean and Scrum is like comparing apples and oranges.
Would love to get more of your thoughts on this.
I’m with Bob on this one. With agile, I’d go to the customer as soon as I had something that they’d be interested enough in to give me feedback. That may be at the end of a MVP development or may be earlier-on with a look-and-feel. I’d be really interested to hear your apples/oranges comparison of Lean and Scrum.
I would agree with Bob to the extent that Scrum has a high frequency of customer feedback – both during the iteration and at the end of each iteration in the form of a review or demo. Without this happening, it would be ‘Wagile’ – waterfall approaches with some agile-ish ceremonies / processes. In Scrum this an essential component to the success of the project because, without it, the team is basing the work going forward on potentially stale requirements.
In my opinion, the lean representation on the first is a direct reflection of Scrum. Also, the statement, “with Lean you are mostly focusing on building a small subset of features (hopefully the most critical features) and getting that MVP (or mini-product) into your customers hands a lot sooner. The quicker delivery helps Lean eliminate more potential waste than Agile as you’ll be able to get a quicker reading if your building the right product. If you aren’t, then you can abandon ship sooner thus saving two precious resources: time and money.” is a core focus of agile – make mistakes early, get minimum marketable functionality in the hands of your customer as quickly as is possible, and iterate to produce additional functionality.
I also agree with Bob. What in Scrum says you don’t collect feedback from customers? We use Scrum as a way to implement Continuous Delivery. In our environment, we strive deploy to production after each sprint. When i speak about Scrum, one big advantage is the ability to deploy often and get customer feedback in the loop.
May I add something here?
Scrum is meant to give the “Product Owner” the chance to deliver feedback and eventually to develop a better understanding about what options there are and how to get to the end result (in terms of KPIs) faster and more efficiently
The customer in a scrum process is the product owner, which for the lean people is kind of a dangerous shortcut, without getting real customers playing with the product and interviewing them, doing design research and getting their feedback, the product can’t be better
Scrum is really good to manage the friction between marketing function and other functions in the team…. while lean is the way to manage friction between the user (and its needs) and the overall organization
in case you are just building another classified ads platform… you can use scrum, if you are doing something more innovative, you need to put some real customer feedback in your process
Do you mind expanding on why in Lean it’s a dangerous shortcut when you said the following: “The customer in a scrum process is the product owner, which for the lean people is kind of a dangerous shortcut, without getting real customers playing with the product and interviewing them, doing design research and getting their feedback, the product can’t be better” ?
After taking your feedback and some of the feedback from the LinkedIn Discussion, I talked to Natalie and found out that she mentions market feedback in her talk but the slide doesn’t reflect that, so I’ve updated the first image in this post.
After even more thought, this comparison makes more sense for new product and feature development especially since new products have higher risk and Lean helps minimize the risk by getting the product out there sooner because it’s smaller. Would love to get your thoughts on this.
I would go further to say that whenever there is a star, it is not “customer feedback” (in the sense of talking to them) but actually having a product that you can sell to them. The first phase being a concierge MVP for example. I think that might differentiate it from SCRUM.
Definitely, and of form of validation that you can during customer development that shouldn’t be exclusive to Lean (but I’ve seen it more associated with Lean) is presenting your MVP (whether it’s a concierge service ( “fake it til you make it” prototype) is to ask if the potential customer is ready to commit money to it.
Long time no see. Seems like you are doing well 🙂
I am going to throw in my two cents here thinking that maybe what’s your impression of scrum/agile does was picked up at our previous workplace.
First of all, no two implementation of agile, scrum, or lean is the same. Some lean implementation also have very long cycles and some scrum and agile implementation have very short cycles and vice versa. If you look up some agile diagrams on google, I am sure you will find a similar one depicting agile implementation in the same way that this picture describes lean. In reality, the two are very similar. They are both about maximize customer value in the shorted time possible with high quality. The approach may be slightly different which makes each one more suitable to certain environment than the others. So, comparing agile and lean in such a way as depicted in the diagram above is simply wrong. Most agile coaches are emersed in lean as well, but I can’t say the same the other way around. In this case, it just shows the lack of understanding of agile by the speaker.
Bilel brought up a good point though, and it is used by lean practitioners to criticize the scrum approach of using a Product Owner as a proxy. This is definitely not as good as dealing with real customers. However, the reality is, real end user customer is not going to be readily available to a development organization in many cases. The concept of PO is a compromise to that reality. This is in fact a very good manifestation of a core agile spirit – adapting to reality.
Lastly, in practice, many agile implementations that I know of is done with lean approaches. Lean emphasizes on end to end system view and most agile software development frameworks focuses in the team space. The two can live in perfect harmony. In fact, that is the trend.
Happy to chat about more if you want.
Wow Patrick, it’s definitely been a while (since 2010?). Great to hear from you! To be honest, I didn’t even realize our former workplace was doing agile…but I was also on the PS and Framework teams which may have been different from the others.
I do understand the PO is a compromise as the customers are not always available, but as a PO/PM I don’t have all the answers, so it’s our job as the problem solving team to go find out the answers. The PO/PM is the customer advocate but isn’t the customer. Restating user stories as hypothesis helps shapes actions (features, etc.) into experiments and makes it easier to deem things a success/failure, but isn’t absolutely necessary – it just sets up the mentality.
I think at the end of the day, they can live in harmony but a hybrid approach could be best: replacing user stories with hypotheses when necessary, using agile teams (focusing on small teams, interactions over documents, etc.), focus on the critical aspects of the product to get it out – work in sprints to accomplish that, recognize the assumptions you are making as assumptions that you need to verify using your work.
For Lean to truly work as described, the customer taking possession of the market ready product better understand they will be very busy indeed testing a product often, otherwise Lean becomes Mean and all falls apart. I don’t see Lean being viable for every project, but could be very efficient for products that can truly be released in stages. For instance in manufacturing; Order Entry, Accounts Receivable, Inventory might be released before payroll, since payroll could be outsourced until available.
Agile makes some assumptions which may not fit all projects. It assumes there is someone, who can speak authoritatively about the requirements and the priorities of those requirements and act as the voice of the user. For many projects, the user community is diverse, often using products in ways not initially imagined, and having divergent use cases. It is often impossible to know the frequency and scope of these use cases without significant elicitation, analysis, and market or business use case analysis. This used to be called requirements gathering. It was hard work, took a long time, frustrated everyone, and nobody liked doing it, so we invented a process that eliminated it; called agile. Agile is good for simpler projects where there is someone who can explain the predominant user and system stories with some accuracy. The problem is, agile wants to eat the world and proponents often accuse everyone who does not follow it of being “old school” or behind the times. A more mature approach is to understand the tradeoff of speed, complexity, risk etc. of the various methods and projects and craft processes that take those things into consideration. For some organizations, one size may fit everything they do, but that is highly unlikely.
Great post. Wish I had landed here soon. Especially the visual is truly worth a thousand words.
What is the difference between customer and market feedback ? How would you define “customer” vs “market”
Thanks in Advance
Customer feedback is 1:1 feedback, so when you go an individual feedback to find out if you have the right design/approach/solution. I like to talk to at least 5 different customers before building anything.
Market feedback is a bit harder to establish as it’s how the world, or the market segment you’re targeting, feels about your product overall. Has the market adopted your solution once they hear about it? Are you able to retain them? Is your product spreading virally?
Hope this helps!