I’m not saying that how a coach “be’s” is not important. But it’s also not the only critical aspect of things. Good energy, knowing what to explain and explaining them well are critical. A great coach can explain the right things to people so that they can learn on their own.
The Agile community is currently focusing on certification and frameworks that make it easy to start. I believe this is much of the reason for Dark Scrum and Fake Agile.
We need to shift our focus to the laws of effective software development embodied in Flow and Lean thinking. These are usually touched on in framework training but then used to justify practices that are only partially consistent with them.
It’s amazing to me how this is as effective as it is. It is better when you integrate true Flow and Lean thinking with your practices. Go for smaller pieces, shorter timeframes and greater visibility. How to do this is easier with a framework designed around the value stream.
Don’t rely on framework thinking, rely on real thinking-yours. Don’t buy the quick excuses I hear many consultants espouse- “if only they’d do what’s in the guide”, “management wasn’t involved”, …
The job of the consultant is to guide the way, not blame their clients. That’s true being.
Most everyone has heard about complexity in software development by now. The takeaway many get is that it’s impossible to make predictions. But this is an over-reaction. Complexity means is that you can’t count on your predictions. This means we must always use feedback to see if our expected improvements really occur. When they don’t we should look to see why they didn’t.
Continue reading “How does your approach deal with complexity?”
“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”
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”