Little's Law and the Hidden Variable

Did you know there's a hidden variable in Little's Law, and that the traditional equation L = λW - is missing something?
Well, it doesn't tell you something important, and it used to bug me a lot until I could pinpoint it - so let's explore.

What Little's Law says

Quoting Wikipedia: "In mathematical queueing theory, Little's law is a theorem by John Little which states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system."

For example, if we take a restaurant - the average number of guests present (L) is equal to the average arrival rate of guests (λ) multiplied by the average time a guest spends in the restaurant (W).
Let's say, if the average arrival rate is 10 guests per hour (λ = 10 customers/hour) and the average time a guest spends in the restaurant is 30 minutes hour (W = 0.5 hour), then according to Little's Law, the average number of guests in the restaurant (L) would be 5 guests.

Sounds all good - so: what is missing?

When Little's Law doesn't work

A few years ago, I had a hunch that Little's Law was missing something: Imagine that our restaurant has 5 tables and one waiter who can serve 12 guests an hour. Guests take half an hour between getting seated and paying their tab.
Does Little's Restaurant follow the tradtional formula of L = λW, ie., W = L/λ?
Would a reduction of seats lead to guests dining faster?
Would a reduction of maximum dining time generate more guests, or would people dine longer if there were more guests?
Probably not.
Is Little's Law broken?

No. But it's missing something - it doesn't account for system capacity!

Fixing Little's Law?

This modified version of Little's Law accounts for capacity: L = λW / (1 - ρ)

Now, that alone doesn't make sense, so I need to explain this variable ρ:
ρ represents the utilization of the system, calculated as λ / μ, where λ denotes the average arrival rate into the system, μ is the service rate capacity of our system, i.e. the reciprocal of the average service time (1/μ = Ts), where Ts is the average time required to serve a single customer (note the difference between "service time (net time)" and "time spent in the system (gross time)" - it's critical!) The "hidden factor" that Little's Law hid in plain sight was the relationship between the average number of customers (L) and the arrival rate (λ) needs to consider the impact of utilization and system capacity on the system performance! In underutilized systems, an increase in arrival rates has no impact on queues - whereas in overutilized systems, a reduction in system load won't have a visible effect until we get close to the actual capacity limits.

Returning to our restaurant example: Our restaurant's capacity is currently constrained by our amount of tables. As long as we have empty tables, a reduction in customers will not speed up anything. As long as all tables are full, adding more tables to the restaurant won't slow anything down. This view is complete counter-intuitive with the original Little's Law - but it makes sense, even in real life. Oh yeah - at some point, the waiter will be overburdened. At this point, the system capacity is no longer defined by tables, but by the waiter. So it's still all about system capacity.

Some examples

Example values for our Restaurant

μ	λ	W	ρ	L = λW / (1 - ρ)
5	1	0.5	0.2	1
5	2	0.5	0.4	2
5	3	0.5	0.6	4
5	4	0.5	0.8	10 --> bigger than capacity!
10	1	0.5	0.1	1
10	2	0.5	0.2	1
10	6	0.5	0.6	8
10	7	0.5	0.7	12 --> bigger than capacity!
3	1	0.5	0.3	1
3	2	0.5	0.7	3
3	4	0.5	1.3	-6 --> negative!

What's important to note are the three invalid records: When the arrival rates get close to or exceed the system's capacity, the numbers "break down." The real-life effects we would observe here:

• When arrival rates start to approximate the restaurant's capacity, the number of guests present gets bigger than the capacity, which in fact can't be - these invalid numbers indicate that variability could cause a backlog (queue) to form at peak times which can only be serviced when peaks are over.
• Customers arriving to a full restaurant can't get serviced and might leave - i.e., the negative number hints at unserviceable demand, i.e. lost opportunity.

The important observation may sound trivial, but is often ignored in management: only when you have more seats than the arrival rate of guests can you avoid having to send anyone home. And the fewer tables, the more likely someone will have to wait. Which is why a WIP Limit of 1 is just as impractical as not controlling demand influx.

Conclusion

While Little's Law has its merit, and we've been using it for years in order to explain the relationship between throughput, cycle time and Work in Process - we can't use Little's Law to optimize our systems properly if we don't account for System Capacity.
Taking System Capacity into account allows us to predetermine whether increasing or decreasing WIP will have a significant effect - operating significantly below capacity is capacity waste, whereas operating above system capacity causes overload waste.
Thus, the "hidden variable" is more than just important to apply Little's Law - it's crucial!

Further reading

There's an interesting whitepaper by Dr. Little who also highlights the key point of my blog article: as arrival rates approach service rate capacity (as outlined in this blog article,) WIP and processing time skyrocket, "hitting a brick wall" close to the system's capacity as queuing overhead reaches infinity.

Strengthen your Daily Events

It doesn't matter whether you use Scrum or Kanban, on a team or program level - Dailies are (or: should be) always part of the package.

In general, it's a good idea to have a fixed slot on the calendar where everyone quickly comes together to keep each other synced. Still, the amount of Dailies can get overwhelming. And tedious, And boring. So what? Here's a suggestion for Dailies that doesn't rely on Scrum's standard "Three Questions":

Brief Information

Dailies are not the time for discussion.  They're for brief information exchange.
Be as concise as possible, provide only relevant information.
If there is something to discuss, focus on what it is, and keep the content discussion for later. Meet after with the people who find value in the conversation itself, so that those who aren't involved are free to do something that matters to them.

Don't mention Business as Usual

Nobody cares that you were "busy" or "working on", because everyone is!
And as long as you're following the agreed plan, that's not news, either.

Should you mention that you have finished one work item, and started another?
If you're using visual indicators of progress and your board is up to date, everyone can see what you're working on. And as long as that's doing just fine - that should suffice.

Cover the four areas

Instead of focusing on activity, try refocusing on things that were not agreed beforehand:

Changes

Did anything "outside-in" happen that makes further pursuit of the current plan suboptimal?
Did you have any learnings that make a different way forward better
Do you need to change the work, or the goals?

Exceptions

Did something unusual occur, for instance: does something take unusually long, are you running out of work, do you need unplanned support? Are there any execution signals that imply there could be an issue somewhere?

Whatever comes up that may need further investigation or wasn't part of your initial assumptions should be mentioned, because it will distract from your original plan.

Problems

Does something block your pursuit of your current goal, be it technical, organizational or procedural.

Which work item is blocked, and what is the impact of the blockage?

I like to prepare red stickies and just plaster them across the blocked item(s), so that everyone is aware that this item doesn't make progress.

Solutions

The opposite of problems - what is now unblocked, and can proceed as normal again?

Don't get into any form of detail how exactly the problem was addressed, unless multiple items were blocked and you need to be clear how far the unblocking reaches.

Be prepared!

Many Dailies are entirely "ad hoc", people just show up, and mention whatever is on their head.

Instead, try to be prepared for the Daily: do you have any BICEPS to share, and what's the best way to get the message across?

But ... I have nothing!

Yes, that's great. It means that you don't need to communicate anything in the Daily, because everything is on track.

And what if we all have nothing?

Then - cancel the meeting and continue whatever you were on to. You have more important things to do than interrupt your work to communicate trivialities.

And the social aspect?

If you want to use the Daily as a water cooler event, to decompress or whatever - you can do that. With the people who are interested. That should be part of the regular work, and not of a Daily, which is a cyclical Inspect+Adapt event to help you maximize your odds of succeeding.

Should we even have a Daily then?

That depends. In another article, I discussed that closely collaborating teams may not need a Daily. For all other teams, it's actually good if you don't need Dailies, yet still keep the fixed time slot just in case. The mechanism could change from routine daily to "on-demand" daily.

You could measure how often you need to have Dailies, which becomes a metric of how well you can predict your next steps, then use that to have a discussion of whether that's appropriate to your team situation or not.

CONWIP Kanban - implementing Covid regulations with ease

The Covid social distancing regulation forces stores to adapt new strategies of ensuring distance and hygiene are maintained while people go shopping.

Today, I discovered an application of Conwip boards in daily life - and people may not even recognize that they're doing it: because: there's no board.

Let's look at a supermarket, and visualize it as a board:

Stores have instituted a fairly robust process that ensures - given a normal, self-balancing distribution, social distance can be maintained, without much supervision.
They have merely reduced the amount of Shopping carts to become the Constraint on store capacity, and have set up a few extremely simple rules:

• No shopping without shopping car
• Don't get too close to other people in the shop
• Keep within the distance markers at the cashier

There are a few implicit rules that go without saying:

• If there's no shopping car, you have to wait until one becomes available or you leave.
• Bring back your shopping car after packing up.

The system self-balances and exercises full WIP control:

• If there are too many people in the store, there will be no carts left, hence no more people coming in.
• If a queue is forming anywhere, no carts will be released, hence no more people coming in.
• Once a queue is dissolved, carts will be released, allowing new people to enter the store.

I could immediately spot what's going on here: the store has adopted a type of CONWIP Kanban:

•  the shoppers are our Kanbans (WIP), 
• the carts our Replenishment tokens, 
• the amount of Replenishment tokens is our CONWIP limit
• the Constraint is defined by the store's size, and modeled by demand controlling through the CONWIP limit
• the Replenishment buffer is the cart pickup.
• The space between carts at the cashiers functions like a "Constraint buffer."
• That even ensures we're warned ahead when cashier is operating at or near capacity limit, and we can open another cashier.

You gain high control over the system and free real-time risk management on top - and you need neither a significant amount of time nor money to implement these type of changes!

11 tips for utilizing flow efficiency to boost performance!

Flow efficiency - the art of achieving (sometimes significantly) more without working more. It's the Holy Grail both of Lean and Kanban. How do you achieve it?

Here are 11 actionable suggestions to get started on your journey to maximum flow efficiency.

1 - Map your process 

Do you know what happens between the time when a work item begins, and when it ends? By definition, a "process" is "a series of actions or steps taken to achieve a particular end."
In Kanban, the idea of process mapping should lead to a Kanban board - where each action becomes its own column on the board.

During this exercise, it's specifically important that you "focus on the baton, not the runner".

Your process is not defined by how your teams are organized or who has which skillset - it is defined by the works items being processed. Hence, your process mapping exercise should not focus on having people describe their work, it should be described by looking at the flow of work.

An example process map for development work

2 - Make wait time explicit

At every handover in the process, the work item will most likely spend some time waiting before being processed. There are two types of wait time in the process: inherent to the activity (for example, an analyst waiting for an appointment with a user), and inherent to the process (for example, a refined backlog item waiting to be picked up by a developer). Initially, we are only interested in the wait time inherent to the process. 

Visualize them on your process map:

A process map with "WAIT" markers

3 - Visualize processing time

The next step is to use whatever data (or experience values) you have in order to label the process with corresponding times for each step - weighted averages are perfect, averages are good - even guesstimates are enough.

A process map with processing time annotations

4 - Act on Wait Time

The definition of flow efficiency is the ratio of wait time vs. touch time, so in order to improve our flow efficiency, we want to see what we can do about wait time.
The elimination of wait time will improve both our flow efficiency - and our throughput time, without changing anything in "how" anyone works on any item.

There will usually be one step in our process sticking out, where wait time is higher than with all other steps. This is where we can have the biggest impact with the least amount of change:

Our example process has a throughput time of 40 days - a single change could speed it up by 20%!

5 - Focus on Throughput

The troughput rate is the ratio of inventory (i.e. WIP) getting processed per time. Based on Little's Law, you have two big levers to improve your throughput rate: Reducing inventory - and reducing processing time!

What many organizations forget, though: you have another lever on throughput: increasing the amount of WIP passing through your system!
The easiest way to do this is to examine the process for blockages: anything that leads to started work items to not move smoothly and uninterrupted through the process.

It's very common for organizations to suffer from various other causes of bloackages - including, without limitation: waiting for people or events, lack of materials (e.g. environments), higher priority work passing by, interference of other processes etc.

Identifying the common places where work in our process gets blocked.

6 - Understand constraints

 A common theme in every organization is that overburdening the process constraint causes blockage. When we push more work into a step than can be completed, some of that work will natually be blocked due to lack of capacity.
Unfortunately, in complex knowledge work, it's often really difficult to know why the constraint is constrained. And even if we have that knowledge, it may not even help us - because that's an action upon touch, i.e. trying to change how people work in the hopes that more work flows through the system.

It's also extremely important to remember that "constraint" and "bottleneck" are not necessarily the same thing:

Our process has two "bottlenecks" - yet only one "constraint" that defines overall performance!

Looking at the Step throughput rates data will reveal which step is the real constraint, and which is an irrelevant bottleneck.

Our example process is constrained by deployment: if we improve development, nothing will get better!

It's extremely important to understand this difference, because if we improve upon a bottleneck that is not the constraint, we will just shift the wait time downstream!

7 - Reduce workload

Organizations that specialize in departments tend to focus exclusively on department performance, and even teams with specialists tend to focus on role performance. Both of these are entirely irrelevant, as the only important performance metric is the overall system's performance: process throughput!

Reducing the workload sounds absolutely counter-intuitive to specialists, yet it's the most important in improving flow efficiency: it reduces in-process inventory, simply by starting less work.
Stopping excess work leads to "the baton, not the runner" moving significantly faster - no magic involved!

All the local optimization performance can be eliminated without affecting process performance!

While this makes every person with cost center responsibility cringe, we have achieved a seemingly miraculous change: we are working less and still get significantly better throughput rates - for free!

Let's do some number crunching to make the case with an example:
Previously, we had an average processing time of 40 days - and an average of 40 items in progess.
That means our throughput rate was 1. While we are still producing 1 item per day, this little tweak reduces the in-process nventory, which means the average age of items stuck in process goes down. By eliminating 20 items stuck in process, we double the throughput rate - to 2, which means work now flows through our process twice as fast!
And this is where things get magical: We have moved from acting upon processing time to acting upon excess inventory: Throughput optimization has become our lever for performance.


Nobody works harder, many people have less stress - results stay the same, yet process performance has doubled!

8 - Redirect excess capacity

The reduction of "blind effort" leads to a lot of excess capacity in the organization - capacity that is now free for anything except starting new work!

A question I like to ask in coaching, "What overburdens the Constraint?" - let's trust for the minute that work at the Constraint is already done as well as humanly possible, i.e. "everyone does the best they can".

In many organizations, specialization and a "my job is done" attitude has led to people involuntarily (or unwittingly) pushing work elsewhere, until it eventually becomes a burden on the Constraint, where then blame is placed for poor performance.
We need to reverse this mechanic and instead ask, "What work is being done at the Constraint that can be done by someone else - even if it's significantly less efficient if done by others?"

This does not mean that, for example, we will tell analysts or developers to perform Exploratory Tests. Instead, analysts could prepare test scenarios and developers could create small semiautomation tools that allow testing experts to proceed faster, which means the Constraint has less work in order to achieve the same outcome.

Relieving the Constraint of work increases throughput while (almost) everyone is working less and nobody is working more.

9 - Set the right Constraint

In most organizations, constraints exist simply because they happened to be where they are. A common "solution" is to hire more people to work on the Constraint, until the organization grows to a point where coordination of all the work in progress becomes the constraint - oftentimes leading to shadow inventory that exists beyond the coodinators' horizon.

A much smarter tactic is to deliberately place the constraint where it makes sense:

The best way to place the Constraint is to ensure that the most precious asset of the organization (i.e. the rarest skill, the most talented people, the most expensive equipment) defines the capacity limits, then act accordingly.

This means that there is all of a sudden a "right constraint" - and it shouldn't move.

Add capacity to all steps that should not be the constraint to ensure the Constraint doesn't starve!

10 - Plan for idle time

While Lean optimization would call out for idle time as a waste, we need to reverse that thinking. 

A machine can easily be planned for maximum utilization. We can easily calculate upfront how many items a factory can produce per day, per month - and even a year ahead of time. We can then set up our plant in a way that we have just enough capacity to produce just enough output just in time.

Humans don't tick that way. Knowledge work is unpredictable. People can't spend 100% of their time focused on churning out output ... Something unexpected always comes up, whatever - you name it: "The high probability of low probability events" makes it impossible to predict accurately. And the last thing you'd want is 20 people not being able to work, just because one person isn't available - hence: the need to ensure the Constraint doesn't generate flow blockage!

The best way to make decent forecasts is to ensure that the deliberate Constraint doesn't get into an Overburden state even when an unexpected event happens: 

As counter-intuitive as it seems: the Constraint needs to be the opposite of a bottleneck - it must have excess capacity!

11 - Feed the Constraint

The step that feeds the Constraint should provide a buffer that is both small enough as not to accumulate blockage - and big enough to ensure the Constraint doesn't starve, i.e. become idle.

Provide a constant, sufficiently big stream of inflow of work for the Constraint to ensure the Constraint never runs fully idle - as that would reduce throughput.

A deliberate misappropriation of  dimensions - the step that feeds the Constraint must be able to do so!

Bonus - Change your mindset!

A common misunderstanding in Kanban is to have "Doing", "Done" columns for each step of the process. This presumes that "my work is done, someone else's problem now".

When we stop focusing on the runners and start looking at the baton, i.e. when we observe the flow of work instead of the efficiency of each activity, we can't maintain this kind of thinking.

A work item that is "work in progress" is, by the very definition of the word, "progress" never done. Either it's "in processing" or "waiting for further processing" (i.e. "not done"). 

Therefore, it's quite important to banish the term "Done" from all buffers in the process, because it supports the wrong mindset!

We need to understand that there is no "Analysis Done, Development Done, Testing Done" - only "waiting for Development, waiting for Testing, waiting for Deployment". And all of these "waiting for" columns kill our flow efficiency. Unlike traditional Kanban, where it's good to have low Column WIP and getting items into the "Activity Done" column as fast as possible is an aspirable goal, flow efficiency re-defines the goal: we don't want any buffer columns at all!

The one in front of the Constraint is inevitable, but all other buffer columns are actually problems asking to be solved!

Double Queues for faster Delivery

Is your organization constantly overburdened?

Do you have an endless list of tasks, and nothing seems to get finished? Are you unable to predict how long it will take for that freshly arriving work item to get done?
Here's a simple tip: Set up a "Waiting Queue" before you put anything into progress.

The Wait Queue

The idea is as simple as it is powerful:
By extending the WIP-constraint to the preparation queue, you have a fully controlled system where you can reliably measure lead time. Queuing discipline guarantees that as soon as something enters the system, we can use historic data to predict our expected delivery time.

This, in turn, allows us to set a proper SLA on our process in a very simple fashion: WIP in the system multiplied with average service time is when the average work item will be done.
This allows us to give a pretty good due date estimate on any item that crosses the system boundary.
Plus, it removes friction within the system.

Yes, Scrum does something like that

If you're familiar with Scrum, you'll say: "But that's exactly the Product Backlog!" - almost!
Scrum attempts to implement this "Waiting Queue" with the separation of the Sprint Backlog from the Product Backlog. While that is a pretty good mechanism to limit the WIP within the system, it means we're stuck with an SLA time of "1 Sprint" - not very useful when it comes to Production issues or for optimization!
By optimizing your Waiting Queue mechanics properly, you can reduce your replenishment rate to significantly below a day - which breaks the idea of "Sprint Planning" entirely: you become much more flexible, at no cost!

The Kanban Mechanics

Here's a causal loop model of what is happening:

Causal Loops

There are two causal loops in this model:

Clearing the Pipes

The first loop is negative reinforcement - moving items out of the system into the "Waiting Queue" in front of the system will accelerate the system! As odd as this may sound: keeping items out of the system as long as possible reduces their wait time!

As an illustration, think of the overcrowded restaurant - by reducing the amount of guests in the place and having them wait outside, the waiter can reach tables faster, there's less stress on the cook - which means you'll get your food faster than if you were standing between the tables, blocking the waiter's path!

Flushing Work

The second loop is positive reinforcement - reducing queues within the system reduces wait time within the system (which increases flow efficiency) - which in turn increases our ability to get stuff done - which reduces queues within the system.

How to Implement

This trick costs nothing, except having to adjust our own mental model about how we see the flow of work. You can implement it today without any actual cost in terms of reorganization, retraining, restructuring, reskilling - or whatever.

By then setting the work you permit within your system (department, team, product organization - whatever) to only what you can achieve in a reasonable period of time, you gain control over your throughput rate and will thus get much better predictability into forecasts of any type.

Footnote:

The above is just one of many powerful examples of how changing our pre-conceived mental models enables us to create better systems - at no cost, with no risk.

Why "Agile Development" will not solve your problem

Do we even need "Agile" to improve time-to-market, reducing cost and increasing success rates? After reading this article, you may have doubts.

Do these statements sound familiar to you?

• Software Development is too expensive
• We are lagging years behind the demand.
• Too many initiatives (projects etc.) fail.

The solution? Scrum. No, just kidding. Scrum doesn't have a solution there. Neither does LeSS or SAFe. Or XP, or any other "Agile Framework" that focuses on the development part of an organization. The solution rests in how we think about organizing our products long before developers actually get involved.

Too many "Agile Transformation" initiatives are focused on the output of software development and forget the big picture of the system in which they are operating. 

The Product Development Funnel

Take a look at this abstract development funnel. Every organization works somehow like this, while the slope of the funnel and the processes in each stage may vary widely. 

Let us examine the core concepts of this funnel.
To keep this article at least somewhat simple, let us equivocate "product" and "product portfolio" - because from a certain level of abstraction, it's irrelevant whether we have one product or an entire portfolio thereof: both capacity and capability are still finite.
Likewise, let us ignore the entire dispute around Lean/Agile vs traditional program and/or portfolio management, because irrespective of how you do it, you are still dealing with demand, choosing opportunities and prioritizing effort.

Customer Demand

Whether our customers are people out there on the market who purchase our product, or internal stakeholders of our product, there are always unmet needs. The amount of unmet needs that our product could meet is the amount of potential work that is still required, and that's potentially infinite - unlike our funding and capacity.

At the expense of taking a grossly oversimplified definition here, let us define "Marketing" as the effort invested into making others aware of potential needs and wants - and in return, becoming aware of what these are.

Oddly enough, even delivery is a marketing activity in some sense: as people use the product, they become more aware of additional needs. Hence, the old economic rule, "supply creates its own demand" ensures that the demand part of the funnel will never dry up in a well-run product. 

Development portfolio

Every demand that's deemed sufficiently important will eventually end up in some kind of portfolio, the known list of undone upcoming work. This is where the first stage of filtering occurs. Filter mechanisms include product strategy, economic viability or even internal politics. The specific reasons for filtering are irrelevant in this context.

Every item that lands in the portfolio will subsequently put stress on the development organization. In an odd twist of fate, the worse an organization's ability to manage the portfolio, the lower the satisfaction with the developed product will eventually be, irrespective of how good or bad development was.

The reason is simply because once the capacity of the development organization is exceeded, accepting further demand will not yield better outcomes.

Running Initiatives

Once a portfolio item has been scoped for development, it will become a development initiative. Organizations do have this habit of finding it easier to start initiatives than to complete them. Every initiative started will eventually result in one of three states: Live (successfully delivered), Dead (descoped without delivery) - or Undead (lingering in a limbo state where people are waiting for results that may never come).

Let's briefly examine Live and Dead: An initiative that goes "Live" is the only type of initiative that results in something called "Business Value", or even potentially positive Return on Invest. It's therefore highly desirable to get initiatives live.

A Dead initiative is an initiative that has been terminated before it has generated business value. Every cent spent on dead initiatives was waste. Completing an initiative with a negative ROI is just throwing the good money after the bad, so killing them is still the better alternative.

The biggest problem though, are neither Live or Dead initiatives - it's the Undead: An organizational culture that doesn't have the willingness to kill initiatives that have exceeded their life expectation will generate and accumulate undead initiatives. 

The problem with these undead initiatives is that they drain your organization's energy. People spend time and effort to work on and track the Undead, and this time isn't available to get other initiatives Live, so they turn otherwise healthy initiatives into Undead as well. Talk about Zombie Apocalypse!

The health of a product development organization can easily be measured by how many Undead Inititiatives they permit - every initiative ever started that was not clearly terminated or completed. The easiest, yet oftentimes most uncomfortable, fix to increase this health is by taking inventory and killing all the zombie initiatives.

Delivery Capability

The delivery capability is the one place where a common "Agile Transformation" focuses. The expectation is that somehow, magically, the adoption of daily standups, cadenced plannings, reviews and retrospectives will improve performance. It doesn't. (At least, not significantly - unless your developers are really stupid, which I claim they aren't.) And, on a more abstract level, the expectation is that this approach will somehow improve the ratio of met versus unmet demand. It doesn't.

It might look like a good idea thus to increase the capacity of the development process, i.e. add more developers or provide better tools and extra resources to make developers more efficient. It isn't.

What sounds good in theory often results in proportionately increased expectations: When development capacity is increased through additional funding, the organization will expect to be able to launch more initiatives - and thus, the problem persists. It might even get worse, but that's another story, to be told at another time.

Retrospectives and change initiatives focused on "how can we do better in delivering" might completely miss the point if the development organization is in a state of continuous overburden: the overburden will never go away as long as more demand enters the system than what can be delivered.

Everything these frequent events accomplish is that the constant pressure to deliver creates psychological stress and eventually developers burn out: Development performance may even decline!

Let's talk about waste

In this section, let us move backwards through the funnel, as the waste accumulates throughout the funnel, like a clogged pipe. We have to unclog it where the blockage is caused, rather than where it occurs.

Wasted development effort

What should developers spend time on? Developing working solutions, obviously. Yet, developers often spend significant portions of their time doing things not related to this. Let's take a crude tally:

• Status meetings for all those running initiatives.
• Especially the zombies.
• Task switching effort between those initiatives. 
• Waiting for input on an initiative.
• Catching up with changing requirements in an initiative.

The sum of all the effort invested into these items is the "low hanging fruit" in any optimization strategy. Reducing the amount of running initiatives reduces the amount of wasted development effort, thus increasing available capacity to get meaningful work done.

Kanban addresses this by limiting Work-in-Progress (WIP), although this only helps when we limit WIP at a higher level, that is: we must control the influx of initiatives, not the amount of development tasks, in order to gain any benefits.

Scrum addresses this by limiting the amount of items a team takes on during a Sprint - however, this is not a fix when more portfolio initiatives get started than completed: the consequence is an ever-growing product backlog. The problem is hidden, not solved.

In the ideal Scrum, the Scrum Team has full control over the entire product development funnel. Since this would require the organization to have moved from cost accounting to throughput accounting, from funding work to funding teams and towards an integrated cross-functionality that puts business acumen into the Scrum Team - this is a type of Scrum most organizations don't have. Again, this implies that the improvement potential then doesn't relate to delivery.

Coordination Waste

The second stage of organizational waste occuring in product development is the coordination of initiatives.  That's where we get project managers and matrix organizations from, and it's the reason why developer's calendars are cluttered with appointments. As every initiative has someone in charge, for simplicity's sake, let's call them "Initiative Owner". This initiative owner wants to be informed about what is going on and will take care that their initiative gets due attention.

If there is only one initiative, then all of an organization's efforts can focus on completing this one initiative.

Add another initiative, and the organization has to solve the problem of coordinating both the efforts between those initiatives - and to solve blockages in either initiative without blocking any other work. The effort required for these activities increases exponentially in complexity with each ongoing initiative. 

This coordination overhead would not even exist if there was only one initiative. The time and money sunk into coordinating parallel initiatives is pure waste.

At this point, we already need to ask the question why we see value in having multiple parallel initiatives - and why we believe that the value of starting another initiative outweighs the waste caused thereby. Likewise, we can ask the question whether the reduction of initiatives reduces the waste by a level that warrants deferring, descoping or even discarding one or more initiatives.

As coordination waste is multiplicative on outcome throughput, the lever of optimizing coordination waste outweights the lever of optimizing team-level productivity.

Budget Waste

Every organization determines one way or another what will be developed. Regardless if this happens via a Product Owner prioritizing an item in a product backlog or a SteerCo starting a traditional project, at some point a decision will be made to start a new initiative. In one form or another, at this point, the organization makes an investment decision: budget is allocated to the initiative. The biggest waste of budget is to start an initiative that doesn't get completed. Any initiative started without sufficient delivery capacity to complete both the currently running and the new initiative, will predictably induce waste into the organization. 

The simplest form of reducing budget waste is by deferring the decision about starting an initiative until there is sufficient free capacity within the organization to complete this initiative without impacting any other initiative.

As budget waste yields coordination waste, and coordination waste yields capability waste, the lever of reducing budget waste is even stronger than that of reducing coordination overhead.

Marketing waste

Probably the most well-hidden form of waste is demand waste, or "Marketing waste". Any form of demand that isn't eventually met by the product generates waste. The discovery, itemization and exploration of this type of demand generate cost without value. Having more demand than one can meet is only good because it creates options, yet one needs to be careful lest one loses focus in all of these options. There's even the economic dilemma of demand pull inflation where the mere prospect of additional demand will increase cost, but that's another story, to be told another day.

The simplest way of decreasing marketing waste is by limiting demand to a level where supply is at least still sensibly correlated to demand, and the organizational processes of managing demand are low effort. 

Marketing waste propagates into the product organization at full force: Poorly defined or invalid value hypotheses block scarce downstream capacity, while an oversupply of demand leads to pressure on the system. 

Limiting the waste

As heretical as this sounds, the most effective way of improving a development organization has nothing to do with improving development - and that's where all the team level agile approaches go wrong.

The most effective strategy for increasing effectiveness is by pulling the longest levers first:

1. Limit the amount of initiatives within the development organization. To achieve this:
2. Limit the influx of approved initiatives. To achieve this:
3. Limit the rate at which demand is translated into initiatives. To achieve this:
4. Limit the influx of demand into your organization.

"Do not try to do everything. Do one thing well."

- Steve Jobs

Here is an overview of what an organization's development funnel would look like if all settings were optimal:

The optimization in this context focuses on reducing the Organizational Waste not related to delivering Useful Products, and on the decrease of Opportunity Cost by eliminating the waste associated with pursuing low-value demand.

When we take into account Little's law, we realize that this optimization approach achieves:

• Reduced cost of meeting demands ("feature cost savings")
• Reduced Time-To-Market for features
• Increased Success rates of initiatives

Depending on how significant the associated waste and opportunity cost within an organization currently is, the leverage may be massive, while the organizational change (staffing, training, skill distribution etc.) is insignificant. All that's required is - thinking differently!

And the funniest part - we haven't even touched development!

Conclusions

1. Think about what you really need to optimize before looking at "Agile Frameworks" as a solution. 

2. Change your thinking before optimizing the work.

3. Optimize what you work on before optimizing how you work.

10 Bad reasons to choose Kanban over Scrum

"We're using Kanban instead of Scrum" - a common sentence, Especially since I do SAFe consulting, I hear this one quite frequently. Most reasons provided for this are anywhere between highly and extremely doubtful, and in many cases reveal ignorance both of Kanban and Scrum alike.

So here are my top 10 bad reasons for using Kanban instead of Scrum:

#1 - Our Consultant told us so

There's so much wrong with this sentence that it can't be fit into a single sentence.
First and foremost, if your consultant - after some short observations - knows your process better than you do, then you should seriously question what you're doing.
Also, a team should strive to be autonomous in decision making, and if your best reason for a decision is because someone else told you so, then you have absolutely no valid reason: you haven't understood what is best for your own good!

#2 - We had to choose

"Scrum or Kanban" is a false dichotomy. It's like saying, "Do you want a beverage or lunch?" - why not combine?
You can easily and very well combine Scrum with Kanban, as they address different problem domains. Whereas Scrum's primary concern is the nature of teamwork, Kanban focuses mainly on the flow of work. Especially Scrum.org has been investing significant effort in recent years to put together a "Professional Scrum with Kanban" curriculum which makes exactly this point.

#3 - 1 month is too short

A common argument I hear is that "we can't get anything Done in 4 weeks." 

Sorry to say, if you're not getting anything Done in 4 weeks, chances are you're not doing Kanban either. Kanban is flow optimization, and if you sit back content with a cycle time of more than 30 days when other development professionals can easily do 1 week (or less), you're just being lazy. 

While some organizations are indeed so impedited that everything is moving slowly, working relentlessly to make the problems visible and finding creative solutions to make progress is essential to succeed in the long term.

#4 - Our work is too complex

"We do really complex stuff here, much more complex than anyone else!" - Every team which has ever mentioned this argument to me was applying a "special pleading" fallacy, usually oblivious of what other problem domains look like. 

I will admit that Logistics is complex. As is social media, telco, fintech and science. Scrum is specifically made for complex problem solving, so that's simply not a valid reason.

#5 - Our stories are too big

This argument translates to: "We set up a board and put a sticky on that won't be moving for a month and call this Kanban," Well, I hate to break the news: it isn't. Kanban is about managing the flow of work, and a Kanban board where nothing is moving hides transparency and makes optimization impossible.

I remember working with a corporation where team members adamantly insisted that stories estimated to take 4-6 months were already atomic and impossible to split any further. We took a few items from their backlog into a workshop and a 6-month user story was decomposed into almost 70 workable, individual slices of value. The biggest could be delivered in a few days, some within hours. Unsurprisingly, the entire package of all relevant items estimated to less than one month!

#6 - Requirements from all sides

If this is your reason for not using Scrum, you're defaulting! One of the main reasons for having a Product Owner in Scrum is to solve the problem that everyone thinks their specific problem is Priority 1. Where a requirement comes from doesn't matter - there's always one thing that is the best thing to do right now. Even in Kanban, an understanding of what is the most important thing is extremely helpful in order to "stop starting, start finishing". 

#7 - Maintenance is unplannable

Teams which operate on a live system oftentimes get exposed to unplanned work - bug fixes, support tickets, maintenance and whatever. My first question here is: "Why is maintenance so high?" Could taking time off the busywork treadmill help fix systemic issues reduce the amount of maintenance? I have seen such teams who purposely shifted towards Scrum and taking just a fraction of their capacity to address fundamental issues - they benefitted greatly!

#8 - Requirements change too fast

To me, this begs the question: "Are you getting things finished before the requirements change?"

Usually teams answer, "No", and then I seriously question why you're doing what you're doing. Scrum might help you sort out what's worth taking into account, trashing all whimsical ideas that are forgotten faster than they were proposed.
Just as an added side note, Scrum's sprint plan isn't immutable: There is nothing in Scrum which prevents you from integrating new information and opportunities as they arise.

#9 - Too many meetings

Scrum's events all serve a purpose of inspecting and adapting - not losing focus or track in a changing environment. There is no reason for Scrum events to fill their entire timebox and there's no need to do them in a specific way.
As long as you know why you're doing what, get frequent user feedback, improve your process and outcomes and keep the team synchronized, you're quite compatible with Scrum. If you are missing out on any of these items, your problem isn't the amount of meetings!

#10 - We don't do User Stories

I have no idea where the idea originates that Scrum teams must use User Stories, estimate in Story Points, create Burndown charts or whatnotever. When your reason against Scrum is a practice such as these, the short answer is that Scrum is neutral to practice. Scrum is merely mentioning "backlog items". These can be stories, requirements, bugs, defects, ideas or whatever else floats your boat.
Some teams find value in the User Story approach, others don't. Some estimate in Story Points, others in ideal days, yet others in amount of backlog items. All of these are valid from a Scrum perspective, although some may be more helpful than others.

Wrapping up

The discussion "Scrum or Kanban (or both)" is quite valuable for teams to determine how they want to organize themselves. Unfortunately, the discussion is often not factual and highly biased. It is often led with huge understanding deficits both regarding Kanban and Scrum.

There are a lot more bad reasons for preferring Kanban over Scrum than mentioned in this article, and there are also some good reasons for doing so. When your team mentions any of the items in this post, it's good to be suspicious and ask probing questions. Most likely you will uncover that Scrum is just a pretext and there is something else going on.

Expose the root cause and deal with it, because otherwise, critical problems might linger unaddressed.

Do you really want high utilization?

Let's end the discussion about whether we should optimize for maximum utilization right here, right now - with a metaphor. Ponder your own answers for the questions.

Your features are the cars. Your teams are the lanes.

Lane 1 is optimized for maximum utilization (80%+).
Lane 2 tries high utilization (50%).
Lane 3 actively minimizes utilization (as close to 0% as possible).

Question: If your goal is to get from A to B as fast as possible - on which lane would you travel?

Question: What happens when a car suddenly needs to brake? (i.e. an impediment occurs)

Question: What happens when a car needs to enter your lane? (i.e. new information becomes available)

Transfer-Question: What is the fastest way to obtain business value in product development?

Concluding Question: Since minimal time-to-market maximizes ROI - which utilization strategy should you pursue?

Is you Kanban board healthy?

Have you ever stood in front of a Kanban board and wondered whether the team is actually doing fine?

Here we will discuss a few key concerns that will easily help you discern whether your Kanban board has problems:

What do you see on your Kanban board?

Broken Priority

When picking up a new piece of work, you should choose the top item on the board which is not yet completed. Sometimes people pick the item they prefer doing - ending up with lower priority items getting done first. The good news is that this becomes visible immediately.
If this happens frequently - or your Kanban board looks more like a dotted map than a flow system, you should seriously raise the question "Why do people not work on the highest priority?"

Unfinished Pile

The objective of Kanban is to get as many things into "Done" as fast as possible, where "Done" means "Delivered to the customer". Unfortunately, a wrong definition of "Customer" (e.g. "The next person down the line") invites team members to simply hand over an unfinished item, and work on yet another unfinished item.
When team members do not pick the rightmost "not done" item on the board, but rather any other, this should lead to the question "What prevents us from getting those things done quickly?"

Broken WIP Limits

Specialists often fall into a habit of simply working off their portion of a backlog item, completely disregarding what happens around them. This may cause an "Inventory" problem: The next step down the line may be clogged, with more and more undone work piling up.
Kanban suggests setting WIP limits on queues and stopping the production of ever more inventory before something new gets started.
Observing WIP limits makes it very easy to recognize when this point is reached. Sometimes, teams ignore this and individual columns on the Kanban start cluttering up. In this case, you should raise the question: "How can we avoid clogging this queue?"

Bottlenecks

Another problem of specialists is that they may be a limited resource in completing a specific step in the delivery workflow. If this is the case, we often observe that this step becomes a bottleneck: Some teams permit a huge WIP limit "because it's normal that a lot of stuff is there". Even worse, some abolish the WIP limit for such a step "because we always break it". A bottleneck should never be taken as irresolvable impediment.
When a bottleneck is observed, the team should be even stricter on setting a very low WIP limit. As this WIP limit is broken, this should trigger the question: "Can we re-organize work so that the bottleneck is resolved?"

Queue Mania

Some teams go crazy on Kanban boards - specifically, on electronic boards. It is very convenient to add a column whenever needed, because people feel it helps them organize their work better. Unfortunately, this fails to consider one underlying problem: Each column represents a queue, and each queue is actually a representation of a handover in the process. Handovers cause delay and are considered wasteful in Lean.
When you observe more columns on your Kanban board than you have fingers on one hand, you should ask: "How can we de-fragment our workflow?"

Summary

Starting Kanban is easy, customizing it is also easy. A Kanban board only visualizes what you are doing. To get real benefit out of Kanban, the layout of the board should continuously be put under scrutiny.
When the board looks unhealthy, the team should "stop and fix", using a Retrospective and define measures for Continuous Improvement. Only then will you get real value from doing Kanban.

Evolving Kanban Boards

Regardless of whether your board is electronic or physical, boards have a huge advantage of making workflows visible and making problems transparent without much overhead.

Here is a real world example of a electronic Kanban board. Let us discuss what this board actually means. As a disclaimer: This is not intended to be a pattern of "how your Kanban board should look like", but "how you could work on your Kanban board". Feel free ignore the detailed contents, because they are irrelevant to our cause in this article.

First thing you may notice: the board is a bit more complex than our usual "toDo, In Progress, Done" board.
This board has evolved over time and it is owned by the team. As such, it does not reflect "how the team should be working", but "how the team is actually working".

A little background

This board belongs to a cross-functional feature team, applying a rigorous Test-First Zero-Defects approach which mandates "no code change without test coverage" and "no deployment with known defects".
Consequently, there is no "In Test" or "Fix" column: Devising the right tests (e.g., "analysis") is as much part of software development as fixing any potentially discovered defects.
When the team moves a backlog item into "Done", it is unconditionally ready to go live.

An evolution journey

As the team discovered that the original 3 columns "ToDo, In Progress, Done" do not provide a sufficient level of transparency to understand at a glance what is actually going on and how they could collaborate, additional columns came in.

The first column that came in was the "to Review" column.
With this, a developer indicated that "My code is ready - from my perspective. I need a code review". Along with the Review column came the Working Agreement to always accept a review before starting a new Work Item. This was intended to minimize inventory.

When a work item was technically complete, the Product Owner inspects the delivered software and determines whether a go-live is a good idea. This may be by discussing with real users, with relevant stakeholders or simply by looking at the software on screen. In some cases, the item is so simple that simply trusting the developers to have completed the Acceptance Criteria is enough.
As the responsibility for this decision rests with the Product Owner, developers move tickets to "Resolved" when they have built Working Software ready for a demo.

The Review process became a bit more complicated, because this team is not  fully autonomous - they are part of a large scaled Scrum organization. Occasionally, the input of members from other teams became essential to maintain Collective Code Ownership. Because such reviews from other teams could take a while, the team created an [in] "Review" column.
The Source Code Management System (in their case, Stash) takes care of managing team external Pull Request reviewers and their feedback - but the ticket sticks "In Review" as long as essential feedback is still missing.

An organization problem sometimes made it impossible to merge fully tested, reviewed code: The Red Master.  Nobody is allowed to merge into a Red Master for any reason other than fixing the broken build - so the team introduced an "Pull Request Open" column to indicate work items that are just waiting to be merged into a Green Master.

Due to not only being a large scaled Scrum organization, but also due to B2B dependencies, the team quickly discovered that sometimes, they would be blocked based on external dependencies. They introduced an "On Hold" column to park any work item which they could not feasibly make progress on because they had to wait for an external party to complete their work. Examples for "on hold" would be, for example, an interface adaption in an external 3rd party software.

After introducing Kanban for a long time, the team encountered a new problem: They could pull work as fast as it arrived. However, not every request that was brought forth to the team makes sense. Any feature and/or information requests were parked on the "Backlog", for the Product Owner to inspect. The Working Agreement became that the Product Owner had responsibility to groom and refine stories in the Backlog before developers would pull them.

Had the PO decided the items would actually be an improvement towards the product vision - and met the team's Definition of Ready, the item would be moved to "Selected for Development". The Team's Working Agreement became that the team completely ignored the "Backlog" column, because it could contain worthless, incomprehensible or conflicting requests - or simply those which were misrouted in the organization.

Conclusion

The specific status model of a team's Kanban board must suit this specific team.
This article is not intended to provide a "better model", but to provide an understanding in the though patterns which can lead teams to evolve their board.

It is generally the best approach to start with a simple board. During Kaizen Events, you might then add columns when inevitable. Working with a complex board and not knowing how (or why) to work with it from the beginning is not a good idea.

This article purposefully omits the steps where workflow columns were added and later discarded because they were found un-necessary. That happens - and is actually good, because it means that people care and Continuous Improvement works.

What's better: Scrum, Kanban or XP?

The question "Which agile framework is the best?" is often raised by people who are fairly new to the world of agile frameworks. In short: I can't answer this question without asking a counter-question: "Best for what?"

 

 

When your only tool is a hammer, every problem becomes a nail!

Let me analyze the problem in regards to the image above.

Scrum: keep things in place

Scrum is primarily known for the sprint cycle process and the ceremonies: Grooming, Refinement, Planning, Daily Standup, Review and Retrospective.
Scrum discerns only the roles Product Owner, Scrum Master and Developer. You need a Product and Sprint Backlog consisting of Stories, in the latter broken down into Tasks.
You'll need to define suitable Working Agreements, such as a Definition of Ready and Definition of Done with your team, then use Inspect+Adapt on these rules to optimize your process continuously.

Scrum is quite rigorous. If you do not have any of these things, you end up with a disdained "Scrum-But". If you do something beyond, you usually also end up breaking your Scrum.

Scrum is a wonderful framework for creating structure, clarity and order. Additionally, Scrum reduces volatility, enhancing predictability and confidence.

Kanban: Create flow

Kanban is often confused with the Kanban board, the most notable artifact. Making work visible, creating a smooth flow of work as well as identifying and removing bottlenecks are all key factors of successful Kanban.

Kanban is very flexible. You can start with Kanban wherever your organization is, without interference to structure or process. From there, you start optimizing.

Kanban is a wonderful framework for making impediments visible and optimizing delivery.

XP: Professional Craftsmanship

Extreme Programming is mostly concerned with Engineering Practices. Techniques such as Pairing, Test Driven Development, Continuous Integration and Refactoring will lift your developers to new levels of excellence.
Design concepts such as Whole Team approach, Collective Code Ownership, Clean Code, Emergent Design will broaden your team's horizon and capacity.
Lean concepts such as sustainable pace, Metaphors, Small batches, Standards , Automation and Continuous Improvement reduce waste and risk.

XP is process-agnostic. You can pick individual practices from XP that solve specific needs in your team, although taking the batch is advised for best results.

Summary

None of these agile frameworks is "better". Each of them has a specific area of use. As such, the frameworks become "better for solving a specific problem". Therefore, you need to define your problem first before answering the question "Which framework is best?" - a hammer is better for fixing a nail, but not for a screw. Of course, you can cut a board with a screwdriver, but a saw would suit your need better.

Take some time, define your specific problem, then work from there.
Here are some rules of thumb:

• Solve organizational or process issues with Scrum.
• When you can't seem to get anything "done", try Kanban.
• When your perceive quality or architectural issues, apply XP.

These frameworks are not exclusive. You can mix them - and high performance teams combine them. Scrumban is famous, for instance.

Disclaimer: None of these frameworks will actually make you successful in the long term without an Agile Mindset. If you have issues with Agile Values or Agile Principles, your only fix is returning to the Agile Manifesto - regardless of which framework you're using!

Six types of Agile Products

We're Agile now. We don't need a Project Plan any more, we're freed from deadlines and we don't have to work off predefined requirement lists any more. Yay, this is gonna rock!

Let's go for it!

Not so fast, young Padawan!

Agilists don't abolish processes or planning. When we say that we value adapting to change over following a plan, it doesn't mean we don't plan!

Agile projects might be even more rigorous than any traditional project you have ever worked on!

They are set up differently. Nobody went out to obtain a $100m funding up front, "be seeing you in 5 years with the results". (And nobody in their right mind should fund a project like that!)

Agile's "Inspect and Adapt" follows the decades-old acronym "WYSIWYG": you get what you see. 

This goes both ways. The project will not continue to receive funding when there are no more results!

So, before you go out on your next hackathon, be prepared to deliver as much as possible at any point in time.

Agile products grow over time. There are four primary growth stages of agile products:

Seed - "We know what we want to produce, but haven't really started"

Startup - "Here is what we're working on"

Initial - "Go ahead and use it - we know there's still lots of things we must work on"

Mature - "If you want more, you gotta pay for it!"

In the seed phase, the stakeholders come together and define the product vision. At this time, we may have a project homepage and a project team, but nothing to show for. As a newly formed venture, we might go to Kickstarter, but we need a compelling reason why anyone should fund us.

Actually, unless we have some proof that we can do what we've set out to, chances are we won't get this funding. So, we need to produce something to get an initial taste.

There are three things we can do, we don't need to do all but we should pick our options:

The Mock Prototype will give the stakeholders and future customers something to connect our vision with something more tangible. It will give them an impression of what may one day be - and it will give us an impression of whether we're aiming in the right direction!

In the mock prototype, we'll usually resort to mockups and we might want to spend as little resources on generating it as we can. If we build some code from the mock prototype, we might even salvage some of the code for the final project - although I wouldn't count on it and in many cases even advise against it.
We may borrow apply techniques such as Rapid Application Development to put out one or more prototypes and determine what the product could look like.
As prototypes are built to be disposed after they achieved their validation purpose, if you spend weeks on a single prototype, your project is probably already dead, so we need to do this in a cost-effective and highly disciplined manner.

We leave the prototyping phase once we have a validated understanding of what we actually want to build.

Once we know what we'll be building, we should produce a Walking Skeleton that features most of the end-to-end components of the final product. For instance, we might produce an application consisting of a webserver, a database and a web frontend. It's not going to do anything fancy, but that's not the point of the skeleton. We want to know if we have the right means to get the job done. Filling in the functionality is for later.
Let us use an example on this: If we are trying to build a data mining application, but already fail at the "store data" part because we can't maintain our data, we don't need to worry about building a nice user interface or tuning performance.

We leave the Walking Skeleton phase once we have a validated understanding of what resources and technologies help us build our product.

As soon as we have a reasonable amount of certainty that we can make our vision real, we should work on the Minimum Viable Product.
The MVP is a usable piece of software that does something in line with the product vision, so we are talking about working software produced using good engineering practices.
Because of this, the Product Owner has to make some seriously tough calls on what should be part of the MVP and what not. A good PO should never fall for the temptation to load the MVP with features - in this stage, less is more!

While A Walking Skeleton is a great basis for the MVP, there are often good reasons for building an MVP which doesn't even use any Walking Skeleton.

While we can "alchemize" on the Prototype and to some degree even the Walking Skeleton, we need to have some form or engineering framework in place to produce the MVP. As the product is just in the startup phase, Scrum is a perfect methodology to build up both the team and the product simultaneously.

At this point, take caution that effort was already invested, but you still have nothing to show. Even the value of the MVP is close to Zero, its value is in the learning rather than in the bottom line.
Because of this, the investment into an MVP must be minimized both in cost and time. Chances are if you take more than a few weeks on an MVP, you risk a lot in terms of "building the wrong thing".
For your own sake, if you can't see yourself reaching an MVP anytime soon, just let the project die!

You want to get into the "Initial Market" phase as fast as possible.

This phase determines everything for investors. A good product will start generating revenue in this phase, because you have a Minimum Marketable Product, something that you roll out "ready for use". You want people to actively use the MMP for more than some fiddling. If you can't get customers hooked to the MMP, you might want to cancel the project, because it will most likely be wasted effort!
The transition from MVP to MMP requires delivering the most critical items in your backlog as well as continuously staying in touch with the customer base in order to refine the backlog.
Techniques such as A-B testing will give you feedback on how customers like different approaches to new features.

If your engineering practices are still lacking in the MMP phase, you will most likely kill your product due to technical debt sooner or later.


Let's hope your project has survived the MMP phase and is sufficiently mature to enter a maintenance routine.

A mature product has an established customer base and should have generated sufficient ROI to make the investment meaningful. At this stage, the backlog no longer consists of any release-critical features and most things to be done are merely extensions of existing features. 

When there is nothing which must be added to the product, it is no longer essential to follow a rigorous short-term delivery routine such as the Scrum timeboxes. Also, when the criticality of further extensions is low, funding may be reduced.

Agile practice recommends shrinking the team(s) at this stage and moving on to more critical projects. The reduced team is mostly in "maintenance mode" and occasionally produces new features, so Kanban may become the team's preferred delivery framework.