What is Lean Product Development?
So what is Lean?
Lean is a product development philosophy that revolves around cutting all of the unnecessary work or effort until you are absolutely sure you need to do it for your users or customers
Imagine you want to create pizza delivery company. What would you normally need to do to make it a real thing?
Buy scooters, hire drivers, put out some advertisements etc.
To better use resources, you could first do as much as you can yourself. For example you could use your car and drive the food to people's houses yourself. Though it is a lot of work to be done, you won't spend resources until you know you have to. It will happen when you will no longer be able to do everything on your own.

Basically this is the lean approach
Lean is not specifically for software. There is a process called Agile that is specifically for software.
Agile is a way of applying lean mindset to software development. When people from hi-tech say agile, they usually mean Agile Software Development, which is a sort of project management framework.
Agile is an iterative method to developing software, where we group things into small batches and do them in order to not waste resources
You are creating an app. You are writing down 20 features that you think are absolutely necessary for users to want to download your app.

Agile way to do it would be to research, design and develop only 2-3 features, then release them and see what users feedback will be.
Scrum and Kanban
are two very popular Agile software development methodologies or structures. You can think of both of these methods as guides to developing software in Agile way.
There are a lot of things about scrum. But the main four are:
1. Sprint Planning Meeting
Spring planning meeting is where you take the most important features of your product from the top of your product backlog and move it to your sprint backlog. Then you discuss and write down all the work that needs to be done in order to make those features a reality.

You put the work to project management software into things called tickets
2. Using tickets
In scrum, the work your team does is boxed into a timeframe called a sprint. Usually two weeks

During these two weeks, your team works on the tasks by taking them off the top of the sprint backlog and moving them to "in progress" and then eventually to 'done'. These are the tickets that are moving from column to column. By the end of 2 week you should complete everything from the sprint backlog. If not, those things go to the next sprint.

3. Stand Up Meetings
are small daily meetings usually held in the mornings. Why stand up?

The theory is that if you and your team remain standing and not sitting down then the meeting will be very brief and concise in general

Goal is for every team member to talk about what they worked on, what they work on now, what they are going to work on next. Most importantly they should bring up questions or requests for help.

4. Retrospective meetings
The team is gathering in the room and discuss:

What went well

What didn't go well


Like Scrum Kanban is just a framework for implementing Agile Software Development. Except it is not as strict in terms of meetings and times.
I guess you've all seen Kanban board before. Just a bunch of columns with cards on it which you can move from one column to another one to reflect the state of item.

But Kanban board doesn't mean Kanban process

Key concepts of Kanban
Kanban doesn't use sprints
You don't time box the work of your team into these two-three week periods
No sprints - means no sprint backlog. Only the product backlog itself.
Team just works on tickets, move it to done and take the next task of the product backlog. And this goes on endlessly
Kanban doesn't prescribe any particular meeting types
Kanban says that only a certain number of items can be in progress or at any given state at one time. How many items can be in each particular state is up for the team to decide.
is another software development methodology
It looks something like this: we take all 20 features that we want and we
research - design - develop - release them all at the same time
Doing things in Waterfall way may be risky because it can take a long time to develop all these features. Your competitors can start releasing similar product. Or you may find something new about user needs or market that would be difficult to implement. Or find out that users need something you didn't spend much time on, but features you paid most attention to are not needed.

So what Waterfall is useful for?