Robust Vs Complicated
Robust - having or exhibiting strength
Complicated - consisting of many interconnecting parts or elements; intricate.
Designs have a lot to do with how well things are understood and therefore used.
Consider the two pictures of SAFe and FLEX below.
Developers of complicated systems would have you believe that functionality requires complication. But it does not. SAFe is complicated because it is based on levels. It started with the program level (now called Essential SAFe) and has grown into what it is now.
Trying to be everything to everybody is not possible. The number of combinations in the variations become astronomical if the system is not designed for variation. This is where design comes in. Designing around levels is not a good approach because that's exactly what we're trying to get away from in the Lean-Agile space. Hierarchies and organizational structures need to be replaced by flow and networks. Different parts of the organization need to be able to operate in a self-organizing manner while keeping the context of their work (a focus on realizing value) present.
But it's worse than this. If you need all of SAFe it's very complicated. If you start at Essential SAFe you leave out much of what's needed.
Consider how FLEX handles variation. Many organizations have multiple business stakeholders. The diagram below shows how FLEX can have the strategies and portfolio management part of FLEX can accommodate this.
And, of course, sometimes there are multiple development groups.
Or possibly development groups that are arranged in a combination of vertical aps using horizontal platforms.
By designing the system modularly while attending to how the parts of the value stream interact with each other it is possible add any number of combinations without significantly increasing the complexity.
The reasons this flexibility is important are:
- it is possible to create combinations that suit your organization without becoming complicated
- seeing the value stream is important and this enables you to do that
- FLEX can continue to grow and add more pre-made solutions that fit into the framework that you can use without great complexity.
Net Objectives is looking for both clients who see the advantage of FLEX and for consultants who want to train with FLEX as well. Please contact me if you are interested.
The Patterns of the Intake process pattern group https://www.dhirubhai.net/feed/update/urn:li:activity:6546044032676691968
The Intake Process Pattern Group https://www.dhirubhai.net/feed/update/urn:li:activity:6546037607263023104
I just wrote FLEX as a Pattern Framework.? https://www.dhirubhai.net/feed/update/urn:li:activity:6546024671983349760 (included here): A pattern is a solution to a recurring problem in a context. Christopher Alexander, who created the concept, says "Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." In FLEX’s case, the context is achieving business agility – the quick realization of value predictably, sustainably and with high quality. This, of course, requires solving several problems with each of these problems being solved in a different manner. FLEX groups these patterns those patterns that solve the same conceptual problem. Hence it consists of pattern groups with each group consisting of a set of patterns that solve the problem associated with the group. The primary groups are: 1. Value stream management 2. Strategies, & initiatives 3. Portfolio management 4. Product management 5. Intake process 6. Planning 7. Development 8. Release 9. Realization Patterns must include their purpose, the forces they deal with and their proposed solution(s). Patterns are also named in order to be able to identify them. This has the added value of improved communication.
Business Transformation Leadership | Expertise in People, Process & Technical Change | People First & Value Focused | NED
5 年Dan Gibson?
I think anyone who tries to capture a mental model of how an organisation works (or should work) falls into the trap of abstracting themselves so far from reality that they begin to believe that abstraction is how things actually work.