“Just enough process to let people do their best work” is an Agile thought not a Lean one. Lean suggests process should be the explicit workflow and policies that enable people to do their best. We’re not going for more or less process, but rather clarity on what is the best way to get work done.
Lean suggests that people doing the work know this better than anyone else, so clearly they’d be the ones to define it. It must be visible so we can work to improve it.
But it’s not quite this simple. Left to their own, people tend to self-optimize. So, although people must create their own process, it has to support the bigger context as well – that is, how to do their work to optimize the bigger picture. Creating the awareness of this context is management’s role.
Frameworks can support this as well, but must then meet these requirements:
1) the framework must provide the context for the entire value stream
2) while preset practices can be presented, they must be changeable by the people doing the work
3) this requires clear objectives for these practices so that the work still is done effectively
Frameworks should also provide alternatives to practices so that people don’t need to reinvent the wheel (another form of waste).
Don Reinertsen says “A flow-based process delivers information on a regular cadence in small batches. In fact, cadence helps lower transaction costs and makes small batches more economically feasible.” He also suggests the best measure for flow is reducing the cost of delay – that is, what delays in value realized cost in terms of lower revenues, opportunities lost and higher risk.
Achieving this requires reducing handoffs, managing queues and having a focus on small batches of work that deliver high value.
But all of this is akin to “buy low sell high.” Is your approach limited to providing you a set of practices to guide you or does it also provide you with an understanding of Flow so that you can tune its practices to your situation?
For example, forming trains when teams are well-formed is not difficult. But does your approach provide the principles of Flow so that handoffs and delays can be avoided even when the teams within the train are not cross-functional? Doing so can shorten the delivery (and planning) time considerably.
If there are delays in your workflow what tools does your approach provide for you to lower them other than the advice of a consultant?
this is one in a series of blogs. You can see the entire series at
The term organizational operating system refers to standard, organization-wide collection of business processes used throughout the organization. The definition has also been extended to include the common structure, principles and practices necessary to drive the organization.
Continue reading “Does your approach create an organizational operating system?”
I keep hearing how you have to “be Agile.” But what does that really mean? How would you know if someone were “being Agile?” You’d probably look to their actions. But then, of course, you’d be looking to see if they were “doing Agile.”
Agile, of course, has more to it than the actions people take. But by separating the being from the doing many Agilists give themselves a built in excuse for their clients’ failure – “well, they were just not being Agile.”
Continue reading “Why you need to ‘do Agile’ to ‘be Agile.’”
It’s is important that we understand the difference between Agile at scale and scaling Agile. Agile at scale means the organization is Agile. It can develop, deliver and pivot quickly. But it doesn’t mean that the projects are scaled. Large projects are an anathema to Agile as are large teams and trains. Scaled Agile should help us break workflows down into small and separate value streams so as to create efficiencies and quick feedback.
Continue reading “You want to have Agile at scale but not to scale Agile”
Many people are talking about business agility. But talking about it and doing something about it are two different things. To be clear, business agility is the ability to realize value quickly, sustainably, predictably and with high quality.
Doing this requires:
Continue reading “Does your approach enable business agility?”
Starting with Essential SAFe does get people working together. But the real problem for most companies is that they can’t sequence work well and are working on too many too large items. This causes thrashing and delays delivery. You don’t have to implement the higher levels of SAFe to get much of the benefit they promise. All you have to do is make explicit a powerful concept missing in all of SAFe – the Minimum Business Increment (MBI).
Continue reading “Make your Essential SAFe adoption more effective by adding just one explicit concept”
Agile has moved from the team to the enterprise with the goal being business agility. We need a system that takes us from strategies to realization. This has two tightly connected phases – the discovery of what to work on and developing it.
Business has the responsibility of discovering what these small pieces are – both who is being targeted and what value is to be delivered. These are presented to the development group in the product backlog.
What these pieces are is the missing concept I am referring to. Many people are using the term MVP for this, but an MVP is about discovering if a new product is viable. It starts small and grows.
Most large organizations have strategies and initiatives for extending existing products and services. This requires going from big (an initiative) and making it small. This is accomplished by ‘asking what part of an initiative can we deliver sooner?’ This is not just about being small, however. It must also contain all of what’s needed. That is, what shared services, ops, marketing, support is required to achieve value? So it can be thought of as the smallest container of what is needed to provide the quickest realization of value.
We call this the ‘minimum business increment.’
For more on MBIs and how they relate to MVPs, go here.
Originally posts August 2013.
Disclaimer: I could have named this framework/method/process tunnel vision, but that seems a bit redundant. So don’t infer I mean to pick on any Agile approach that is a framework over one that is called a method or a process. I am just using the word framework generically. For the purposes of shortness, whenever I use “framework” in this blog, pretend I’ve said “framework/method/process/…”.
Continue reading “Framework Tunnel Vision”