port agile

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

2012-11-28T23:38:00.002+01:00

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

2012-07-31T23:45:00.003+02:00

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

2012-05-22T18:20:00.000+02:00

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

2012-03-05T21:59:00.000+01:00

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.

The Democracy of Kanban - Pecha Kucha from LKCE 2011

2011-12-02T21:55:00.001+01:00

Another 5'40'' that rushed my heart.

Arne Roock (@arneroock) has been so nice and did all the work to not only upload the videos of all the Pecha Kuchas from Lean Kanban Central Europe 2011, but he also sent me a cut down version from only my own Pecha Kucha - 'The democracy of Kanban'.

My basic line of thought is: Kanban delivers a more detailed view on a teams' process. This helps to get rid of he black box view that simple boards of the 'ToDo | Ongoing | Done' structure deliver. The more detailed view helps not only to visualize the workflow better and more detailed and thus get more frequent and shot term feedback, it also helps to do some analysis on what's going on.

The Democracy of Kanban from Markus Andrezak on Vimeo.

In this Pecha Kucha I describe why Kanban is a crucial step towards democracy. Kanban is delivering teams a more detailed model of what is going on in their doings. This helps them to get an outside view of what they are really doing in the software development process. This detailed outside view helps the teams to come to decisions that are based on analysis rather than just a hunch.
This fact, of course, is unnerving to those advocating and selling the same recipes over and over again, regardless of the concrete context of the teams.

That again helps the team to reflect on real data of the real 'system', rather than having intuitive hunches on what's going on all the time. Indeed, doing this, has helped me to get rid of several myths that were going on all the time at my workplace. We found out that we simply do not have a problem with too much variation in requirements sizing (which many thought), we as PD are not a bottleneck in our organization we found that out by mapping our portfolio to Kanban), also some teams got better by just leveling their WIP limits differently.

I am fine and can very well accept that some people might get to similar results with intuition. But not all, very few indeed. We didn't. Many don't. That's why I think that the detailed model enabled by Kanban's visual boards together with the metrics are incredibly powerful means for teams on their journey to continuous self improvement. Guru' are not needed. That's why I think that Kanban is helping us democratize the way tat teams can improve their work(flow).

Oh, BTW ... make sure to watch the great and entertaining LKCE11 keynote by Stephen Bungay on how we lost the art of management that Klausewitz and von Moltke already discovered nearly 200 years ago.

The (limited) value of 1x1 flow in Product Development

2011-11-24T19:14:00.001+01:00

There is a lot of discussion going on in the net right now on the issue of single piece flow as a great tool for ... actually what? This is actually rarely defined. (And I think that is the issue of a lot of misunderstanding and disagreeing on things that are actually agreed upon - context being left out.) Also it is brought into play as a true north for a continuous improvement process - as the means of all means, the end of all ends which will lead to the ultimate goasl - the dissolving of the Kanban. Hmmm. I doubt it. Before we go further let's have a look into the follwing recruitment ad:

Looking for Software Developers

Nickel & Dime Inc. is a new software shop that is working on highest qualty standards. We have opened new facilities that are working under lowest WiP limits. We have achieved a great level of flow. We now want to go to the next level and we are seeking your support: we want to achieve sustainable single piece flow throughout our software shop. If you are not only up for the adventure of getting there but also working under a strict, sustained single piece flow for the next years, no matter what product will be developed, no matter what other factors are weighing in - you are our man. Call us under 0800-111111

This is an impression for the recruitment going on for a company going for single piece flow in software development. Are you likely to hire? Are you likely to stay? Why? Why not?

Let's say Nickel & dime really hasn't achieved 1x1 flow yet. To get there immedeately means revolutionary change. Which problem would be triggering the need for 1x1 flow and solved right away that would justify revolutionary change?

OK, let's not go for revolutionary change but instead use Kanban to control WIP. We lower WIP piece by piece, make problems in the flow visible, caused by whatever issues in handover and development process and environment. We resolve those issues. At least we now have an idea which problems we are facing when we opt for revlutionary change. Let's say all goes well. We achieve 1x1 flow after a certain time. Did we have the right true north now, leading us through the continuous improvement w/ Kanban? That would mean we are in Nirvana now, happy, happy for ever? To answer that question, look at the recruitment ad again. Do we want to develop in strict 1x1 flow for the rest of our time? I guess not. If not, why did we go there, why did we choose that exact true north of 1x1 flow?

Then, why did Toyota choose 1x1 flow as true north? Because in manufacturing, where you want to elminate variability this makes sense. You want to have a great takt time. As Jim Benson of Personal Kanban fame, @ourfounder tweeted today,

"1 pc flow is based on perfect value stream and like sized / defined work items. Knowledge work has high vriation of work items, rapidly changing contexts and fast evolution. Therefore 1 pc flow achieved will either be temporary or for subsets of the overall work. The moment 1 piece flow is achieved for an entire prod dev process, it ceases to be knowledge work."

I might add, that ineed we are making money in PD beacuse of the high variation of the work, because there is no repetition and no equally sized work.

This is completely different at Toyota. They go for a minimum of variation, which is the complexity they have to master. Therefore, getting ever closer to 1x1 is the right challenge and the right true north. Still, they use it as an Utopia, no place nowhere and in fact they will never reach it across the whole line. Even less will they reach the even more favorable true north of 1x1 flow in the sequence of incoming client orders. They still try to - all of the time. They'd even be happy to get there. Except for one reason. This is where the Toyota Kata comes into play, which is embeded into their change, indeed defines their change all over the place. They are seeking for ever new small, but challenging steps getting closer to 1x1. The only reason being to make new production problems visible and trying to resolve them. The reason behind that is simply and at the same time as a stroke of genius to keep moving and in a problem solving mode all the time. What is happening along the line is that Toyota keeps awake and energized and creative all the time. Highest quality, great products, etc. are all great but calculated side effects.

So, if we in our industry take 1x1 as the true north, would we get the same benefits as Toyota? As we are talking about knowledge work and everything Jim mentioned in his few sentences, aren't we rather risking customer focus and generation of value? I have been fiddling with the idea of 1x1 flow for a long time now - because it seems attractive, elegant, compelling. When I think it to the end - for myself - I come to the conclusion that this leads to inward bound, process releated activity rather than customer facing benefits. It gets a stale, dead end best practice with no added value.

I do see a value in 1x1 flow, though, which is using it for a sgort perod of time as a didactical tool to show teams definciencies in flow, excessive handovers, immature PD processes and environments. It is a tremendous learning experience in our field - for a certain time. No more, no less. WhenI talk about 1x1 flow I will make sure that this is the purpose I see in it.

Kanban done right will actually help to achieve Rightflow, the right level of WIP under the given context.

What do you think?

Replenishment - Craving for Feedback :)

2011-11-15T15:04:00.001+01:00

First off: We are incredibly greatful for the response we have received so far. Thanks to all of you!

When we published the book - of course - we had plans. We also had vanity metrics in mind. We wanted:

200 Downloads
50 filled out feedback forms.

What happened is nothing short of amazing: We have more than 1100 downloads from close to 50 countries. But: We are short of reviews and feedback.

Why do we need feedback? Short question- long explanation: The whole book is a multi variable experiment to us. There are a lot of things unknown to us:

Should we even write a book. apart from the vanity effect of writing a book, the question is: Is there a market for a book, which means are there interested readers out there, which means do we have topics that people are interested in? We don't have a clue. (Still.) The question, of course, is - why embark on a long (high WIP-limit, large batch size) unpredictable journey if it may not be relevant?
Which of the topics we could write about are most requested, driving most demand.
General questions on writing a first book: which format(s), normal publisher vs. self published, distribution channels (eBook vs. print book), etc. We had the trigger when amazon came up with the amazon single concept, which made us think - ah, we can just publish something in small batch size whenever we want. (And we already drfited away from that a little, I guess).
A million other things, basically we don't know a thing except that we some experience in some aspects of Lean and Kanban that might be worth spreading.
Is a German language edition important, or will English suffice?

This means, circulating a small shot and geting feedback on it is a chance for us to learn. Hence the feedback form.

As we said before, the first part has worked out brilliantly! We have more than 1100 (!) downloads in the various formats. (Still more tan half of it in PDF format, which to me as a die hard kindle fan was the first surprise - I thought most people in our community already ditched paper books, PDF etc. for the more convenient and functional formats of .mobi and .epub.)

Now comes the hard part. We planned for 50 feedbacks. We have ... less than 10. Of course, we can't expect too much yet - the book simpy needs to be read first. Also, of course, people have to *care* to give feedback. So, not getting the feedback is the first indication of not being on the right track. We also think, feedback needs time as opposed to ... downloading (for free).

The feedback we have is actually already great as it includes the statement from someone important to us and the community that it gave him the last impulse he needed to also start writing a book. (If this is all the effect we had, it's also fine!)

In short: We would *love* to hear from you:

http://bit.ly/replenishment_feedback or in free form to replenishment@portagile.com

Thanks for staying with us

Arne and Markus

Replenishment - Free eBook published w/ Lean Kanban Central Europe 2011 conference

2011-10-17T09:00:00.000+02:00

Edit: We extended the free download until mid November, so that attendees of LESS2011 in Stockholm can also download and comment on the eBook. We already have incredible 800 downloads of the book. We now are really keen on your feedback :)
Thanks for all, Arne & Markus

I am happy to announce that today, with the opening of the Lean Kanban Central Europe conference, Arne Roock and me published a free eBook "Replenishment".

The book's cover

It contains 4 texts on Kanban:

Wip Limits
Guarantee bandwidth for intangibles to address sustainability of your business
Tool Support
Project Development vs. Product Development

Our preface explains why we are publishing this free version of the book, so I'll just post it here:

Dear audience,

You are holding in your hands our approach towards a MVP on an eBook on Kanban in the form of loosely coupled essays. We would like to publish it as an amazon single, comes time. Time shouldn’t be long, as the real benefit of publishing eBooks is that you can get away from large batches sizes to small batch sizes, even in publishing. We are thankful for these new options and would like to explore them.

As this is our fist publishing of this sort and we are yet developing our model we wanted to take the opportunity to publish the smallest possible batch to you for validating our model. We assumed there is a demand for insight in the short form. We also assumed there is a demand for loosely coupled topics that came to our mind which aren’t covered in long form. We assume we should rather hit sooner than late. We also assume that in later phases of the project we publish more amazon ebook singles and can very well imagine to broaden the content by including numerous other authors.

You now know what we assumed. We have prepared a feedback form and would be happy to receive feedback from those interested. The feedback does not only check our assumptions but leave space for feedback on anything that comes to your mind as well as topics that we have not covered but are of interest for you.

We had the idea for this book while thinking about the great KLRIS event, organized, of course, by David J Anderson and made the approach more concrete during and after this event. Thanks again to David and his team for coming up with this great event and thus the inspiration! (The KLRIS event is also brilliantly covered in a free eBook ‚Quotable Kanban‘. )

Some note on the cover photo and the title of this book. Standing in front of the famous Geysir Stokkur (and in fact bigger, but younger brother of the actual Geysir ‚Geysir‘) and being still inspired by two full days of discussing Kanban and its future it was obvious that this is one of the most brilliant examples of replenishment. And also, what is the whole of Kanban without proper replenishment? What happens downstream if upstream doesn’t work and what is more upstream than replenishment? Indeed, Kanban leads us the way to exploit the opportunities of clever replenishment. Read more on this in in ‚Project Development vs. Product Development’. So, rather than going for a shallow effect of showing the eruption, we go for the deep result of serious, powerful, value defining replenishment.

We hope you enjoy and have fun reading our (still) small eBook and don’t forget to give us feedback! It’s appreciated!

Arne & Markus,

Hamburg & Potsdam, October 2011

You can download the free version of the eBook until end of October from the following links in mobi (kindle), epub (most other ebook readers incl. iPad) and PDF formats under the following links:

http://bit.ly/replenishment_kindle

http://bit.ly/replenishment_epub

http://bit.ly/replenishment_pdf

As stated in the foreword, your feedback is greatly appreciated and crucial to us. We prepared a feedback form under

http://bit.ly/replenishment_feedback

There you can also leave your email address if you want to be informed on updates and the final version we will sell over amazon in the not too far future.

You can also leave feedback via mail at replenishment at portagile.com ...

Thanks for your patience, interest, download and feedback

Markus

KLRIS

2011-09-19T23:16:00.000+02:00

... stands for Kanban Leadership Retreat Iceland, which took place in the wonderful Icelandic summer 2011, luckily one not being impacted by any physical volcanic activity (even though I've learned that the people on Iceland love and repect but do not fear heir volcanoes the least.)

Replenishment

It was a gathering arranged by David Anderson to answer demand from the best trained and most well known Kanban coaches and practitioners around the world to discuss matters. The event was organized in the unformat of an unconference.

Famous German Kanban Authors ;)

If you couldn't make it, don't despair. Today David has published a free ebook, edited by Janice Linden-Reed, full of quotes covering several pillar topics of Kanban like Foundation, Transitioning, Visibility, Limited WIP, Measurement, Flow, etc. The end of the ebook also provides some longer contributions by Arne Roock, Al Shalloway and Jim Trott, Mhesh Sing, NIcholas Muldoon and also yours truly w/ 'Estimates are overrated' which you could already read here. The book contains a slightly revised version of the text thanks to some editorial work by Janice Linden Reed - thanks for the support! The text got so much better and clearer after review by Janice as a native speaker.

Thing area - birth of icelandic democracy

Please enjoy the ebook! Browsing through the ebook happily today, I was really amazed how good the experimental format of collecting quotes works. It really captures some key Kanban insights as well as some of the spirit in Rejkyavik (esp. for those who haven't been around).

Anarchy in Iceland?

There have been many insights for me in (on?) Iceland. There is one insight I had, which is rather on a quite meta level, that I want to share to reflect on the state of the community. And this one insight was not easy for me to digest in Rejkyavik itself but grew on me ever since.

close to ...

... bursting

Regarding culture, background and experiences we have been quite a diverse crew gathering in that hotel. To me that was quite a challenge at times. You can not imagine how complex it was in some of the sessions to nail down the topic that actually seemed to be so clear to me in the beginning. Just take a topic like ’Portfolio Management’. Already having contributed a chapter to the German translation of David's book, I was sure to have a grip on the topic. But after only some minutes I was shocked by the wealth of different contexts in which Portfolio Management may take place beyond what I experienced until then. There was quite some time of cognitive dissonance and dizziness in some of the sessions for me, summing up the whole picture of all participants. What is now left for me as the basic impression and insight is the openness of the leading Kanban Crew and most of all the openness to not only try to verify the Kanban model but to also look out for falsification.

Famous German Kanban Author before nearly drowning in Gullvattn

In short, I love the community, I loved the retreat and I really loved Iceland.Thanks a lot to David and his whole team for making it happen!

Go on and don't hesitate to download the ebook, read, enjoy and capture some of the spirit of those great summer days on the Mid-Atlantic Ridge. It's a gift :)

Thanks for your attention,

Markus

Me, stoked by Ielandic nature

Some kind of queuing effect (including at least one broken rib)

2011-07-12T07:12:00.000+02:00

There are some amazing queuing effects. This one, not the worst, but not a funny one also, I encountered myself. Since then I know that breaking a rib means not only counting off the time until the rib is healed.

And the story goes like this. Once upon a day I rode my bike home from work - through a nice forest as usual. Then I received a call on my cell phone. Nice, friendly, communicative and outgoing guy I am, I - of course - answered the call, riding on. Then there was this log lying around and I went - whoops - over it, landed on the right side of my rip cage. I was immediately breathless and felt something's wrong - but after getting myself together for a few minutes I could just ride home. So, I thought to myself "you just broke a rib" and started thinking about how long I couldn't run (which was important to me at the time), and for how long I'd be handicapped somehow.

And here comes the fallacy. I thought of being handicapped for about two weeks, which I would be a decent time for the rips to heal off at least a little and the pain to go away. What I didn't think off was that due to the pain I couldn't breath very well. That led to me not breathing deeply. Which again led to the air not flowing well through the deeper areas of the lungs, which again led to bacteria residing in the lower bronchia. Which of course led to me getting a solid cough. Which led to more pain, which ...

It took quite a while for me to get over this. And the general state of health of my body went down for some time. Even after getting better my immune system was down and I was getting colds quite often. So, overall I couldn't run for about 4 weeks at all due to the cold and a general weakness and I felt quite bad for at least two months, but my whole system was handicapped form something like more than a quarter of a year. And if you think I am a one off with that queuing effect or a quitter or ... (and you could go on and on describing what leads to what) - you're plain wrong. This was a very normal pattern for the consequences of breaking a rib. Old people even die often from these consequences, acquiring a pneumonia from the reduced breathing caused by the fracture.

If you don't believe me, try for yourself ;)

A 4HB update

2011-07-06T06:59:00.002+02:00

My ~~4HB~~ update to you is that in my context ~~4HB~~ currently does not make any sense. As you can read here, I at least in my own opinion had quite a success applying ~~4HB~~ to my personal target of getting rid all of that schlumpy access weight I gained in the last years after getting kids, changing life style after that and so on.

I reduced my weight to some sustainable 82kg, coming from ~~92kg~~ (I don't even get it now that it was that much). After that I wanted to further reduce my weight to a 12% body fat bearing 78kg with 4HB and I even bragged about it. I won't do that, even though I'm quite sure it would just take me a couple of weeks. So the first message is again: ~~4HB~~ works.

BUT: For me it has a specific target, which is reduce as much body fat as possible in the shortest possible time frame. And it does that well. Reading the book I am sure that @tferriss refined 4HB for that exact same target and he seems to have needed and applied it to some specific targets in his fighting caterer etc.

So to come back to why I dropped 4HB for my target of getting down to 78kg. After a little research it became apparent that Ferriss took the Paleo diet and stripped it down a little in some details and made it more practically applicable by formulating some strict, simple rules and overall simplicity.

Now this is exactly what drives me away from 4HB - the simplicity leads to nutritional behavior and simplicity that I just don't like and which doesn't feel natural to me. With 4HB that is not even intended, I guess. As I said it is not supposed to be fun, taste well or anything. It's intended to shave off weight quickly. There is just one effect that makes me a little suspicious in 4HB. On the binge days you can experience increase in body fat in just one day. If you stop 4HB you will gain quite a lot of body fat in your next two weeks. To me it indicates that something in 4HB is tricking the body in a way that's at least strange, as with the same nutrition without 4HB you don't gain body fat. To me it seems that the fat cells get so depleted that they simply get hungry and take all they can get, which is a long explanation for the yoyo effect.

Coming back to Paleo diet, which has a completely different target, which is to offer a sustainable nutrition pattern or paradigm, I don't get it at all. I guess for a carnivore it's fine. But for me as a vegetarian, I don't even get started. Yes I've read all through the Internet for the few experience reports and hints on how to go Paleo as a veggie, but nine looks convincing and sustainable to me. Challenge me on details in the comments.

Now what I am going to do seems a little harder to me but also more convincing and - main point - more sustainable. I'll follow the advice of the great book 'Vegetarian Sports Nutrition' by Ennette Larson Mayer published by Human Kinetics. The point made in this book is, and I highly embrace it, quite the contrary of Paleo and 4HB: Your nutrition should be as diverse and possible and rather than concentrating on complex carbs you should work on the right mix between complex and simple and refined carbs. This means a high variety in grains, wholebfood, legumes, vegetables etc. Sports drinks are ok, if you keep level. The recommendation is to find the right level of proteins, not to concentrate on them. You should eat fruits - and lots of them. (As there is no indication of fruits spiking the blood sugar, it's even supposed to be weight neutral.) And so on, and so on. In short it seems to be a holistic, sustainable approach to nutrition and this, I guess, is my next challenge rather than just going down some kilos. 4HB gave me a nice trigger to make nutrition a topic for well being but it now is what it is: A method to reduce weight quickly, which I don't aim at. It'd be the wrong tool for me.

Estimates are overrated

2011-04-20T00:38:00.000+02:00

Wherever I come, whomever I meet, in each and every organization estimates seem to be a problem (and mine is in no way better). There are various sources of problems with estimates. The most common symptom I see is teams taking too long to estimate because they take it too serious. This leads to the typical complaint that method X bears too much overhead, the meetings are too inefficient, boring and cumbersome, and finally the whole of method X is under question.

A typical situation in this context is a longish discussion if feature US12 has 5 or 8, maybe even 13 feature points. Gosh! You can read books on this issue. The even tell you what to do. This situation is supposed to be a clear indication of uncertainty in requirements, which you can resolve in several ways, most of them involving even more overhead. Heavens no, the enemy entered the stage: Variability! The PO must really be a prick! A more modest assumption may be that the team is unsure of the implementation approach, architecture, design, task breakdown, yadayadayada.

First of all: I don't blame the teams in this scenario. The environment in which they live must have signalled to them - in whatever subtle way - that their estimations matter. To say the least. Hell no - the estimates don't only matter, they are part of your commitment and before you say "f$%^ no" the team's commitment is a commitment to a timeline, depending on no less than a tight sprint plan, release plan, which again depends on the correctness of all estimations of the other projects, on the limited variability of all the features any talented PO can think of etc. If you leave this blog for only 5 minutes and try to brainstorm on the dependencies of our current project you will go blind and depressive at the same time. If all those dependencies were really embedded in your 'planning' and thus in your estimations and your commitment you might as well stay home and never touch your keyboard again. But anyway, your rent needs to be paid, so you come back to your mind after the 5 minute break and another cup of tea, destined to go back to work tomorrow, no matter what. At least you now know that a) your estimate can not contain all uncertainties and is only a best guess snapshot of your current knowledge and b) does not matter that much in that context.

Another symptom is that teams can not decide on the estimation process (planning poker based on Fibonacci, planning poker based on any natural numbers, split up stories above a limit of 21, estimate in days and numbers (no stop, I'm back to just hours), classical function point analysis!, ... ) I'm getting nauseas over all the decisions you could feel forced to make. And people can get religious over it. They do.

What I will tell you now may let you relax a little over all those micro decisions and estimates. It may well be that what I think and say only matters for some areas, maybe 40% of software development. I personally think it matters for around 80% of software development (or all of it once one got the point). Anyway, here is what I think.

Don't care (too much) about your estimates. They don't matter too much for several reasons. One not so sublime reason is that while one might think it makes sense to get the variability out of the estimations by science and sound reasoning, I do think that most of the variability simply levels out statistically. One time you estimate too high, the other time you estimate too low. If you have a systematic error in your estimations, that will be learned by the team over time and level out this way.

The more sublime reason which will be much debated when you bring up this topic is that estimations where brought into the world for the wrong reason and support the wrong reason and they don’t even do it good. Estimates support the wrong approach. Estimates are good for chasing time lines, but they are no good at all for judging value created, value to be created, complexity of a certain topic etc. To explain that, let me change the perspective: Think of my job where I am working on a standing organization honing and fine tuning a standing Internet product (for years). So, I am talking about product development right now, just to make the point more clear. If you are an (even a small one) amazon, ebay, google, whatever revenue generating product with a margin in the internet you are only talking about product development. By that I mean the constant refinement and change of our product. And my statement is that timelines do not matter in product development in general. There may be some very few exceptions, e.g. the infamous press conference to announce your product change with your product going bang into another direction at the same day, 10 am. If your Corp Comm Dept. is clever they know how to rip this event off and make it a success without going into the details as much as generating an issue when a certain percentage of the product is not ready. (Yes, I’m saying that even in this case the exact timeline makes no sense). What matters is the right spirit, (fast) user feedback, ideally a constant flow of product changes to try out new angles and if you're really good a good approach for handling the white space out there to keep innovative and not getting 'MySpace'd' by another facebook.

Timelines are only good for blaming people. Blaming people who have been stupid enough to commit for timelines they could not hold any responsibility for and then couldn’t finish 110% of the features. The world is too complex to maintain timelines and have people getting shot at.

In general, going for the timeline is the same mistake as going for utilization. Reaching any or both targets does not proof a thing. You may keep a timeline and keep utilization high and still have a crap product. It's the same as you should not commit to a Scrum sprint regarding a set o features or user stories but rather on a goal. And the goal would be something like, publish product part X – and in the sprint have a lively productive discussion how this is feasible, which features are necessary, which can be simplified, descoped, which ones need to be more elaborate etc. If you’re lucky you can get closer to value generation by having users opinions as a main influence in these discussions. And guess what - for this approach you don’t need exact estimations. I go as far as to say you don’t even need clear requirements. What you need is much harder to achieve but harder to describe: You need a clear goal and a deep and thorough common understanding of what it means to reach that goal.

In this scenario, no doubt, good estimations can help coming up with good real options on the way of reaching the common goal. But being a few points off does not matter at all. But for sure, an organization with that level of understanding would never burn an individual or a team for not keeping a timeline. (And the teams themselves would be the first ones to ask themselves what went wrong an punishing themselves for being off too far.)

So, my point was: Set clear goals on a quite abstract level, estimate to catch a glimpse of your current understanding of the complexity of your current goals (or your next releases etc.). Reach those goals by an intelligent negotiating process in the team coming up with a set of good options and choosing the most pragmatic and realistic ones. In this setting estimates support you on a very high level but need not be exact. As a rule of thumb, discussing an estimation of a User Story for more than one minute seems to be overhead to me. Really.

Now, why do I think the same holds for any project rather than product development also? Simply because product development is done in … projects. So, a project is simply an organization form and in itself means nothing. In the scenario of a software shop delivering a project to a client, the project will simply be a part of some other product development process. And absurdly, the one project (yes yours) can not be so important with regard to the timeline as to treat it differently than product development should be treated. I know, I know – your client doesn’t see it that way. But that doesn’t mean you have to see it that way (and you can still do an excellent job, delivering all you have to deliver). To get a grip on the overall risk and variability of your current project just listen to some aspects an examples. I once committed to building a major international job portal based on three lines of requirements in Excel with a team of six developers. I knew what I had to do. I had to meet the client each and every week to exactly find out what he needs, where we need to be strict, where we have Leeway, finally to make clear to him that if I fail the problem is bigger for him than for me etc. What role would exact estimations play in this context? Or: do you think that you’re much better off in your current project, just because you have 157 User Stories in a DEEP product backlog? How deep is the level of common understanding of the details of those User Stories throughout the team? What if you overlooked that line that means you do not only have to integrate that SAP HR systems but adapt it also? Or on a smaller level – what if your release cycle is 6 weeks and miss the spot by a day? (Yes, you now lost six weeks based on a three day User Story). What use are your fine grained estimations now? I guarantee you that the little variability you have in your estimations is negligible compared to the rest of the uncertainty in your project and that there is a) no way to drastically get rid of it and b) no cheap way to do decrease that level of uncertainty to a very small level. Further it is just the wrong lever you’re pulling.

The bad news is that what you have to do is much harder and on a different level but much less technical an less process etc. You will have to be clear about what you want and you have to be good about what you’re doing as a profession. This means you have to have open discussions in your team. Where estimates help you is to get a good common sense of your basic speed.

If you ever get the chance to play a round of getKanban, you will have a lot of counterintuitive learning experiences. One of them is that the variability of the User Stories pulled across the board plays a minor role. Lead time is king here, and the learning that waiting times dominate actual work times lets lead time dominate ever more. That means the worse and less lean a system is, the less important god estimations are. In fact, the worse the system is, the less probable are good estimations. The other observation is that (nearly) no one blames the variability of the dices (1200% in getKanban). And finally you will learn that simply watching the lead time of your work pieces together with the visualization of the wok flow, explicit rules and the daily discussion on what to do how will never let you miss a beat. The teams, with all the variability in the game, very seldom miss a fixed date ticket.

My experience with 'The 4 Hour Body'

2011-03-24T00:39:00.001+01:00

Some 10-12 weeks ago, I heard of Timothy Ferriss' new book 'The 4 Hour Body'. Having read his first book, 'The 4 Hour Work Week' I knew I had to expect something which screams 'marketing' in my face. On the other hand, the extreme, hacking like approach of Tim Ferriss somehow appeals to me because of his playfulness and openness. And, Tim's writing is quite motivating and eye opening. I didn't quite like his first book, simply because I very well believe that the 'tricks' he is offering are surely working for him, but wouldn't work for everyone. I guess he knows that, but he's selling those tricks as though they'd be working out for all of his readers. Anyway.

In his new book, rather than describing life hacking, he describes how to hack your body in several ways. He starts off with how he's always looking for the minimal effective dose for anything: How much training do I have to do, to get a certain effect? How few do I have to change my habits to get rid of body fat? How much training do I need for running 50k rather than 5k, etc. Although in most aspects I do not share the search for the minimal effective dose as an aim in itself, I share the search for it as a means to understand certain effects. Regarding running I do not want to limit my efforts to the minmal effective dose, as I am looking for other things in running, like calmness, flow, quality of life etc. But to understand how to improve certain aspects of my training, I do like the idea of understanding effects of isolated aspects of training physiology and thus minimal effective doses of certain training forms.

The first two chapters cover body recomposition. Then come other interesting chapters on how to hold your breath for 3:30 mins with one day of training, the female 15 minute orgasm, etc. I will only talk about body recomposition and especially body fat reduction. Tim suggests you should do a body recomposition programme of e.g. 20 pound, which might mean losing 10 pound of body fat and gaining 10 pound of muscle mass (core strength, ideally). I'm not short of muscle mass at all, but I had gained a certain overdose of body fat through empathizing w/ my wife during pregnancies and not having the chance to breast feed my kids afterwards to lose some pounds again. So after stepping onto the scale after some ten years, my weight was not at 78 kg but at 94 last October. After buying a Withings scale my weight dropped by 5 kg down to 89kg in 3 months by changing nothing. That was fine! But reading 4HB gave me the idea that it might be possible to do the weight time warp and come back to my loved 78 kg.

The suggested diet reads extreme, because it has an extreme goal, which is to reduce as much body fat as fast as possible. It's not a fun diet. So I was hesitating to start:

No 'white' carbohydrates: Short chained carbs (sugar, flour, pasta, bread) mostly appear in white form or could be white. The problem with these carbs is that they get into the blood quickly (high glycemic index GI). They serve only one purpose physiologically, which is to deliver energy quickly. If they are not needed, they get transformed into body fat. Worse, high peaks in blood sugar lead to emission of insuline, which reduces the body fat metabolism. So you do not only take in stuff you don't need, but taking in that stuff also leads to not getting rid of it again. Bad deal. White carbs only make you fat. They give you nothing you need :-/
Eat the same meals over and over again: This is just so that you don't start thinking in the super market and so that staying in the diet is easy.
Don't drink calories: Water contains all you need, everything else is fun to drink but does not serve the extreme effect and purpose of this diet.
Don't eat fruits: Fruit gets transformed to body fat storage in general. there are some exceptions, but they are complicated, so don't bother. This is another simplicity rule.
One cheat or binge day per week: Not only is the diet hard and for most people the inflicted changes are hard to maintain. But in the first weeks most people start craving for sweets, nice deserts, a fresh coke, some orange juice ... whatever. This rue has two aims: a) Have one day off of the strict regime of the diet, b) Although you can eat as much as you want, as long as it is mainly proteins, vegetables etc., there is an effect to it tat reduces overall metabolism. The binge day trains the bodies metabolism and keeps it at a high level, which is good, as we want to have a high rate of base metabolism when we want to reduce weight (body fat).

There are some things which are somehow mentioned but not made explicit enough in the book for my taste:

It is important to understand that protein is the main ingredient, because protein is split up into amino acids, which are again the building stones of muscle. By increasing fat metabolism and at the same time feeding the muscles with amino acids we make sure that good muscle mass is not reduced.
The diet works by avoiding blood sugar peaks, thus avoiding insulin emission, thus increasing fat metabolism. many people don't believe this is possible, there are lots of rumors that fat metabolism can not be influenced by which food you eat. Bit is now widely scientifically accepted that you can increase fat metabolism by at least 35% by changing what you eat.
As I said, the other effect is that you don't eat any useless carbs.

Understanding these principles helped me a lot in improvising through my work days and conferences. It shows that mexican, indian and thai food are good if you leave out the carbs (rice, noodles).

My normal day looked like this:

Breakfast: Green tea (good effect on general metabolism), Soy protein shake ('cause I couldn't stand eggs three times a day).

Snacks: A handful of nuts

Lunch: Salad with lots of eggs and legumes

Snacks: A handful of nuts

Dinner: omelette w/ tomato, vegetables and legumes

Lots of green tea and water. You need to drink a lot, as the rapid fat loss is bad for your liver (body fat stores lots of bad stuff).

After starting the diet, as I was a white carb junkie before, the first days felt veeerrrry strange to me and only my enthusiasm kept me going. I felt hollow and weak, but very light. I couldn't concentrate very well, to be honest. But I already lost up to a pound / day. On day 3 I went to OOP 2011 in Munich. My experience, waiting at the airport was enlightening. OK, I go to Starbucks - not possible, all drinks there contain calories. Well, then I go and grab something at the baker - not possible, all white carbs. Etc. You get the strange impression that the food industry is only selling useless carbs, and I now come to the conclusion that this works because they are selling it for the kicks. Human beings LOVE the kick they get out of the blood sugar peaks (but they don't know it, still: they're craving for it). After being on 4HB for a week, it gets completely clear to you that white carbs and the blood sugar peak they produce are the most archaic form of an addiction. And the industry out there is not selling via nutrition and health, it is selling via this kick. I am absolutely sure of it now.

If you think a little further, white carbs are responsible for diabetes, all kinds of inflammatory diseases up to cancer, rheumatism etc., they are responsible for body fat, heart problems, they make you overweight, obese, which leads to joint an back problems etc. All modern diseases are somehow depending on a constant flow of white carbs.

I don't want to go into too much depth, but here are the effects 4HB had on me:

I started the diet on 24 January 2011, at 89.5 kg. I ended the first phase last week at 80.5 kg. These are 9kg weight loss in 7 weeks. Out of the 9kg, I lost 7kg body fat.

This had several secondary effects:

I was suffering of lower back pain since about 30 months. It's gone. Completely.
I was heavily into running until the birth of our first child w/ a PB on the half marathon sub 1:30 hrs. In the last years I couldn't catch up running regularly, as whenever I got into a regular training mode, either my achilles tendon got inflamed or my knee hurt. Now, my tendon is fine and my knee only hurts a little. I think this is the effect of body weight reduction. This allowed me to come back to my old high cadence running style, in which I am going for 180 steps per minute, reducing my stride length and thus reducing the impact on my knees.
My training pace reduced immediately from 5:45 to 5:15, a training pace I didn't reach since 5 years.

As we are now going to Spain for 3 weeks, I have stopped 4HB to better blend in w/ my family on vacation. After the vacation I will pick up 4HB again to either reduce my weight to 78kg (nearly ideal running weight) or 12% body fat (even more ideal ;) I will also pick up some of the core strength exercises mentioned in the 4HB book to further reduce the impact of running on my core strength chain of muscles and tendons.

If you're interested in my further 4HB success I'll happily keep you updated. Don't hesitate to post comments or questions on details.

Kids still have small batch size instincts

2011-03-07T00:21:00.001+01:00

Today I was at a carnival party with my two kids. Like me, they had been disappointed, so my mind mind started wandering and I wasn't really into it. But at a certain point I received a wake up call:

The kids were playing a game where they had to collect as many admission cards as possible from the grown ups. The kids had been called onto the stage to get explained the task: Go and collect as many cards as you can from all the grown ups in the room (admission for kids was free, so only grown ups had tickets). I guess it was by mistake that no time limit was explicitly given and no end signal was told when "collecting time" would be over. Music started and the kids started collecting. And collecting. And collecting. And they collected. And so on. Now every kid was already laden with tickets. But none of them brought their tickets to the "referee" of the game. It was a perfect raw at the time. No one had delivered any tickets (value). Now the hosts realized that they hadn't really explained the main rules to the kids:

Only those tickets that are delivered to the referee are counted.
Only those tickets that are delivered to the referee in time are counted. But no knows in advance when time is over. The signal of time over is simply that the music stops. Uncertainty is brought into the game.

As soon as the hosts explained those rules (while the kids where still collecting ... and collecting ... and collecting .... and so on), the kids completely changed their way of work from large batches to small batches. All of them instantly delivered their goods to the referee to mitigate the risk of not delivering anything before the music stops. During the remainder of the simple game, all of the kids delivered the goods in small batch sizes, further mitigating the risk of not delivering enough (value) in time.

I was quite happy watching this and it was great to see that these kids hadn't been consciously making a trade off between higher set up (or delivery) time for commuting between the audience and the referee and delivering value to the referee. They just knew they'd be sacked if they didn't deliver value. It was also great to see that they didn't even have to think about the need to reduce batch size.

What a diference to our industry, where it is still at times had to convince individuals and teams and Management of the manifold of advantages of small batch sizes like

risk management,
early feedback,
low coordination cost,
lead time etc.

It was also interesting to watch that none of he kids chose single piece flow, as they felt that in tis setting it makes no economical sense. The holding cost was low, but the transaction cost too high for a batch size of one. They rather chose batch sizes in the sweet spots between 4-10 to manage risk. As the time went on, they reduced the batch size to further reduce the risk of being too late with too many tickets.

For a long time I will remember this game as a perfect example of the value of small batch sizes in risk management while delivering value.

Kanban - german edition of David Anderson's classic published

2011-02-12T21:37:00.005+01:00

This post is refererring to Arne Roock's Blog Post on the publishing of David Anderson's already classic 'Kanban' wich is now also released in german. The book was translated into German by Arne and Henning Wolf. The publishing was celebrated at the OOP 2011 in Munich with some events and talks on the topic and David made no secret out of the German edition being updated in some chapters and containing an additional chapter by me.

The German cover - quite different

I can only imagine how hard a task this was, as to me the original is already a nice, soft read focusing on the purpose and motivation of Kanban and reflecting this in a very soft and understanding way. I followed the translation from the beginning and have to take my hat off on how well this book was transferred into German. If you get hold of the book, just after a few pages you will realize how good the translation is - especially compared to other books in our industry.

As mentioned before, I contributed one chapter to this book, the last chapter in fact. In this chapter, I describe how we apply Kanban to Portfolio Management at my work at mobile.international GmbH, owner of Europe's largest car classified site. My latest view on what we're doing with this is that we are managing demand load on the system that is provided by our PD department. Actually, we are managing the waiting queue for our department. From a distance, every project needs to wait in two waiting queues. One is more simple but has more impact. This queue is the portfolio management. The second queue is the actual PD workflow, in which every committed project is realized. The whole system is roughly the equivalent of a shop where you also have to manage two queues (if you're in bad luck ;): First you have to stand in line to enter the shop (if demand is high enough - or actually: too high) an then you have to manage the queues in front of the till. You don't want to have customers waiting in any of these two queues for two long. But for this not to happen you have to actively manage the queue length - and give it all you got. (The better metaphore might be an airport, where you mostly have to queue up twice: check-in and security - basically quick ckck-in machines are then a better way of portfolio management with less overhead and security, well ... let's not think of the TSA nowadays ...)

I may expand on that in a future blog post or article. I actually gave myself the task to try to find out which queue has what impact on the whole system.

If you have a closer look on the 2nd queue, the PD department itself, you can see that this queuing system consists of quite a few queues itself - from requirements to delivery. And this makes clear the task of the PD department - apart from just delivering projects the task is trying to deliver the projects in a way that the queues are short and the 'customers' are happy because the queues are short and stuff is delivered with short wait cycles. And, oh boy, here we find livers the dime a dozen ;)

Actually with the publish of the German edition of David's Epic I was humbled twice. First, in the foreword Arne and Henning mention me in a way that is just too kind - but one should never should say no to compliments. And second, I was quite stunned and humbled when I was asked by David, Arne and Henning if I would like to contribute a chapter to this book. The idea came up after I visited the Lean Kanban Belgium 2010 conference (quite well organized by Agile Minds Belgium - I will come back to this great conference as well as the LESS 2010 in Helsinki in my conference summary of 2010 later in this blog), where I held a talk just on this topic, which was attended by David and some other smart guys and where we had a lively discussion on the topic. So, in fact, the topic actually hit a nerve and resonated well with this great audience so that the idea stuck to write the whole thing down. Thanks again for giving me the chance, guys :-)

So there you have it - grab a copy, read the book, read my chapter, give it some reviews on amazon and give me or the other guys involved some feedback via Email or twitter. We would be happy!

Edit: A great in depth description of a Kanban introduction given by Henning and Arne to celebrate the publish of their translation is given here by Markus Gärtner.

The (success of the) iPhone will be a midget to (that of the) the iPad

2011-02-05T00:41:00.001+01:00

Edit: This is just a reporting of an old blog post of mine from another blog. I haven't been that wrong - which is ok, given the blog and press reaction of the skeptics at the time. But Ibhave to say that Android adoption goes up at my workplace and that Honeycomb still isn't my cup of tea, UI and UX wise but it might work well on the tablet market.

Years ago, early in the morning I stood in from of our offices. I work at a geek place definitely. I, a geek myself, work at a geek place, definitely. The evening before I just received my iPhone.

The clumsy procedure involved me having to drive to an ugly customs office with depressed and demotivated customs guys having a ball on trying to make me feel illegal because the iPhone was still supposed to be illegal when you unlock it. Yes, and I tried to save the import tax ;-) Anyway, I drove home and had the iPhone set up in 5 minutes time, I had it unlocked and jailbreaked in another 5 minutes. And I had all the music I needed synced in another 5 minutes, I guess.

Standing in the cold in the front of my office it didn’t take long and other geeks working at my place came along. the iPhone thing was quite new and I still an early adopter. The other early adopter syndrome plagued guy, my brother, didn’t yet have it. I knew right away what would happen: Hide or be bashed. And so it was: All the gees at work were so smart: Oh, you don’t know there’s no copy and paste? You surely know, it’s only Edge, no 3G, do you? You know the camera is crap compared to my 5MB Ericsson/Nokia, you name it bla bla device - and so on and so on.

What was bothering me right away was the fact that all the guys were working for the same company as I did - an internet company making a fortune on an internet product. So, I guess they shouldn’t be blind to the fact that all the shortcomings of the iPhone were more than compensated by the incredible and before unseen simplicity and elegance of the User Interface - and that despite of all the innovation behind it.

At the time they were all waiting for some new fancy linux based PDA or this and that or the newset fancy Nokia with any useless navigation on it and god knows what.

You know what happened. Today they all have iPhones. All of them. They even disrespect it (some of them) by placing it in a strange dock beneath their work station. Sure, the new cool thing for a developer is the Android (the good vs. the bad - again, so it’s good that google makes a statement towards China so that they are bit more ‘good’ again ;-)

And now - dejá vu - the whole geek planet is again complaining about the things the iPad is *not* and thus being blind to see what the iPad is and what its potential is. (And all the opportunities it will open for geeks and developers as well).

But guess what: It is a mass market device. Apple does not enter markets anymore with niche products to gain momentum. They have momentum and can directly address the large crowds.

Geeks may be disappointed by the iPad not having USB, exchangeable battery (again), no real keys, no extendable memory, still a closed environment, no camera!!!, etc. And yes, they are all shortcomings.

But my mum will be delighted. She doesn’t even want to know what USB is. the doctors running around in hospitals, using the iPad for documentation will not care about battery life, the sales forces don’t care about the keys and so on and so on.

The content providers will be more happy about the new revenue stream provided by the new marketing channels than they will be unhappy of the camera being added in v 2.0 of the iPad and concurrency in OS 4.0.

And guess what, all my geek colleagues will love to surf, watch movies on the couch, chips and beer on the side, an iPad in their hands in just some months.

The iPad will be Apples biggest success ever, whatever its current limitations are, because it defines several completely new markets and revenue streams.

(From an agile perspective: We always drive business to be content with a very minimal product to enter the markets, learn on the market and only add the features that are absolutely necessary to drive demand. It seems that many, as customers, do not like what the preach as those crafting the products ;-)

Where have I been?

2011-02-04T14:52:00.001+01:00

Oh my, I don't actually know what happened.
Yeah, you know - if you watched, which I wouldn't expect from after having been neglected for a loooong long time: Nothing happened :-(
I guess, the reasons for not updating this blog were manyfold:

I have a new role at my job, which meant quite a change and distraction from things that happen here
I was busy writing articles, reviewing articles and books, working on talks on conferences (see my - ummm - last post - and even that post is soooo mid 2010 that it does not reflect where have really been. Excuses, excuses - bla bla bla and so on.
I was not satisfied with the format of this blog and am looking for a new template (might even switch to WordPress). Just look at this small writing - disgusting. I still like the picture and stuff, though.

But guess what, I am in a fresh mode now and have collected a couple of topics I want to write about in the next weeks:

My conference year (as a visitor)
My year as a speaker
My reading year (fiction and non-fiction)
My learning year
What is my focus for improvement at work
A posting on 'The 4 hour body' by Tim Ferris and my application of it
My summary of my kindle experiences and what I want to make of it
On paranoia driven development
What do I see in Lean: A summary
Things I don't understand, like: making simple things really complicated (or the other way around, or: Behavioral patterns in the agile coaching community
My new model of queue management on several layers - duuuh!

Well, even thinking of it is lots of fun for me ;)

See you soon, right here.

Appeareances

2010-06-22T23:41:00.000+02:00

Just a quick update on my next talks:

1) Seacon 2010, HH, June 28

Pecha Kucha "The Why and How of Kanban"

2) it-agile, Munich, July 2, Opening Unconference
Pecha Kucha "Unsere reise ins agile Land"

3) Lean, Agile & Scrum, Zurich, September 7
"Enterprise Kanban at mobile.de", Session 45 minutes, together w/ Stefan Roock
I am quite proud on this one: Second time I'm talking in the context of the Poppendieck's, Henrik Knieberg is there and it's a very small and very high quality conference.

4) Lean & Kanban 2010, Antwerp, September 23 - 24

"Enterprise Kanban at mobile.de"

I am - again - very proud to be part of this, have a look at the program: David Anderson (unfortunately in parallel to me, Al Shalloway, John Seddon, again the Poppendiecks, Karl Scotland etc - blush!)

Additionally, I am currently submitting talks for:
LESS 2010, October 17-20, Helsinki, Finland
XP-Days Germany 2010 (one on my own, one with Roman Pichler, one with Bernd Schiffer)
OOP 2011 (as above)

Lean Pasta Manufacturing - at Famiglia Martelli in Lari (Toscana)

2010-05-26T22:58:00.002+02:00

This time I want to talk a little about pasta. And how to produce pasta in a lean way. But in a very personal, traditional and - yes - strange way too.

Actually about one month ago, we wanted to have a family vacation on Sardinia. But Eyjafjallajökull , that in the beginning seemed to be a bad joke we wouldn't have to fear, after some time became a real threat and finally the killer to that plan. So instead we improvised for Tuscany. Out of several coincidences we ended up in the small and beautiful village of Lari.

Größere Kartenansicht

In Lari, we lived at a beautiful agriculture that I can only recommend: Il Frutetto, a quiet, peaceful place where Fabio and Tatiana produce exquisite olive oil and some wine. They can not sell too much of it to each family though, as they have only little capacities which need to last for the full year. We are sad already that we do not have too much of the wine left. Olive oil will last for another 6 months, but then what ...?

Anyway, the Frutetto brought me closer to the very traditional craftsmanship of the whole of Tuscany. You do not see a lot of supermarkets there and although it is obviously getting harder to withstand the market pressure of large chains and brands, the Tuscany has impressively held up small stores, small agricultures etc. It is a total different quality of living: You know where the meet, the cheese, the fruits come from - if you want to. And you can taste that!

Soon we were invited to visit the pasta manufactory of the Martelli family in Lari. And now I am getting closer to the point: Following the Tuscany tradition, this family has business objectives that completely differ from anything I have seen and experienced in any of the companies I have yet worked: This business does not want to grow. Rather than that, they want to stand out for all times as the best pasta makers delivering the highest quality ready made pasta available. They don't even want to get that much more efficient until now, as the whole staff consists of family members. (Who knows, maybe one day they get tired of doing that and they will have external staff and everything changes. But to this day, the business feeds the two families of the brothers Martelli).

This leads to interesting effects, as at all the places I have seen lean efforts, it was about savings and lead time optimizations etc. So lean was completely driven by getting faster and quicker and lowering inventory as a proxy for savings by still having quality in place.

The (not so) secret behind the Martelli pasta (and the business model) is that the pasta is produced very slowly on a ca. 50 years old machine and then veery slowly dried at a certain temperature (it is terribly hot in there). So with your whole product drying for 50 hours come to me and talk about reducing WiP!

Another secret ingredient is that the pasta is relatively rough, thus better taking up any sauce that comes with it - this is a feature that is especially liked by the Maitre's of the world as it helps amplify any subtle touch of your sauce.

The Martelli's only sell their pasta in 1 kg packets rather than in 500gr. I forgot the number, but it goes along the line of: What the Martelli's produce in one day, Barilla produces in 5 minutes (whatever).

I guarantee to you that there is no obvious optimization that came to my mind when I looked at the production place. Any further optimization would have compromized the quality and thus the business concept of the Martelli's. Any stupid excel geek would tell them: Let the machines run faster, only dry your pasta for 20 hours and is still good enough. But no, the Martelli's don't buy that. They rather keep their process and win one pasta "championship" after the other and are one of the most sought after pastas of the world.

I hope this will go on for a long time. Why this so interesting to me is because the business goals are so different. And this leads to an example which makes Don Reinertsen's approach to PD much clearer to me, again: There are no rules and no lean rules. There are several dimensions to look at your problem and domain and then come up with the suitable solution rather than a recipe: Large WiP must not be bad or waste - here it even is your secret ingredient for quality.

But again: Don't use this exception as an excuse for your "unnecessary" WiP! This is different to most environments but again: It explains that you have to take a closer look beyond the "common" rules - they might not always fit you.

I can only recommend to have a look at Don Reinertsen's (minboggling!) talk on some common fallacies which goes by the great title of "The easy road to FLOW goes through a town called LEAN".

Have fun!

P.S.: Oh, I forgot to mention why the business model works: The price of the pasta has increased from 0,80 EUR to 3,30 EUR in about 10 years. And that's if you buy in Lari. if you buy anywhere else, the pasta is sold at prices up to more than 10,00 EUR. The quality does pay off - if you do not plan to grow!

Roman Pichler's new book on agile Product Management

2010-04-17T23:14:00.001+02:00

Roman Pichler published a small but brilliant practical book focusing on agile Product Management with Scrum. Of course, it is focusing on the Product Owner's tasks. This is a welcome counter weight to the predominant developer and Scrum Master focused literature out there on the Scrum market.

Instead of reviewing it and repeating myself here, I simply link to the amazon product pages including my reviews in German and English.

There are lots of books out there where the author just offers a looong list of options, still leaving a confused reader. Not so with this book.

It really is a small, focused and focused book worth every cent. There is another good book out there on product management, which I find to be too general. If you are living in an agile environment, this is your choice!

Apples Constraint Based Product Politics leads to money going to small guys

2010-04-16T22:33:00.007+02:00

Actually, I can not understand the whirl around Apples current product politics. Edit: In fact, the way it turns out right now, I think it's more stupidly following the techie vs. business blueprint of "I wanna play" vs. "I wanna make money" (where in this case the latter can be seen as "I wanna define my product strategy based on a unique usability concept (which some may like but others not) but which is my USP and I'm gonna defend that USP"). Interesting enough most ramblings I see from the tech community are not concerned at all with that USP (which belongs to Apple btw) but with their very own personal freedom of choice of their beloved tools. There are even completely ridiculous comparisons on that, e.g have a look at the following blog ran with a certain twitter fame, calles "Steve Jobs has just gone mad" (but respect due for the great title of the posting):

"Developers are not free to use any tools to help them. If there is some tool that converts some Pascal or, Ruby, or Java into Objective-C it is out of bounds, because then the code is not "originally" written in C. This is akin to telling people what kind of desk people sit at when they write software for the iPhone. Or perhaps what kind of music they listen to. Or what kind of clothes they should be wearing. This is *INSANE*."

Well, there's many things to say about this humble passage. First of all, let's say Apple will really be so strict and enforce this rule (they will sure do that against the flash write once run everywhere thing). What's wrong with that? You don't like it - you don't develop for their platform but for - let's say - Android, because that's just so open as you like it to be, except there's no serious working way do develop a cool application besides Java. But ok, that's not a lock on paper :-) If you think Android is much more open than that, just look at what developer.android.com has to say. It's all about java. No complaint to be heard.

Then again, Apple chooses to define a platform supported by them to support their own product with their very own USP which is so unique that is alone ensures them their margins. So, to me it makes sense that they cover and protect the business and the (tremendous) investments they made on the platform to be sure that the platform just stays what it is. High quality, high usability, unique etc. And of course they are doing everything that is undermining the uniqueness of that platform, e.g. the Adobe write once run everywhere attitude which is, of course, out of a completely different business model the complete opposite of what Apple wants on their platform.

But the most hilarious part is when this all is compared to telling a developer on which desk to sit (heh?), what music to hear (OMG), or what to wear? My goodness, Apple being strict in defining it's product platform is like telling me what music to hear? This is so far off, that this comparison alone could be disqualifying everything else. (Even if I like Tim O'Reilly's idea and open letter that Apple should come back to the former mode of open communication and involvement in the community.

But the main point: Why should anyone be in a position to tell Apple what is best for their product?
At least, there are some sportsman out there. I really liked this posting regarding hacking the devices!
To me it seems, Apple is applying constraints to realize the following properties for applications on it's mobile devices:

Great Usability
Same Usability patterns across all applications
A certain quality
Performance

So, the overarching goal is to achieve a unified, seemless and good usability and performance across all possible applications on their platform.

You may share those objectives or not. But if you share them you have to be honest in admitting that this is the major selling point for these devices for the masses. (Thats why my wife likes those devices, that's why I even dare to think of my mother using an iPad). More than that, this product philosophy (again: like it or not) leads to certain people buying other Apple products after getting hooked on an iPhone. Like lots of people bought MacBooks after having the first real good mp3-player experience in their life with any product from the iPod family.

It's easy to see that such a well defined and user centered product philosophy pays of well for apple. And it doesn't because they want to do evil. It does because people are happy with the devices they buy. Which should be one major target for any product company. Are you happy with your Dell? You may not kill yourself over it, but: Are you happy? I myself die a little death each and every day I have to open my Dell which is provided by my employer!

I can very well understand why Apple is banning Flash from the iPhone. If you don't understand, visit me and listen to the fan of my 3 1/2 yr. old MacBook whenever I open a site with flash on any modern browser. It's killing me. It's killing me for each small little animation where I think - good god, why did they need to use flash for that little silly thing. Is it appropriate to shoot with flash when all you want is some glue to quickly hack some nifty little gadgets together? For simply showing a video? Edit: So - yes - basically one has to say that Adobe screwed itself.

I can also understand that Apple is limiting the way how applications are developed for these platforms with their limitations, because they worked hard on constraining the developer tools to be able to develop something with high quality for the platform. And this is actually the art that was performed in developing the mobile platforms of Apple - to create so much power on these little devices by bringing up so many possibilities but also lots of perfect little constraints so that the developer can not kill the good experience on that platform.

So, what Adobe and other platforms are planning with their write once run everywhere philosophy is quite the contrary: No matter what your device looks like and what constraints i has - just develop one application. Why should Apple, given their product philosophy, be so stupid and allow such a thing? (Especially in the case of Adobe which couldn't have cared less in the last ten years to support apples wishes and bug and performance reports).

And don't forget - everybody can go and grab a phone nearly as or even more powerful like the google Nexus One, which is more open (although some doubt that) but not as nice in it's UI and not as aligned across the offered applications. And yes, you can change the UI whatever way you like.

What I want to say is: If you love the Apples mobile platforms work, you need to understand that they work this way because Apple protects exactly this platform in this way. If you don't like it - buy another product. Which is completely fine. But you will not get the experience of the iPhone on such a small, weak mobile device by being open. (I tried it - i installed so many free programs on my jailbroken iPhone I got sick of them. They destroy the fun of the iPhone.)

And remember: You develop any way you want on the powerful Notebook and desktop platforms of Apple.

What's more and what seems a little forgotten is that I do not see any mobile platform out there with such a lot of programs. I simply do not know of any platform out there with such variety and diversity in depth as well as in width. Whenever I was looking for an application for a certain purpose I found it. Mostly I had the coice of several free apps vs. some offered for purchase (mostly even the free ones winning). So, in effect the iPad and the iPhone are not closed regarding purpose of the applications but the way they are developed. As John Gruber put it: Every halfway gifted 13 year old can get his app on the iPhone. In fact the much debated effective distribution channel over the iTunes AppStore has led to a very strange effect that effectively those who are making real money with iPhone apps are only very few large corporations but mostly individual developers and very small companies. Think of Tweetdeck, Things, etc. And even if the app bears the name of a big company, the market is so young that have not insourced that skillset yet. If you look closely, the so called closed system has led to individuals making the dollars rather than enterprises. Actually, I like that.

Edit: What I would really like apple to do is open the AppStore to all the crap that is supposed to be running on the device. Just open the gates. Let any mediocre flash implementation get on the iPhone on any OS update (but just for me: I want to be able to opt in first, 'cause I won't). And then activate flash and look on the responsiveness of your phone and on the battery. Yes, that's what's gonna happen ... it will be unusable (remember the processor is weak, the battery small etc.) So, if you think about that before, why not simply remove that trash from the iPone in the first place? (Like Apple did.)

Edit: Stanislav Datskovskiy published a briliant blog post from a quite different angle, hinting on the non-apples letting this happen out of sheer dumbness. Nice excerpt: "... For the Apple-imitators to turn into genuine “Apples” would be as fantastic and unlikely as it would be for a slime mold to spontaneously become a true multicellular animal, equipped with a central nervous system. It is also unclear that, from their own perspective, they should want to grow brains – for a creature with that kind of centralized point of failure is decidedly no longer immortal ... " Haha.

Who is a member of Toyota Cult

2010-03-22T23:54:00.021+01:00

@andybrandt just published a post on "What’s wrong with Toyota fascination". As he states that his article is inspired by the wonderful Winter Agile Tunnig micro conference (by the way an incredibly brilliant idea and organization form) which took place last Saturday in beautiful Kraków, Poland and given that and the fact that I was the only person mentioning Toyota (once) and manufacturing (several times) in my talk I would like to comment on that post.

His basic statements are that there are

i) a bunch of lean guys out there - in another blog post and on twitter referred to as "“fad boys” of the Internet Web 2.0 community" - are real fan boys of Toyota and by liking Toyota so much they had the stupid idea of unreflectedly and simply copy 1:1 the Toyota Production System ("mimic Toyota’s assembly line") and were indeed so short sighted as to not realize at all that cars manufacturing is something completely different than software development. (Variability, creativity, etc.)

ii) Toyota is actually one of the lamest car producers out there without any sense of innovation and merely coming up w/ boring small and family cars

So, let us have a look at our feet to explain the "mimicing" part of his post. The thing with feet is: They are useful. And guess what - they have not been invented for human beings n the first place. They have been invented for insects, small animals, never walking around on two feet, no balancing involved etc. So, the original intention was, yes, transport of living beings, but far from what we are doing with them now.

It is clear to everybody that his feet, my feet everybody's (Spiderman being an exception?) feet are a lot different from insects feet (they don't stick, they have individual toes, etc). And that's because evolution (how creationists explain that, I don't know) changed feet by external pressure to what makes them useful tools for us, walking upright, successfully doing crazy things like high jump, long jump, 100m sprints in crazy speed, cycling, climbing, marathon, ultra marathon, Phelps' swimming style, you name it. In myself had some success in one or the other of the mentioned activities and I would never deny the success of the concept of feet.

So, all the smart people (and it's not me to blame for that) who looked at Toyota Production System at the time looked indeed at a manufacturing production system. And with good reason. Like the compiler theory guys at their time looked into industrialization of our "science" and trying to bring something like engineering practices into CS for the first time, these guys looked at a mature industry and especially into a production process that did nothing else than revolutionize cars manufacturing across the world (successfully).

And of course these "fad boys" (what respect towards colleagues lies in these words) did NOT just copy the TPS because, guess what, you simply can not do it. Instead what they did was look into some principles behind it AND some production theory AND the management theory of Demming (I guess another poor old "fad boy") and thought hard about what that means to software development in a transfer process. (When I was in school the principle of transferring an idea or concept from one domain to another made the difference between good and very good. And it didn't mean "copy" or "mimic").

They basically came up with some lean principles such as "build quality in", "Stop the line", "reduce work in progress", "apply the pull principle" etc. Some guy went as far as studying Queuing theory and ToC really seriously and applying the drum-buffer-rope to SE (which was the start of Kanban).

In the case of Kanban, David Anderson did all this with good reason: To establish a sustainable pace in the organizations in a transparent manner to withhold the vicious "can't you simply do more in less time" cycle. And he and his adopters and even a fad boy like me, did this with good success. Believe it or not.

Anyone having doubts or really going for the ugly picture of us guys having installed a software engineering assembly line, Toyota style, I invite to visit me at work and search for that. You will not meet the ugly face of 1920 taylorist assembly lines ...

And yes, we are not at the end of lean or Kanban, it is evolving and in fact that is what I like about it - we are getting smarter every year. Actually that's what I like about Kanban, that I can now start to look at SE or product development from totally different angles, I simply didn't see when I only worked in Scrum. (E.g. to completely refrain from projects and start a transformation towards features along a strategy rather than managing a timeline for a standing organization like that I'm working in is quite appealing to me: Does anyone here really care about the timeline of small features that amazon is pushing out all he time? I can easily plan marketing and communication along those features without an exact timeline but along the strategy and features derived.)

So, what we are looking at is a nice example of evolution through external pressure of ideas and principles behind production (insects) to SE (men). How could anybody have a different impression on that.

Oh, and even the manufacturing guys are going for variability. One large part of the success of Toyota (or Zara or ...) is indeed to work on minimizing set up times to be able to create very different pieces of product on the very same production line, because that simply is the art of lean to produce just-in-time what was just ordered. (The Zara case is btw indeed an incredible story of urning a hole business concept upside down by simply treating clothes and design just as perishable food in a lean way). And I'm telling you - these guys are really clever in parts, they have shown some adaptability and of course, they come up with different solutions in a different context by applying similar principles to their domain just as we come to different solutions in our domain.

The power of Kanban is actually that it enables us to learn from those principles by playing around with them. And you only can do that because there is a relatively fine grained model of your process.

As a final word on the potential power of Kanban, let's see what happens when I synchronize the Input and output cadence of a Kanban system at three weeks. (Yes, and I apply my WiP Limits and establish my pull principle). What I modeled in this special case is the good old Scrum, but already a very good one with WiP limits in place and so on. The missing roles I can define very well as additional rules. But in an Kanban environment what would happen to that special case of a 3-week-sprint Scum model is: that it won't last long, because given the special context it would plain simply modeled to something fitting the environment better. And the changes would be suggested by the actual developers who designed that Kanban system anyway. So, it's about empowerment of the people doing the actual work (another principle from lean manufacturing).

As to the second point, Toyota being quite uninspired and boring. It's all a matter of taste and indeed I never bought a Toyota, but I sure give them credit and respect for: the Prius, as the first mass market hybrid car, developed in at the time revolutionary 18 months; changing the luxury car market by introducing the Lexus; being the first company to introduce the SUV concept to the mass market instead of the military etc.; and again, changing and revolutionizing the way cars are manufactured today across the world.

I think the observations in "What’s wrong with Toyota fascination" are too simple. Additionally it can not be ignored that what Andy calls "mimicking" has been done with success in lots of companies. (Feet are good, if you like it or not.) But for sure, no one needs to like the ideas behind and I like the discussion about that. About the "fads" everybody needs to decide for himself.

Disclaimer: I do use Scrum in my company and we do so with success and love it!

Pat Metheny's Orchestrion

2010-03-16T14:07:00.050+01:00

So, I'm starting off this blog on agile topics with a little musical diversion. Starting off, you might start the short video for an impression of what I am talking about.

You could always say that what Jazz musicians are learning and doing, namely improvising across unheard of scales and quirky chords and scale and chord progressions, is learning to be agile. But to hell with that metaphor. (But then again - the more I think of the metaphor, the more I am tempted to stick to it: Again it's not magic to improvise, but lots of practice and skills (craftsmanship) and lots of just doing things until you're good at it - with enormous patience).

In the case of Pat Metheny, we are talking about one of the absolute masters of Jazz Improvisation, not only on the guitar(s) but in the general field of modern jazz since the mid 70s. He is perfect in playing classic jazz, post bop improvisation and all the classic stuff but more than that, he brought new styles into jazz and helped keeping jazz alive for some decades now by doing where jazz is best at: Taking up new flavors and styles and ever more broaden the meaning of jazz. Pat Metheny is one of the guys who kept Jazz from starting to smell.

Now, Pat Metheny's style is not embraced by everybody and some critics might even say that some of his stuff is a bit too "kitschig" for them, but as for me: I don't care. I remember certain holiday trips with nothing else on the walkman or car CD player than Pat's newest album and I am afraid (for my family too) that I spent hours and hours singing along to those, sometimes loud and in the wrong key, of course.

Especially live, Pat's performance is the closest experience to a perfect live rendition I have ever seen. Being a close friend to 'First Take' Jaco Pastorius (RIP) in his youth, he sure has some entertainer blood in his veins, too.

The last and coming weeks, Pat is touring the world with his Orchestrion project. Beginning last autumn he started to write a little about it, to promote his new album and tour. From what he wrote, I guess (and he says), no one could really know what he's up to. What he did was to build a whole homunculus-like machine, which should be the band for his new project. The Orchestrion machine would be controlled by him and his guitar as well as some sequencers (I guess ableton live from Berlin). For a song or two, this sounds like a funny idea, but as a fully worthwhile musical project of one of the geniuses of our time - who knows?

I wouldn't write about it if it were a failure, so yes: It is an incredible achievement what Pat did here. In February the album was released and just sounds like any other Pat Metheny album, closer to his band than his trio or solo recordings.

On that album some more things were revealed on how he did that. The Orchestrion was build by some professional instrument builders - mainly at LEMUR - concentrating on acoustic instrument being controlled by MIDI. That explains for the natural, unsynthetic sound of the orchestrion: We are dealing with actual, acoustic instruments, like drums, bass, the Yamaha Disklavier, some bells, glass bottles as whistles amongst others.

Throughout the article there are some pictures to only get a small glimpse of the orchestrion.

So, let me switch to the live performance now. I watched the concert at the Philharmonie Berlin on 2 March 2010.

The concert started of like any other Pat solo concert, him grabbing one of his gorgeous Linda Manzer guitars, this time a baritone guitar w/ nylon strings. For everybody never having been to a Pat concert this already is a moment of magic (for me too, after all these concerts I've seen). When he sits down and starts plucking the strings, with the first tone of the guitar, lots of Pat's qualities come to a full shine: The simple sound of the nylon string guitar is so much larger than life, you really wonder how he does it. And, no, it's not easy. Lots of things play together here. Yes, he has a very unique styla and technique of playing the guitar (picking the nylon string w/ a plectrum for instance. But adding to that, how he mics and amplifies and processes the guitar is so perfect and a science in itself. So, why doesn't he just do it any other way? Because he is a perfect musician and entertainer. he doesn't only want to play on the highest level, but he wants every note he's playing to be an experience for the listener (fur us: the client!). So he does not rest until the guitar sounds better than any guitar could ever sound live and direct in my own 4 walls. He did this all the time, when he reinvented the electric guitar sound on stage by putting up two amps, combined with heavy effects for just getting a special spacial distribution in the concert room, when he started playing the guitar synth and did not take up to playing all the voices available but just came up with that one perfect, trumpet like sound on the pre-Midi Roland guitar synth that he still uses until today, etc.

I am really sorry and embarrassed to sound like a fan boy, but the guy simply is that good.
So, next he played a solo impro on the steel string guitar and then on his famous Pikasso guitar, all made by Linda Manzer.

All the time you saw some strange instruments standing around on stage. But you couldn't really make out what it is. What we didn't know yet: The main part of the Orchstrion was covered by a red cloth. So what we saw was not the complete Orchestrion.

As a next song, he started an improvisation again, kinda bluesy and I really didn't like it at first because it really sounded like a cliche and I thought about the worse times of Louis Armstrong. But then, something funny happened. Small parts of the Orchestrion started moving and adding to the music. Namely Mr. Fingers, a small finger cymbal and a high hat just giving a nice small beat for Pat to groove to.

Each beat of any instrument was accompanied by a little LED flash coming up, so that you couldn't only hear what's happening, but also see. This would become an important feature of the Orchestrion later on.

A soon as the instruments started playing a funny thing happened with the audience: Everybody started smiling mildly as this was such a sensation. And here the magic starts. This is actually easy. Instead of triggering a beat box or a synth by midi, all that happened was that little instruments driven by little solenoids.

Now imagine what happened one or two songs later when the red cloth was taken off and the whole Orchestrion was revealed, something like that was to be seen on stage now:

Without further ado, Pat now started to pay his Orchestrion suite as can be heard on his new CD. And this moment was simply incredible, Everybody, EVERYBODY in the audience now had just a big kid smile in his face and simply no one could believe what's going on. As you can hear on the CD the suite starts with quite a modern and complex piece of fusion jazz with all kinds of complex harmony behind it. It's not just just that it sounded like on CD, no it sounded really alive and not at all as replayed by a sequencer with some guy doing live guitar to it. This was MUSIC. Live music.

So again, Pat is not stupid and a perfect entertainer and a perfect musician at the same time. So every piece of what he did here was so elaborate. The blinking LEDs added to that impression as much as the concept that he could influence everything any instrument played by controlling all the instruments loops with the midi signals from his guitar. Every instrument just looked terrific. The stage is dominated by a large drum rack in the background where the individual instruments are not simply put together but separated on the whole wall. On the rights side you see a bass being plucked, the notes of the bass triggering a nice lamp changing her colors according to the pitch of the bass note (Another optical effect which makes it easier to resolve what's going on. And that's another thing that's going on - it all looks so incredible that your mind always tries to solve just how it works. A little explanation at the end).

The front of the stage is dominated by two cupboards full of tuned glass bottles which are used as kind of organ pipes. (Incredible sound). You have some strane 8 pieces of guitar strings being manipulated by other selenoid triggered rotors, sounding a bit like an 8 voice choir. A whole lot of little percussion gimmicks around the stage cater for lts of diversion, fun and diversity in the sound. And so on and so on.

As music is hard to describe I'll add some links to the videos available and maybe, you can try to grasp a little of the magic and how it works.

The end of the show consisted of some tunes where Pat started with a blank piece of paper - nothing at all - and built complex songs by playing in all the instruments' loops liva and alone on stage. So yes, he could play al those songs on stage on his own, given time to enter the loops, if he wanted (Which he doesn't, as some of the musical pieces are just too complex to do that in short time).

What became clear to me was that his guitar can trigger any of the instruments. Given the nature of the instruments there are two ways to trigger them. Instruments like guitar and piano can only be triggered one at a time as the whole fretboard of the guitar is used to play whatever needs to be played.
For the drums, he uses certain fretboard positions (or pitches or notes) for a single instrument of the drum set, say the low E string is the bass drum, the G in the middle of the guitar a snare drum etc. So, he can play quite complex rhythms at once on his guitar.

He does that by entering loop after loop and instrument after instrument for a certain harmonic turnaround. That's impressive enough and: try this at home just for guitar. You must be incredibly precise for such a load of instruments to still sound good and on point.

But then, another thing seems to happen, which is that when dynamics change, it seems to me that parts of the patterns of the loops are changing too. So when the whole piece gets louder, obviously there are some changes in what the loops play back. And this is really what makes the trick of this being a musical experience rather than a bunch well played loops.

The crazy thing about this is that Pat does this again so perfectly and with such imagination that you can not believe that he able to still have the overview of this complex musical monster on stage and at the same time control it. And again, this all looks so flaw- and effortless that I am still wondering today, how many time of his life Pat devoted to the concept of the Orchestrion and then to practicing with it to come to that level of perfection.

So, coming back to the unloved metaphor of jazz and agile, this performance just again makes clear to me how hard it is and how much effort and devotion and phantasy and love and care you have to put into something like this to make things seem effortless in all that diversity. Part of this is to really understand the whole idea and history of Orchestrions from the last century all through the Yamaha Disklavier and making best of what's available today. And only all of this together leads to the effect of grown up people sitting in the Philharmonie with a constant smile on their face - just likes kids - during the whole performance.

I don't get it at all if anything experienced comes across in this article, so tell me about it.

Thanks for your time,

Markus

All pictures copyright Pat Metheny and Lemur