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.

Appeareances

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)