Have just written a post
What’s missing in the Agile space
linkedin.com/posts/alshallo…

Here are some of my favorite quotes from it.

Picture is some of what's missing: 1/ First, we need to take a scientific point of view. One of the implicit assumptions about this is that we can understand what’s going on. While many hide under the covers of our world is too complex to understand I agree with Eli Goldratt’s observation (picture) 2/

Agile is not just about challenging the assumptions of our plan and of what we need to build.

Even SAFe suggests this.

It's about challenging how we work.

But few Agile approaches actually do this.

Most have their own treasured values.

We need to take a scientific approach. It is much harder to build a system that helps you think right from the start instead of following it, but that is easy to start with and well-defined

Simple to learn, simple to start.
Really difficult to build.

Simple to the user typically requires difficult to the creator

you don't want your framework to be purposefully incomplete. You want it to be intelligently incomplete. That is, you want it to provide you the information you need, when you need it, without overloading you. you don't want your framework to be simple to understand but difficult to master. Although building product may be difficult to master, you want your approach to be simple to understand and relatively easy to master.

Quotes from Dr. Eli Goldratt's The Choice, These on the left deal more with complexity. Those on the right,
especially those in bold italics are most pertinent to this talk. My point in including these is to show the relationship
between espousing things as being complex and causing resistance.

Will be writing a linkedin post on the J-Curve. here are some thoughts I'll be using.

Virginia Satir's J-Curve is held to be unavoidable.
I love Satir. But we're not a family.
But if we act like we're a CAS without understanding cause & effect we'll get it most likely.
1/ If we had a theory (like Flow, Lean, the Theory of Constraints) we could move the "transforming idea" up earlier & not have such a dip.

This is a belief that separates those in the Agile community. Read the text in the picture.

Scrum is on one side, Flow, Lean, ToC the other /2

The real cost of multi-tasking.
Many people point to multi-tasking as a major problem. It is a significant one, but not the key one. Consider the cause of multi-tasing – people working in multiple value streams. People are being interrupted and are interrupting others. Correlated with multi-tasking is work waiting in queues. While multi-tasking may cause a 10-20% drop in efficiency, work waiting in queues can create unplanned work in the form of bugs, working on the wrong things, rework, etc., that is much larger.

Frameworks are not the only way to structure improvement initiatives.

We should stop accepting their limitations simply because they are easier to create and promote. An Agile framework that can't adjust itself as we learn, or that requires a massive shift from any adopters when it does, is not Agile

Remember the words "we are discovering better ways"

More on this successengineering.works/the-mindset-of…

When you first look at complex systems it looks like you will not be able to get an understanding of cause and effect - almost by definition.

But when you look deeper, you see patterns in the behavior.

You also see that embedded in complex systems there is cause and effect.
1/ As Eli Goldratt says "If we dive deep enough we’ll find that there are very few elements at the base - the root causes - which through cause and effect connections are governing the whole system.”

So, at first glance, it's easy to think that cause and effect is not applicable /2

"The way we see the problem is the problem" S Covey Cognitive bias is real

"We do not think & talk about what we see; we see what we are able to think & talk about" Edgar Schein Together with the above quote this means we will not see a solution if we're not talking about it 1/ “It's easier to act your way into a new way of thinking, than think your way into a new way of acting.” Jerry Sternin. We cannot presume a proper mindset. We must show people how to get their by working together.
2/

Most of the waste in knowledge work can be attributed to small errors that go undetected but end up resulting in large amounts of rework.

There is more to be gained by increasing the rate of feedback than there is in trying to understand the nature of your development system. the bottom line is that you can never get enough training to get you out of a framework that's been designed to keep you in it

"There is nothing so useless as doing efficiently that which should not be done at all."

Peter Drucker
5/

since Scrum is based on the idea that it is easy to start and people can figure out what they need, why are there over 30 Scrum certification workshops?

Doesn't this alone tell us folks won't figure things out?

SAFe has over a dozen.

1/ what's conveniently ignored is that both Scrum and SAFe are designed to get quick starts and then have to train for ever

They talk about Shu Ha Ri but leave out any way to transition out of the box they've created.

Just more training.
2/

the fact that Scrum and SAFe are not based on first principles (SAFe mentions them but is not consistent with them) does not mean it's not possible to build a system on them. Amplio and Tameflow are built this was, as I am sure others are. It's like we're back to the way engineering was with bridges hundreds of years ago where people had their own rules for how to build bridges.

And then they wondered why they failed.

Theory is needed.

There is no such thing as Scrum first principles. Or Lean, or Flow for that matter. There are only first principles that different approaches take advantage of.

1st principles stand on their own.

You observe them, point them out, and take advantage of them. of course, this misunderstanding in the Scrum community is not surprising since it's based on empirical process control and specifies no theory

When you have first principles, you don't need to have immutability. You focus on what works.

The 1st principles are your constraints

Quotes from Dr. Eli Goldratt's The Choice, These on the left deal more with complexity. Those on the right,
especially those in bold italics are most pertinent to this talk. My point in including these is to show the relationship
between espousing things as being complex and causing resistance.

@AgileMunro to do something to see what will happen where I am not almost certain of the outcome, or to validate something I've done before but am not sure about its repeatability.

I have had to run few experiments when it comes to workflow improvement because I understand workflow @AgileMunro i run experiments in what the customer needs much more often. but even there I can often avoid many of them by asking - and those experiments can be very small.

OMG, I've been accused of being a serial adopter. Meaning I learn one approach, promote it, then try to improve it & when the founders aren't interested go on to a better approach.

Hm, do they think i should stick to something I sell when I have something better to offer? /1 I try to fight against Upton Sinclair's observation that "It's hard to get a man to understand something when his salary depends upon his not understanding it."
/2

love the progress being made in my new way of training being done in team master class.my Amplio Lean-Agile Teams Master Class. I believe a few years from now we'll look back & scoff at the idea that live, in room training was the best./1 sometimes the best way to get out of a box is to put yourself into another one &be committed to improve it

Part of the Amplio Community of Practice effort is to learn how to take this to a large group of people
successengineering.works/the-amplio-com… /2

i did hear indirectly that I had used the word discord instead of disorder. My bad. fixed.
of course, it didn't have any effect on the article I wrote. but don't like to misstate things.

here is the article:
Amplio from a Cynefin perspective
successengineering.works/dealing-with-c… apparently i'm making up strawmen that complexity thinkers believe you can't identify cause and effect and predict what will happen. cuz that's all I've been saying

here's a post on that:

A Fundamental Question that Separates Many in the Agile Community. successengineering.works/the-mindset-of…

i am about to write a chapter in my book on the level of disruption needed, why process is important, why attending to fit for purpose is important. Invite polite feedback + or - re being wrong or misleading. Main conversation will take place on linkedin. so I may not respond :) people confusion disruption with change.

Change does not have to be disruptive.

It's usually best when it isn't.

Sometimes disruption is a good thing, but not for its own sake.

The opportunity for disruption changes over time
/2

@__bbak no. it is clear what complex is. Product development is complex. And products emerge. And system behavior emerges. But you can drive it by attending to relationships you can understand and be prepared for things to happen from what you don't see/understand. @__bbak i believe in first principles (e.g., too much work causes delays which cause waste). I believe you can drive from these knowing this doesn't provide a full explanation. You strive for quick feedback to eliminate waste. you enable quick response to outside surprises.

Writing a post on how frameworks blind us by limiting what we see

Scrum is like having blinders. SAFe is like having a light shone in our eyes.

Both obscure our real problem. Neither gives us a way to see it.
This isn't the post- but it's a way to see successengineering.works/the-value-stre… The lie of frameworks when they say we can go beyond them is that they have us focus on the framework. This tends to have us stay in the framework and not ever see beyond them. Which makes going beyond them difficult.