Agile Management | NOOP.NL

The Cynefin Agile Lean Mixup

I was pleasantly surprised to hear that several thinkers, practitioners, and researchers have teamed up to “further the application of complexity science in software development as well as in the larger organization”. The inaugural CALM Alpha event is scheduled to take place this week, in the UK.

However, I am wondering about the real purpose of the event, because the announcements by some of the five “faculty members” have been a bit confusing (for me at least)…

According to Dave Snowden and Karl Scotland the name CALM stands for “Cynefin, Agile, Lean Mashup”. But Simon Bennett says it stands for “Complexity, Agile, Lean Mashup”. Dave explained this inconsistency away by saying “you can replace Cynefin with Complexity if you want”.

But I disagree.

We cannot just replace carrots with vegetables, and we cannot replace Scrum with Agile. We also cannot simply replace the Cynefin framework with complexity science. (And anyone who tries to replace Dutchmen with humans would be causing serious problems.)

Complexity Thinkers

When you ask community members of complexity science “who are the most inspiring complexity thinkers for organizations?” you get many different names, such as Stacey, Goldstein, Hazy, Uhl-Bien, Lissack, and Boisot.

For my Complexity Thinking presentation I took inspiration from many sources, including Ackoff, Jackson, Lewin, Meadows, Seddon, Ashby, Maguire, and Snowden.

And in the Agile and Lean communities some people have familiarized themselves with the works of Eoyang, Argyris, Stacey, and of course Snowden. (I’ve even seen a reference or two to some novice called Appelo.)

Needless to say, there seem to be as many models and theories as there are systems thinkers and complexity thinkers.

I like that, because…

Complexity itself is anti-methodology.
It is against “one-size fits all.”

- Tom Petzinger, The Interaction of Complexity and Management

That’s why I struggle with the communication about the CALM event.

Is Complexity All About Cynefin, Really?

The announcement of the CALM Alpha event says, “The faculty will present our current understanding and experiences of the relationship between Agile and Lean practice, and Complexity.”

Yes, that would be great!

But…

Why is it called a “faculty”?

And why are they going to “present” things?

It didn’t escape my attention that almost all faculty members have tight relationships with the Cynefin framework. Joseph Pelrine suggested a reading list of scientific papers, and almost all of them are about Cynefin-related stuff. And Karl Scotland wrote the event is about “how do we apply complexity science, and in particular the Cynefin framework, to Agile and Lean development.”

The Cynefin brand is being passed around as if it is a synonym for complexity science. It isn’t. Just like Scrum is not a synonym for Agile. And Kanban is not a synonym for Lean.

Note, I don’t claim there’s anything wrong with Cynefin. On the contrary! I also never complain about Scrum. I think it’s great. And Kanban too. But I do object when people tell me I should do Scrum (or Kanban) when I want to be Agile (or Lean). Likewise, I object when people tell me Cynefin is the default model when we want to apply complexity thinking.

Because if they do, either they don’t get it themselves, or I suspect they’re trying to sell me a tool. And I have a policy of only purchasing tools from likeable businesses with crazy logos.

So, Will It Be Cynefin or Complexity?

When Steve Denning and I organized the Stoos Gathering (together with others) we did not call it the “Radical Management Gathering” or the “Management 3.0 Gathering”. I can be stupid, but not that stupid. It would have made it very hard for us to convince other thinkers and practitioners with diverse opinions and management models to join us.

That’s why I am wondering about the real purpose of CALM Alpha.

If the five faculty members are really trying to create a community of complexity thinkers, I expect Cynefin to get as much (well-deserved) attention as the many other ideas, models and frameworks that complexity thinkers have come up with in the last few decades. I expect the works of Stacey, Goldstein, Argyris, and many others to be discussed. And I will try to join and give this community my warm support.

However, if the faculty is trying to create a community of Cynefin practitioners, then this is also great! It could be similar to the Scrum Gatherings, where people discuss the single model and its many applications. In that case I will not join. Just like I’ll never join the Scrum Alliance. Because, as an aspiring complexity thinker, I believe I shouldn’t commit to just one model. I like my options open.

Speaking of options, Chris Matts said…

I hope it is a “pull” based event based on learning rather than a “push” based event where the faculty teach us what they think we need to know.

So, what will it be?

The Complexity Agile Lean Mashup? Or the Cynefin Agile Lean Mashup?

If the faculty doesn’t choose, I hope the CALM participants will.

Sorry I won’t be there. I’ll be in China, fluttering around like a magpie.

p.s. I trust people interpret this post for what I mean it to be: constructive feedback to clarify the purpose and communication of what might be a very interesting new community.

Unprofessional Behavior

Jeffrey Wammes is a Dutch gymnast who was not selected for the Olympic Games. His (former) coach said on TV that Jeffrey did not behave like a professional. Jeffrey, not surprisingly, doesn’t agree. He considers himself a professional, because he has done all that is reasonably required, including training, certification, and intensive practice. Nevertheless, his own coach said he was not a professional…

Some people behave like professionals, sometimes even without official titles or certificates. Some of my suppliers and business partners come to mind. And my spouse. And my housekeeper. And plenty of Agile practitioners. Let’s call them Type 1 professionals.

Other people just say they are professionals, because they have official titles and certificates. Because an authority, at some point in time, judged them to be professionals. But their actual behaviors sometimes indicate otherwise. Let’s call them Type 2 professionals.

Some people say they are professionals and they behave as such. Awesome! I wish everyone was that straightforward. Let’s call them Type 3 professionals.

Behaving Like a Professional

The attributes of a person can tell me things such as gender, age, education, nationality, shoe size, etc. These are simple observable facts. But the attributes of a person tell me nothing about professionalism. Simply having a profession (for example, getting paid to be a gymnast) does not mean that a person is a professional (being a “professional” gymnast). Well, at least not for me.

I know the dictionary allows for multiple interpretations of the word “professional”, either requiring behaviors (Type 1), or requiring status (Type 2), or both (Type 3). I dislike Type 2 because I think status should be earned, which requires showing the right attitude. One does not need to be a mental gymnast to understand that status alone is not very helpful.

For me, what counts is how people actually behave (Types 1 and 3). So, you have a title or certificate? Great! Let’s talk. You may be one step ahead of others. But I will ultimately judge you for what you really do. Not for what you claim to be.

Last week on Twitter I summarized that opinion as follows:

Nobody _is_ a professional. But any person can choose to behave like one.

I tweeted it 20 seconds after the idea emerged in my head. It is how I use Twitter sometimes: as an outlet for my brain barf. Anyone is free to read it, ignore it, or question it.

Making Sense of Nonsense

Dave Snowden decided to do the latter. I received a reply from Dave saying, “It was a nice soundbite, but it doesn't stand up to even a superficial examination.”

At first Dave did not care to explain why the tweet “didn’t stand up”. It is a kind of feedback he has employed several times with me and others. He just says the “language is wrong”, or there is “superficial understanding”, without bothering to supply a useful explanation. (It is hard to learn to become a professional, when all you hear is, “It’s not good enough”.) After I pointed out the unprofessional nature of the criticism, Dave said he would publish a reply on his blog, which he did some days ago.

Dave Snowden’s post says people are professionals because of their training, certification, and practice (Type 3). He writes:

It’s good if people choose to behave in a professional manner, but they need to be one first.

And he warns as follows:

Behaving like a professional smacks of a superficial con trick, pretending to be something without putting in the effort to acquire the necessary skills and experience.

I believe the key ingredient here is practice. Without the right behaviors (which is about regular practice) a person cannot be considered a professional. Anyone who has just received a driver’s license is not a “professional” driver. Insurance companies know this. Car rental agencies too.

It took me four years to earn my certificate as a software engineer. But when I finished I was definitely not a “professional” software engineer, even though the dictionary would have allowed me to use that qualification (Type 2). It took me years of practice to learn the right behaviors (Type 3). And I know some Agilists who did not study software engineering, but behave like professionals in every possible way (Type 1).

For example, I don’t consider software engineers who don’t understand and practice TDD to be professionals. No matter how many university degrees they have.

Dave Snowden’s comment that people can “pretend to be a professional without putting in effort to acquire experience” (Type 2) makes perfect sense, but not as a reply to my tweet! It is exactly this required effort that I see as part of the right behaviors. We mean almost the same thing! So what, exactly, is Dave disagreeing with?

Of course, my tweet-sized soundbite contained a logical error. How can you behave like a professional when professionals don’t really exist? Well, duh! The irony of the tweet itself was the reason why I sent it in the first place. It was probably also the reason why it was retweeted a few dozen times. Apparently, some people actually “got it”. Playing with language is required practice for any aspiring professional author…

Unprofessional Feedback

From various earlier encounters I noticed Dave Snowden doesn’t disagree so much with my messages (though he finds them superficial). What he usually disagrees with is my approach to disseminating ideas, referring to it as “a magpie stealing shiny objects”, “heavy on marketing, light on theory”, “lack of thinking” and “being a sensitive little flower”.

It is a style of feedback I would not associate with a professional researcher. You are a professional when you behave like one.

Oh, and it is not true that I’m “sensitive to criticism”. (You can check this with my reviewers.) However, I am sensitive to feedback that is badly delivered. Such as, “You don’t understand,” without any meaningful explanation. I judge this to be unprofessional criticism.

Naturally, I am voicing my own opinions here. I suggest you make up your own mind by following Dave on Twitter and reading his blog. It’s well worth it, if your brain, like mine, is athletic enough to read around the language.

You're Not a Complexity Thinker When...

You’re not a complexity thinker when… you claim your interpretation of complexity is correct, while others’ are wrong. Because, among scientists, there is no consensus about complexity.

You’re not a complexity thinker when… you predict someone else’s approach to generating change will be wrong, because complexity theory denies predictions based on earlier events.

You’re not a complexity thinker when… you complain your model is misunderstood or misrepresented by many people because the point of your model should be to enable sense-making.

You’re not a complexity thinker when… you only promote your own model, and always attack other people’s models. Because complexity science is against one-size-fits-all.

You’re not a complexity thinker when… you avoid working with people who disagree with you. Because complexity absorption entails creating options and risk-hedging strategies.

You’re not a complexity thinker when… you take your own thinking too seriously.

Systems Thinking in a Bar

People assume that systems exist, but they are nothing more than abstractions in our minds. They exist because we think.

What would happen when there was a gathering of a dozen systems thinkers in a bar? I’m sure they would have discussions about interesting questions, such as:

• What exactly is the bar?
• Are the people here part of the bar?
• Is the beer part of the bar?
• If we drink the beer, is it still part of the bar?
• What if my beer and I go outside, are we then part of the bar?
• Is the bar a system?
• What is the purpose of the bar?

At this point the systems thinkers will probably get into a bar fight, and at some point Peter Senge might be ejected through the window.

Systems in Our Mind

We have these discussions and disagreements about systems because people assume that systems actually exist.

By formulating a research aim to uncover the fundamental characteristics of systems of various kinds, we were making the unquestioned assumption that the world contained such systems.

– Peter Checkland, Systems Thinking, Systems Practice

But it turns out that the universe actually does not contain systems. The universe couldn’t care less about systems. What we call “systems” are nothing more than figments of our imagination… abstractions in our minds.

There are no separate systems. The world is a continuum. Where to draw a boundary around a system depends on the purpose of the discussion - the questions we want to ask.

– Donella H. Meadows, Thinking in Systems

If we want to decide whether or not something must be treated as a system, we first need to consider what part of the world we want to look at, and what questions we want to answer.

A system is a way of looking at the world.

– Gerald M. Weinberg, Introduction to General Systems Thinking

The Purpose of Systems Thinking

Therefore, to answer the important question, “Is the beer I’m drinking a part of the bar?” we must decide what the purpose is of our question. Are we discussing the history of the bar? Its profitability? Its culture? Or its impact on the sewer? This is relevant in order to decide if your beer is still part of the bar when you’re drinking it.

Systems only exist because we think about them.

By the way, I think this could make it very easy to solve the Euro crisis. We just have to convince 400 million people to stop thinking about it.

Are you interested in systems? Why not check out the Top 15 systems thinking books!

(This text is part of the Complexity Thinking presentation you can find on SlideShare.)

Complexity versus Lean versus Agile versus Me

While the experts are battling over each others’ ideas, I remind myself that all models are useful (though some fail faster than others).

Dave Snowden is a complexity researcher who has repeatedly attacked systems thinking in his keynotes, saying that it assumes there is an ideal future that it tries to realize, which he considers the wrong approach.

John Seddon styles himself a systems thinker, and I’ve heard he said Snowden misrepresents systems thinking. But then, in his own keynotes, John Seddon has attacked Lean, saying “I hate Lean. It destroys organizations!”

It is no surprise that the Lean community claims Seddon totally misrepresents Lean. But I’ve noticed some of those same people have been busy attacking Agile, saying that Agile sub-optimizes at the team level, and Lean doesn’t.

Of course, some Agile experts say that this is a misrepresentation of Agile, and that Agile scales quite well to the entire organization. But at the same time Agilists have been attacking traditional project management.

Glen Alleman, project manager and prolific blogger, has repeatedly called bullshit on Agile experts. He claims that the attacks from the Agile community are often just misrepresentations of proper project management.

Complexity Thinking in the Middle

And now we’ve come full circle.

Both David Snowden and Glen Alleman have claimed that I am misrepresenting their favorite ideas. Though, interestingly enough, both have said this from completely opposite positions. (It’s as if Wall Street and Occupy both agree that I’m wrong, for exactly the opposite reasons.)

And so I find myself in the middle.

I consider myself a complexity thinker. I find all perspectives interesting.

All models are useful, though some fail faster than others.

It takes multiple perspectives to figure out which idea fails where and when.

And, while a new battle in the war between Scrum and Kanban has just started, I prefer a view from above and in the middle. I learn most by watching the battle of ideas unfold beneath me. Though it means I have to take a bit of heat from all sides. But never that much.

It’s actually nice and warm up here.

The view is great too!

p.s. Being human I also might have misrepresented a thing or two in this blog post. I suggest you deal with it.

(Jurgen Appelo is author of Management 3.0, a best-selling management book for Agile developers. It has a picture of a monster in it.)

Complexity Thinking (presentation)

Here's my latest presentation (that I'm still working on). It is called Complexity Thinking. I did it for the first time this week at the Lean Kanban Central Europe conference, and I will repeat it (with an improved version) at LESS2011.

This presentation was described by some as "thought provoking", "profound", "crisp!" and "most challenging session". And I'm relieved that people seemed to like it, because the amount of research I put into this talk was (from my own perspective) truely staggering.

But, feel free to judge for yourself and let us all know if you agree or disagree. Or, invite me to come and speak at your conference. :-)

(Jurgen Appelo is author of Management 3.0, a best-selling management book for Agile developers. It has a picture of a monster in it.)

Triple-Loop Learning

So, you want to build a product?

The First Loop

The first thing you should do is to gather requirements. What is it that users want your product to be capable of? Do they want a long battery life? A high quality GUI? Automatic updates? A smooth grip? A sturdy case in the color pink? You go out of your way to get a decent list of features to increase your understanding of what is necessary to build the product. It also reduces the risk of welding the foobar to the plingle when users prefer to attach it to a vringle. (I just made that up.)

This is level 1 understanding. Or single-loop learning. Or anticipation. Or functional thinking. Planning and controlling any kind of project is impossible without a level 1 understanding of your product. This, according to philosopher Daniel Dennett, is how human beings cheat nature. We can envision how things work in the future and prepare for it.

The Second Loop

But you build your product to be successful in an ever-changing environment. There will be new competitors while you are building it. Users will annoy you with new requirements. Some features will not work out as intended, while others emerge that nobody had foreseen. In other words, you have to keep learning while building your product. And the more decisions you can postpone to the future, the better.

This is level 2 understanding. Or second-loop learning. Or adaptation. Or systems thinking. Your product is part of a larger socio-economical system, and therefore you must observe the environment, revise your goals, and let your product adapt in order to survive in it. You implement Agile practices to deal with this second level, with iterations, continuous deployments, user demos, and many more.

The Third Loop

But then you realize that your observation of the environment is also changing it. Your regular user demos are changing people's perspectives on the frequency of their product releases. Competitors are adapting to your adaptations. One customer hates you because you ask for input 12 times a week. While some other users love everything you do, simply you’re the first one to listen to them. It appears the manner in which you communicate, and the types of feedback loops you create, are influencing the product that is emerging!

This is level 3 understanding. Or third-loop learning. Or exploration. Or complexity thinking. You realize that your interactions are just as much part of the system as the product you are making. That all your observations are subjective. And that it is impossible for you to know everything. Because how can you know the knowable when the knowable shifts depending on how you try to know it?

Triple-Loop Learning

All three levels of understanding are important when building a product. You cannot plan a product release without anticipation. You cannot embrace change without adaptation. And you cannot deal with the unknown without some exploration and imagination.

The Illusion of Control

Control is an illusion.

Do you think you’re in control of yourself? Hah! Think again.

Your eyes capture only a tiny percentage of what happens around you. Your memories are largely just a figment of your imagination. And your “free will” is little more than an elaborate illusion created by your brain. (The Grand Delusion - NewScientist, 14 May 2011)

And you think you’re in control of your project? Haha, sucker…

“Humanity’s commitment to technological change is a commitment to the creation of more uncertainty, contingency and incomprehensibility.” (We’ve made a world we cannot control - NewScientist, 14 May 2011)

In their book The Techno-Human Condition professors Allenby and Sarewitz argue that we operate at three levels of technological complexity:

• Level I is applied by people who see technologies as performing particular functions. Feeling comfortable in their illusion of control these people believe that desired outcomes can be engineered, and they say there are no unknown unknowns, if you only try hard enough.
• Level II is applied by people who understand that any technological product is part of a bigger complex system, which usually includes people. These people believe some form of control can be achieved if you apply holistic systems thinking.
• Level III is applied by people who see that complexity is as pervasive as water. It is integrated in our work in ways that we cannot even imagine. Such people are comfortable with the knowledge that they know only very little, and complexity thinking tells them that uncertainty should be embraced, not eradicated.

The levels offered by Allenby and Sarewitz seem to align nicely with my own ideas about systems and people:

• Level I people are project managers. They prefer to engineer the future, with Gantt charts and PERT charts.
• Level II people are systems thinkers. They prefer to bring about the future, with boxes, arrows, and models.
• And Level III people are complexity thinkers. They prefer to invite the future, with interventions and plenty of surprise.

But, to be honest, I don’t feel certain about this. Which is OK.

And if you don’t care when this all incomprehensible to you, you’re doing fine.

Old Ideas, New Words

Sometimes I am accused of re-iterating old ideas, and not adding much that’s new. They say my ideas are just old messages in new words.

That is mostly correct. But not quite.

I see no reason to come up with ideas that are totally new, when the old ideas are working fine, after I modified them with a little tweak to make them work better…

I changed the four leadership styles of situational leadership into the seven authority levels (by distinguishing consulting people versus informing them).

I changed the balanced scorecard into the metrics matrix (by considering system stakeholders instead of internal organization).

I changed S.M.A.R.T. goals into Agile goals (by allowing goal setting criteria that are all context-dependent).

I changed 360 degree feedback into 360 degree meetings (by discussing collaboration in an open and respectful environment).

And I have suggested to change value streams into value networks (by replacing customer value with stakeholder value).

In every case I did this because I believe the world is complex, not ordered. And organizations are living networked systems, not lifeless hierarchical machines.

Many of the great old ideas are defective when applied using the faulty machine metaphor. They only work well when we replace it with metaphors of living growing systems. That’s what I prefer to do.

And so yes, many of the ideas I present are old. But they are not merely old ideas in new words. They are old ideas used in a new paradigm of complexity thinking instead of machine thinking.

I call it Management 3.0. Others call it Management 2.0, or even Management 1.1. But does the name matter when we finally understand how to put those old ideas to good use? Should we throw useful management practices away only because some people have misapplied them in command-and-control hierarchies?

Why not brush the old ideas off and recycle them?

Now that's an old idea worth considering...

Wasteful ProductOwners?

In his recent blog post Banish “Priority” and “Prioritization” David Anderson (of Kanban fame) argues that prioritization of features by a ProductOwner is a “wasteful” act of “non-value-added” coordination. The ProductOwner role is, in his words, an “old paradigm”. Instead, David suggests to introduce “a set of classes of service” with associated “policies”.

When I first read David’s post, I didn’t understand it. My first reaction was, how can someone so smart write something so silly?

Complex Environments

In Scrum it is the job of the ProductOwner to absorb and model the complexity of the environment on behalf of the project stakeholders. Anyone who removes the ProductOwner and replaces the task of prioritization with selection and scheduling using a set of policies commits the fallacy of confusing complexity with complicatedness.

• What if feature A takes precedence now because Sally is the best one to communicate with stakeholder X, and she will go on vacation next week?
• What if feature B should be done a.s.a.p. because the customer accidentally deleted data that can only be recovered with feature B?
• What if feature C must be done instead of feature D because stakeholder Karl is ill, and his input is needed for feature D but not for feature C?

Social Complexity

Managing stakeholders in a complex environment is a complex task. It is non-deterministic. Selection of features and replenishment of queues based on “some plan or delivery schedule” (I’m quoting David here) is a complicated task. It is deterministic.

From a complexity thinking point of view it makes no sense to replace a ProductOwner with a set of policies. It takes complexity to deal with complexity, because complexity is irreducible. You cannot simplify the complexity of the environment to a set of rules. You need the complexity of people’s brains to absorb and model the complexity of the environment. A deterministic set of policies associated with classes of services is a very poor approximation of what happens in the real world.

The suggestion that ProductOwners don’t add value, and that they can be replaced with policies, is sending exactly the wrong signal to managers around the world. And it doesn’t matter whether this was intended or not. When I don’t understand the motivation behind this message, then how are more traditional CxO’s going to interpret it? If we can replace the PO with a set of policies, then why not the ScrumMaster and Software Testers too? It is the “machine-thinking fallacy” all over again. No wonder that some old-fashioned managers find the rhetorics of Lean thinkers appealing. It is an old paradigm indeed…

The Real Message

Given my general admiration of David Anderson’s ideas, I realized I could have misunderstood something about his message. And after a lengthy debate on Twitter (which probably costs us both a few followers) it appeared what David really meant is to capture the boring part of the ProductOwner role in a set of policies. (Only the part that can be modeled with deterministic rules.) He said the interesting part of the PO role (handling exceptions, uncertainty, social complexity, etc.) should be taken up by the team. Or, in David’s blog post:

“Empower the team to make good quality risk decisions.”

Ah, so the requisite variety was there after all! But it was (from my perspective) only one line of value among 40 lines of waste. It was easy to miss.

I still think that (most) teams are not able to take on the complex part of the PO role. But at least this suggestion is one I can understand…

p.s. You may notice I tried to write this post in a similar fashion. Most of it is crap about misunderstandings. The real value is in just one line. :-)