The Democracy of Kanban - Pecha Kucha from LKCE 2011

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

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 :)

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

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:

1. Wip Limits
2. Guarantee bandwidth for intangibles to address sustainability of your business
3. Tool Support
4. 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

... 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)

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

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

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'

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: 

1. 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. 
2. 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.
3. 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

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:

1. Only those tickets that are delivered to the referee are counted.
2. 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

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

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?

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.