This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.
All approaches provide a starting point- I call that a prescription. The key question is how many different prescriptions can they write? If they only have one, or if part of their prescription is immutable, then they are prescriptive, To avoid being prescriptive one must provide choices and how to implement them.
Scrum's prescription is cross-functional teams, time-boxing, certain roles and events. Scrum was designed for a team building a product, not for a group of people who are working on many projects. It's a good prescription for already capable teams, but not necessarily a good prescription to create teams or to get devs & testers working better together.
The Kanban Method has its own prescription that becomes prescriptive if one doesn't consider changes to where they are that might be useful at the start.
In practice, SAFe has a prescriptive starting point at the team level. This may work well when are not collaborating well. But SAFe's higher level prescriptions are pretty expensive and going from bottom to top is not always the right way.
Disciplined Agile & FLEX provide prescriptions, and only after a diagnosis. And they teach organizations how to write their own in order to continue to improve
yes it is. This can be done locally because of the long history of Disciplined Agile. The ability to do this across the enterprise is enhance with the upcoming integration with FLEX - which is designed specifically for this purpot.
this is consistent with Lao Tzu quote which is quoted many times in agile circles. What they forget is that you don't teach someone how to fish. You teach them how to fish for a particulaf type of fish.
It's a very interesting approach AI thanks for sharing. However some doubts are raised by this approach. how to prevent wrong dianostics from giving rise to wrong recipes, or even good diagnoses give rise to good recipes that have no effect on the organization because of side effects or because each organization is unique. Are we dependent on who makes the diagnosis? or we depend on who teaches us how to write our own prescrition?
Won't joining DA & Flex lead to more complex process designs and life cycles with less flexibility?
Alexandre - great comments and a true danger. Thanks so much for bringing up these concerns so we can address them. Funny how I'm writing a related blog so this is very timely for me - a real gift.
Let's look at the concerns raised:
1 wrong diagnostics
2 good recipes that create side effects
3 normally good recipes that don't work on the unique factors of the organization
4 does the organization become dependent upon the diagnosis
5 do we depend upon who teaches us how to diagnose
6 will this cause greater complexity.
As I write this I am impressed. These are some of the issues that I had to attend to when I created FLEX. they are all valid.
The first 4 brings up the issue that we need to get feedback. If we get feedback that things are working, then we should ask “why?”. Is it because we’ve got the wrong approach? Because we’re not implementing the plan well? Other, previously unknown factors are now present? This is the heart of the PDSA cycle (Plan-Do-Study-Adjust). PDSA is more about the way we’re working than the results we’re getting.
How do we do this? We attend to what is called inherent simplicity. Theory of Constraints puts forward the concept of inherent simplicity-the presumption that inherent in complex systems are rules that, when understood, enormously simplify the system. These rules already exist. We must find them and take advantage of them. Doing so enables us to increase performance and reduce or eliminate the challenges we are facing. We also use Flow and Lean measures of cycle time, presence of delays, and others to measure actual results. See "Inherent Simplicity Vs Apparent Complexity - https://bit.ly/32w7NK7
Regarding the diagnosis itself, I always tell people to never trust a consultant. I don’t mean not to trust their intentions. I mean don’t trust their approach nor their judgement. You should be able to see if why they are coming up with the conclusion they come up with. If they can’t make that clear to you then either they don’t understand their approach deeply enough or they can’t communicate it well enough. If you can't explain it simply, you don't understand it well enough. – Albert Einstein.
The danger of creating additional complexity (and dogma) is real. But it can be overcome by taking the scientific method. I like to think of Disciplined Agile / FLEX as an hypothesis that it’s the best way to do something. I am putting this forward as a statement to be attacked (as you did, so again, thank you). We can now learn what’s correct (at least for the moment) and what isn’t.
DA makes a diagnosis on where to start. If there are challenges with it we take that as feedback about how well the approach is working It doesn’t mean we abandon it, but we do question whether we’re taking the right approach.
you are quite welcome. This is part of my role at the PMI. The Agile community has long ignored the role of management, structure and systems thinking. After taking a strategy of embracing standard Agile methods, the PMI has acquired two groups of thought leaders (I was the former leader on one group, Mark Lines and Scott Ambler being the thought leaders of the other) that were both outliers and leaders in organizational methods which could achieve Agile more effectively than the team or top-down approaches common (e.g., Scrum and SAFe).
Part of our work is to educate the possibities that Agile, done properly can be achieved. That education can only take place through dialog and the learning that can result from that. So please keep asking and contributing. None of us has the answer - some of us have pieves of the answer.