Thread by @alshalloway

Been working on Inherent Simplicity and how to work with complex systems. Got question why my comment that one of biggest inventory/queues/delays causes waste is doing work in iterations. So that's one topic. But related is how frameworks based on practices create constraints /1

to use both from a "what's possible" point of view (especially when we're told not doing those practices means you're not doing the framework anymore) and what we attend to. Constraints in design are good actually, as long as they are the right constraints. Using constraints /2

based on practices (which are not generally applicable) means the constraints limit where your approach can work. But having constraints based on how the world works would be useful. So the thought is, let's do design thinking on our process. Our "client" is our way of working/3

the constraints are defined by the factors of simplicity present. This is pbased on inherent simplicity:
1 Value density of items being worked on
2 Batch size
3 How workload relates to capacity
4 The value creation structure of the organization
/4

5 The degree of flow in the value streams
6 Visibility of work and workflow
7 Quality of the product
8 culture

These become our constraints. these match the natural laws we have to attend to. We can start with iterations et al, but we need to know this are just starting pts/5

bummer have an 8am accupuncture session so have to stop. i'll list the issues to continue.
Developing a pattern language (have already)
Why sprints cause waste in areas of WIP, Learning, planning
Why need MBIs when don't have sprint planning (need them anyway but especially here

So let's consider our "client" to be an organization what needs an effective process. (slight change from statement).Their goal is not to adopt X but to increase their business agility. Frameworks are methods to do this, but frameworks are inherently bound to any required/6

practices. This doesn't mean that they aren't good starts. But if that's how you think about them then it must be easy to shift away from them. A low barrier. Consider any framework that is defined by a practice or set of practices. Normally an small improvement is ok /7

but now crossing the line to no longer do a required practice is a big deal. If you were a consultant brought in to do X you'd have to explain why you're no longer doing X (even if what you're doing is better) /8

if you're a practitioner you probably aren't confident to go outside of the box. especially if all the experts say if you do you're no longer doing what you've been trained in. So having a boundary on an approach sets up a psychological and financial barrier to go outside of it/9

if the framework is based on empiricism (e.g., Scrum) then the barrier is even greater because there is no model on which to build outside of the framework. So it becomes all in or you're on your own. Scary when you have a day job that depends on your process. /10

add Upton Sinclair's observation - "It's difficult to get a man to understand something when his salary depends upon his not understanding it" and you have a real issue. Instead folks will keep toiling with something that doesn't work because of the /11

pressures to stay within the constraints selected. In this case the framework. This pattern often plays out as:
1) starts well
2) knd of stagnates
3) try some improvement a few times
4) sometimes start over (bring in another trainer /consultant
/12

5) cycle repeats.

It happens not because the framework has not been designed to be transcended. In fact, it's been designed to not be transcended.
You'll hear people talk about the framework as "it's simple but difficult to master" or "it's simple, use it as is" /13

and when it failrs it gets defended as people didn't do it. and frameworks don't fail, people fail. But what's being ignored is that the framework becomes the system people are operating in. Systems thinking tells us the system will inform the behavior. But frameworks of this /14

type are not designed with tsystems thinking in mind. Because if you did use systems thinking you'd attend to this dynamic and they don't. so it's an endless loop. eventually you have to break out and then it's called X-but -this disparagement makes it even harder /15

psycholcolgically to break out of. Emotionally it brings you into the unknown. It's scary. But we (as adults) don't like to admit fear so we start dissing the approach. instead of looking for what would really work /16

the key when you have an approach is to attend to the constraints you use. This is where design thinkingn comes in. Constraints cannot be limits on the solution. because what's limited may be part of the solution you need. But without constraints it's /17

unlikely you'll get anywhere. So the constraints must be there to help you avoid what won't work not so much tell you what to do. Fortunately, we have much greater accuracy in predicting what won't work than for what will work. so our approach becomes one of getting /18

a decent starting point for us. We can pick scrum or kanban or whatever. But we know that the practices we've started with are arbitrary to some extent. they are the best we could do at the time. note this consistency with Agile - we're not doing BPUF (big process up front)/19

rather our process is like an MVP. experimental, exploratory. We get success or failure and adjust. Both give us insights. There are no boudnaries. We can prgoress at the rate we learn. We can ask whether something will be an improvement or not because while we're using /20

empiricism to validate our work, we're also using science and a model of Lean, Flow, ToC, .... to do deductive and inductive thinking to navigate our constraints and improve as we need to. We are not limited to a preset approach that worked somewhere else, /21

but we can't do whatever we want to claiming we are somehow different by violating universal principles/laws. In other words, while you are different when it comes to practices, you are not different when it comes to how the world works. /22

this work can be done more simply if it is done within the context of a pattern language. This is how FLEX is designed. it is based around the relationships in an organization which are quite similar form an abstract point of view. this abstraction guides us. /23

each pattern can fit into the pattern language - where each pattern has a well defined set of input, outputs and rules of visibility of the work. THis is consistent with systems thieory - which is encouraging. Systems are based around relationships, so making an /24

approach around relationships seems sensible. Have to validate, of course, but i've done that :)
by attending to relationships we can tackle complexity ina different manner. It's about exposing the unseen, not understood relationships that is the key. Changes we make should /25

either be successful or have us learn. If an improvement isn't achieved but we can see why then we are in better shape to take the next step. Our improvement becomes a path of learning. our understanding and our system emerges.

OK, going to beach for a while. will come back /26

@threadreaderapp unroll