Hedgehogs and Foxes - it is hard to get along (but worth it)

As for many others, one of the more interesting aspects about the election campaign in the US was the success of Nate Silver in his prediction. That, of course, led me to reading his brilliant book 'The signal and the noise'. In this book while explaining his path towards the prediction of elections, Nat Silver describes some interesting facts about political pundits e.g. in TV shows.

He analyzed several hundred predictions made TV pundits in a popular political talk show. He came to the conclusion that the predictions of those specialists weren't any better than simply rolling dices. Basically the distribution from 'prediction completely wrong' over 'prediction somehow ok' to 'prediction completely right' was a perfect rendition of a Gauss distribution aka bell curve. Depressing. But to Nate Silver this meant he saw a chance. After being busy in Poker and coming up with Pecota, a prediction system for player stats in Baseball, he decided to make a move into the fields of politics. It simply couldn't be harder to predict politics better than those lousy pundits. Of course, first he analyzed just why those predictions were so bad. What he found out, after talking to psychologist Philip E. Tetlock was the following, which Tetlock also describes in his book 'Expert Political Judgment: How Good Is It? How Can We Know?'.

Regarding proneness to biases and certain views which influence predictions, there are basically two kinds of people: Hedgehogs and foxes. Hedgehogs believe in the one great idea that holds the world together. Thus they express clarity (vision?) - but of course they are also more prone to evangelizing the one important idea. Foxes on the other hand like a more complex view of the world, combining several smaller aspects and forming a very specific and flexible view. Foxes are sometimes hard to understand, it is hard to follow their complex views, but they are open to new facts and feedback which can again alter their world view. The issue is - foxes rarely make it into TV, much less even into political talk shows. In TV they are no fun. They don't polarize, they don't fight. They simply don't draw attention towards them. Hedgehogs on the other hand make it into TV. Often. That is because they do like to polarize and fight for their one real, true idea(l). This leads to the worst predictors - hedgehogs - being more frequently in TV. Hedgehogs sell, foxes don't. The result is known - see above.

As Tetlock describes, the properties of hedgehogs and foxes lead to hedgehogs being terrible in their predictions (dices!) and foxes being quite good at it. Given the above description you can already figure out the reasons: Hedgehogs despise feedback and information that is dangerous to their one big great idea that saves the world. They are the epitome of being biased, even after reflection. If you ever read Kahneman's 'Thinking, fast and slow' and were surprised about how much are biases are influencing us without us knowing - imagine hedgehogs as hallways consciously blending out slow thinking because it hurts their idea. Foxes are grateful for all kinds of small information, enriching their world view, although making the collection of neat small ideas ever more complex and thus ever less easy to communicate. But they always update their model of the world with the latest data given to them.

While hedgehogs feel comfortable only with supportive feedback, foxes feel comfortable in a complex world of wild ideas.

Now, after a lengthy introduction on the topic you are allowed to ask Markus, why are you telling me this?'. Let me get back to a twitter debate I encountered some days ago based on this nice blog post by @klausleopold (Foxy!).

Enjoy the twitter conversation here: https://twitter.com/Kurt_Haeusler/status/273068451029979136 Klick on the Link to the tweet and try to detangle the conversation that ensued in your favorite twitter client. ;)

The whole point of the tweet stream here in this context is to show that there are huge debates amongst the communities, tribes, religions?, leaders? etc. of  Agile, Kanban and Scrum (and sure many others). Which is an interesting enough observation in itself, as to the outsider (such as my wife, my mother, my kids - basically everyone except myself) it could all be the same. But it obviously is not. Like brothers and sisters, debates about the seemingly small differences (seemingly!) can be fought at incredibly high noise levels. (If you don't believe me look at the tweet stream again - it is there for a reason). But that arguing about 'small' differences (and I could go hedgehog here for once: THEY ARE NOT SMALL, BUT IMMENSE!) can be harder than arguing about huge differences is only part of the truth.

Switch.

Let us watch the following Venn diagram which is only my personal view of the common ground between Agile, Kanban and Scrum. We have a huge group of Agilists having much in common with Scrum (also a large group). Then we have the Kanban group of people, not too big yet but growing (sorry, no dynamics in this diagram). They have a certain something in common w/ both agile and Scrum and vice versa.

Where are you in this Venn diagram - which is completely agnostic about the hedgehog / fox dichotomy

The situation is complex. The picture could be about common ground in beliefs, values, practices or simply about people being part of a certain or several tribes. For the moment being lets just think about the latter. Also for simplicity sake, let's say we are looking at one individual being part of just one tribe - let's say 'Scrum'.

Hedgehog Time: A Scrum hedgehog knows Scrum will save the world, not only in the world of software/product development (PD) but in basically all areas of Life. There's hard data to support this. Thousands of companies were already saved by migrating to Scrum. Also, a wicked sports car company is completely based on Scrum. Even if Ken The Schwaber himself says that (was it) 80% (?) of Scrum is more or less ScrumBut - a hedgehog knows what he's doing. Also, the success of the Scrum alliance, one of the most successful pyramid schemes speaks for itself. Thousands and thousands of CSMs (handshake included and approved) can not be wrong. Also, the hedgehog heard about this thing called Kanban, which claims to be agile but even got rid of the agile success factor iteration. These guys must be looneys, also why the hedgehog heard - these guys simply copy techniques from the inhumane area of car manufacturing. That much for agile. Kanban clearly is not the one great idea saving the world - rather the opposite.

The Scrum Fox sees some problems in Scrum, lives with it. He also sees some issues with it. Scrum changes his life a while ago, but also he somehow feels stuck. He incorporated new techniques and idioms all of the time. BUt somehow he is stuck. He watched his data, velocity didn't improve after a first bump. He is now aware of this thing called Kanban, bought Corey Ladas' 'Scrumban' and in the last retrospective he mentioned if iterations currently make sense and if foxes team couldn't try without iterations for 4 weeks.

But all this is not my point. Hedgehog wants Kanban to be THE thing. He also wants people to accept this. He wants to move people towards Scrum. Same is true for the Kanban hedgehog. The Scrum fox on the other hand likes Scrum, but it isn't THE thing for him, no life saver. Last week he was at a meeting of a local Ltd Wip Society. He wondered why all the talk on Scrum vs. Kanban was mentioned, let alone be a heated debate.

When the hedgehog visits a <enter your favorite methodology here> conference he feels among the same, he is at the place to be. The fox, well, he has some doubts about the uniformity of the tribe. It is all too good to be true. Too much preaching to the converted. Something feels wrong, something is wrong. Pushing the fox leads to loosing him, not supporting the hedgehog does the same to him.

This sounds complicated enough, but we can explore the model further. Now let's say a hedgehog has gone the whole way - he started ages ago w/ XP (after having survived  RUP - he was a RUP hedgehog at the time). Then it was agile, the  *right* implementation of agile was Scrum and yes, he can't deny it - now Kanban has some advantages in his environment. But now it is Kanban. So our hedgehog likes agile, he understands Scrum, but he knows that the real deal simply is Kanban. Fine. He is a happy man. But … he wants everyone to see that this is actually one great big thing. *Scrum is agile, agile becomes agile ^2 which is Lean is Kanban*. So obviously we are all one tribe, one big family. We must all understand this. This is what the multi hedgehog wants - unity for the one big idea of Kanban/Scrum/Agile.

Enters the multi fox. He has the same history as Mr. Multi-Hedgehog. He is convinced that his way was good, but all data shows that he has made best progress with Kanban. He likes all the folks. But some are really getting on his nerves. They want to tell him he has to be part of that great, big, huge thing, the conspiracy against management: The Kanban, Agile possibly even Scrum thing.   We must all be alike now, must be the same. But Mr. Fox knows he likes to think in terms of Kanban. It gives him flexibility. He thinks it is elegant. He does not understand at all while he should call himself agile. Being a fox he doesn't need to believe in the huge *Scrum is agile, agile becomes agile ^2 which is Lean is Kanban*-will-save-the-world-idea. He knows there are many methods, many models. They can co-exist, they don't need to be the same. Vive la difference.

And so, while the fox and the hedgehog do the same thing they don't get along. The multi hedgehog knows he's right while the multi fox is still searching. The multi-hedgehog wants the multi-fox to be more supportive of the agile folks, which the multi-fox has no interest in at all. In fact, the multi-fox feels pressured into a tribe he does not want to belong to. He just knows tools he uses.

And now go through this exercise for all kinds of tribal combinations of hedgehogs and foxes. Have fun!

The hedgehog's closed view and system is a threat to the Fox, whose openness is vice versa threatening the hedgehogs views. While what they do is exactly the same.

Why am I telling you all this and for oh so long? The thing is that most debates are not between methodologies - I think - but between very close foxes and hedgehogs. Once you get this, I hope, you can better lean back and relax. Now you know why your colleague fox seems so unambitious towards your religion and resists your pressure to join the tribe. As a fox you know why the hedgehog colleague does not feel supported in his belief system and values, even as you share them. While arguing on twitter guys, or on conferences - always try to think of the hedgehog and the fox. There is no difference in value between hedgehogs and foxes. They're just different. The openness of the fox is great, as well as the clarity and determined spirit of the hedgehog. They're both ok, it's fine. But it is hard, but necessary work to always remember this. Wiki says Gary Hamel prefers hedgehogs which I absolutely do no understand. I think they are a great combination in real life, once they get to understand their underlying issue.

I am a fox, of course. Hence I don't like tribal enthusiasm. Sorry. ;)

PS.: For fun have a look into this dispute between what I would characterize as Scrum hedgehogs and Scrum/Kanban/Agile/I-am-beyond-estimation hedgehogs, amplified by twitters great 140 char communication bandwidth constraint. Please do me the favor and read the whole tweet thread rant conversation: https://twitter.com/jmeydam/status/273861354329370625

Footnote 1: The story of hedgehogs and foxes originates in Tolstoy and was then reused by Philosopher Isiah Berlin in 1953 (See: http://en.wikipedia.org/wiki/The_Hedgehog_and_the_Fox)

Footnote 2: If you want to find out if you are a hedgehog or a fox - try this simple test

Footnote 3: Here a short text on the impact of hedgehogs and foxes on science.

Kanban is (just) a model

In the past weeks, my last active Kanban event way back in the past, I had some unfortunate discussions about Kanban.


The conversations that went bad, have all been trigged by others, not really doing Kanban asking me question on my experiences w/ Kanban and how I am (or was) doing or seeing things. I simply answered. My conversation partners in at least two cases left the conversation annoyed. I wondered what happened.


What I think what happened is that I was so sure and certain about my statements that this was indeed really annoying. What helped me in many cases and conversations, turned against me in the newer cases. The level of certainty I expressed in the conversations was disturbing, although honest and true, being based on empirical analysis of what I have been doing in the last years and several environments. Empirical analysis being a core part of Kanban.


What changed was, that in the past I was mainly questioned by colleagues who saw the effect of my work and who where happy of me sharing the knowledge. In the newer cases I was asked by people who didn't observe the effects of my work. To them my certainty must have come across as that of an ignorant super jerk. In fact one guy said I wouldn't know his organization and thus I would be coming with ready made recipes. I know the danger - but in fact I thought he asked me what I do and so I answered. I didn't even consider his environment - that would've been the next discussion. Again, I simply answered his questions on how I was doing things. Anyways - this is not about communication. During thinking about this disturbing effect I came to the following conclusion.


Whatever Kanban may be: a method, a tool, a process, a process to improve processes … whatever. To me it mainly is THE model to describe Product Development in an intuitive way. Whatever I am doing I somehow describe it in the language of Kanban. And until now it never failed to me to describe and explain effects I have observed. This really helps me to have a good model in my head to discuss and think over all the options that I have.


The model has about a million layers, starting with the visualization, the WiP limits, the core practices, the principles, the values, the culture, the queue model built in, flow ... Millions. All of them together have a certain effect and none of the effects can be reduced or deduced to a single measure we took at work. This also explains why the whole thing is so fragile ... As lean (and agile?) in general are.


So Kanban is a whole set of layers working together. As a conscious or unconscious effort (deep vs. shallow) doesn't matter that too much to me. Lots of the work being done by most of us currently is digging deeper into this model, deepening and trying to detangle it at the same time. Let's keep on.


THE model also now explains to me why my discussions ended in a bad way (besides me possibly being a jerk). Without explaining to the outsider or the uninitiated that we are always talking about the interplay of a multitude of layers, people must think we talk about a mere, lame white wall with stickies and numbers, which couldn't have those effects. And they couldn't. WE'd indeed be jerks if we claimed THAT. But we aren't - just the white wall with stickies and some stupid numbers is not what we are talking about. Since years. But it doesn't seem to get across easily.


But it also something we need to remember: We are not talking about Kanban. Even not capital K Kanban. We talk about all the positive effects we achieve and map these to Kanban. This can be or at least sound annoying. The name may be a problem - it suggests that we talk about the whiteboard with the ... But we don't. And we know, we take it for granted. But they don't know. And we have to explain. (If they don't get mad too soon ;)


In the end, Kanban - yes - is just a model. Possibly the best we currently have and it is still evolving pretty fast. Once it stops evolving it will be done and dead and ripe for replacement for the next great thing. But I don't see that coming soon. Too much is still happening, too much still needs to be explained, too many discussion to be held - possibly me being a jerk ;)


To end, after writing this, it occurred to me that I am saying similar things as David in his last blog entry on Tolerance - 'Are we doing Kanban or not?'. Just from quite different a vanishing point. Read it, it explains a lot.

Projects as a bad proxy and container for value in the product context

My buddy Arne - of freshly earned and well deserved Brickell Key Award fame - and me are just back since a couple of days from the LSSC12 conference in Boston, MA.


I was impressed by the broadness of topics addressed at the conference. During the next days and weeks I will digest them for myself, and hopefull in parts here on the blog as well.


Until then, I'd like to point out a topic that Arne and me were presenting at the LSSC12 ourselves, and which keeps growing in me even after writing it up in the proceedings of the LSSC12.

During our play onstage at the LSSC12

Actually there are two topics: 

• The structure of how to improve flow across your PD organization in a model of three main queue types: a) output queue (product release) 
• product development process queues (standard), and c) the input queue (product discovery and portfolio)

The way we see it now is that in most organizations, once you start with Kanban, it becomes obvious that the output queue is tha single largest queue. Thus is should be the first one that gets handled. The good part is that this is actually easy. Out of the easy problems it is admittedly a more comlicated easy problem but in no case really hard. It is, otoh, hard enough for Kent Beck to come up with one of his very great talks, called 'Software G-Forces'. In this he very lucently describes the challenges and forces that each step toward towards more frequent releases introduces to your PD process.


This leads to the effect that it makes sense, to start the standard Kanban work, in which by slooowly lowering the WIP limits in a sensible way across the development queues (in any model, e.g. Analysis, development, QA, Integrate, Rollout, Live to Site). This will have great stabilizing and quality effects on the out put of the development system. 

Effect of limiting WIP over time on lead time, standard deviation -> enhanced predictability  

As a third queue, now the input queue gets into the focus. This is basically any portfolio or even the product discovery process of your company.


Coming back to the project vs. product development topic, we came to the conclusion that a project is by definition simply a timebox around a purposeful action of a team. The purpose is in general simply to add value to your product. The whole concept of a project and then project management was born in industries moving tangible goods. Basically, project management is derived from the scientific approach towards labor as invented and described by Frederick Taylor. This was a good thing a the time in the context. Even, Taylors motivation was very humane and philantropic. Anyway, to transpose and adopt the methods into the area of knowledge work and intangible goods, such as software, introduces an unfortunate idea. The idea behind project management is that by planning, the outcome of an activity is repeatable and defined. This is achieved by making detailed plans for repeatable actions, laying out pre-defined dependencies between different activieties, resolving thos in the best manner beforehand, coming up with predefined risk mitigation strategies etc. The focus is to gain control over a large batch size of predefined actions, mainly bacause the transaction cost is so high that you don't wat to get 'out of control' in the slightest.


This approach brings with it certain constraints on a ver serious planning, which increases the overhead on the one hand. Much worse in our opinion is that it rediuces options over the course of the project - learning options and also options of acting. Options will always increase uncertainty and uncertainty is the poiseon of the planability of a project. Option, on the other hand, are wbat you want to constantly improve the value of the product. This is where Kanban comes into play on the portfolio or product discovery level.


In our experience, handling the portfolio on a simple Kanban board, makes your organization optimze against flow of value on the product, rather than on plannable projects - which are a mere bad proxy for value generated. The notion of a project tends to get resolved in smaller and smaller batches until only EPICS or features are left and real flow of value sets in. Also, as the features and thus the batch size and then the lead time decrease, feedback time - real feedback from the market - will also drastically get faster. And this is where we want to be: We want fast feedback on value generated from the real market. 

A standard portfolio Kanban board

There may be many ways to get there, but Portfolio Kanban is a very naturally evolving way to get there without to many steering involved. If you are interested, download and read our in depth analysis in the proceedings of the LSSC12.


In summary, what we found out is that taking care of

•  the output and development queues leads to organizations doing the wrong thing (projects) better (better lead time and overall quality i the system, enhanced predictability), 

but the real deal is 

• handling the input queue with Kanban, which leads to doing the right things right.

Also, we would be happy if you leave comments with your insights and questions!

Arne and Markus 

On Queue Management at the Berlin Hadoop GetTogether

Another video of another talk of mine. Some months ago it happened that, on a walk to a talk I gave internally to some of my European Product Manager colleagues, I met an old and nice colleague of mine, David Obermann. So I told him where I was headed and told me what he is doing right now. Turns out, we made a nice coupe. The talk I was about to give - a short summary of Queue Management in PD and what I made from it at my work in the last three years - was interesting to him and as fate wants it - David is nowadays organizing the Berlin Hadoop GetTogether. So I was invited 'for one of the next meetings'.


The meeting was held on February 22, in the nice environment of the Axel-Springer building in the middle of Berlin, floor 19 :-o with a great view over the city. (You can drive one of the famous Paternoster elevators there.)


Watch and enjoy the talk, which is a shameless collection of knowledge from Don Reinertsen, David Anderson, Eric Ries and of course lots of others whom I've met during the last years. (Thanks to all of them!)  It is also nearly the end point of this stage of my work life, as of 1st of May I will have a different job somewhere else. I'll keep you posted.

Just before the talk started, I was told I only had 30 minutes, so I kept improvising all the time, which led to me forgetting - of course - a central part of this talk, which really holds the theme together. Anyway.