Bosch Connected World Hackathon

There is no shortage of things to do in Berlin, and if you’re curious about high-tech, there are lots of opportunities to dive in and get connected to the high-tech culture. In my almost two years here I’ve had a great time spending my spare time attending events at startup-accelerators and co-working spaces, meetups, conferences and even hackathons.

When I saw the notice for a hackathon sponsored by Bosch I wasn’t sure what to think. To me, Bosch means spark plugs and power tools. Turns out there is a lot more to Bosch than that, and they are developing a big presence in the IoT space. So I decided I had to have a look at the Bosch Connected World conference in Berlin.  It was all about connected devices, and I would have loved to listen to the talks in the conference.

But there were also 4 separate hackathon tracks and I was curious about those. I signed up for the Connected Car hackathon. I’ve been learning Android mobile app development on my spare time lately so it was an opportunity for me to see how my skills stacked up.

IMG_2504 B.jpg

The way these things work is that the general topic of the hackathon is introduced, then anyone can pitch ideas to the audience. After the pitches are made, people circulate around the room and form teams to work on each idea. Then the teams design and code up their idea, working until the final presentation on the afternoon of the next day.

I decided to pitch a simple idea and was a bit surprised and very relieved that 4 university students from Stuttgart joined in and we formed a team. Since it was a Connected Car hackathon, we decided to integrate an Android app with the Bosch MySpin environment so that it would run on the car’s entertainment system.idea-1.png

The Bosch guys even brought a Jaguar with the MySpin system installed. We somehow missed to install our app in the car, but ran it on a prototype unit instead.


After two days of hacking we were able to retrieve GPS coordinates from one phone, and display google maps driving directions on another MySpin-connected mobile phone. Very cool! I was somewhat relieved that I was able to contribute my part and feel that I’m keeping pace with the industry.

The event was really well organized at Cafe Moskau (pictured in the tweet above) which turned out to be a great venue. Cafe Moskau was built in 1964 and is situated in the former East Berlin. The architecture of the building is fantastic, such a departure from the stern soviet-era concrete buildings lining the streets around it. Great lunch and dinner foods and refreshments served by an attentive staff – this was definitely not your average hackathon. There must have been more than 200 people hacking away in several different rooms. There were different hackathons for Connected Car, Industrie 4.0 (a big topic in Germany, I think it’s termed Industrial IoT elsewhere), power tools and cloud-connected sensors. Check out the twitter hashtag #BCX16 to see more on the event, or have a look at this video.

At the end of the two days we enjoyed a nice wrap-up dinner courtesy of Bosch where hackers and conference attendees mingled. I must say they did a good job putting this whole event on. And a big thanks to the hackathon organizers – they clearly put a lot of effort into it, and it all went off without a glitch.


Paint The Room!

I occasionally deliver internal Agile training classes, and one of the things I have struggled with is to explain the concept of Agile estimation. I’ve been searching for a good game to get the point across, but could never find anything that worked well. Some times I could work off a real backlog of items and features supplied by the class participants, but more often than not it was almost impossible to find a set of features that everyone in the room could relate to. So some people would get the point, others would not.

One day in such a training session I had a room full of people from various backgrounds and was silently stressing over how to best cover Agile estimation. Then, somehow, two previously unacquainted neurons connected for the first time and in a flash I had the solution.

This game will teach Relative Estimation, Planning Poker, Story Points, Backlog Refinement, Story Splitting and Story Elaboration all in one short 20-minute session. All you need is some Planning Poker cards. It’s so simple you just have to try it to see how effective it is.

If you’re not familiar with how to use Planning Poker, then this page from Mike Cohn (@mikewcohn) is a good start.

I call it the “Paint the Room” game.

Paint The Room

The game is played in whatever room you are delivering the training in. Chances are your particular room has at least four walls, a floor and a ceiling. Good – that’s all you need! Now here is the setup:

Working as a team we have been given the job of painting the room which we are currently in. The customer’s requirement is (intentionally) vaguely stated as “please paint the room” and we have drawn up an initial project backlog which looks like this:

  • paint the north wall
  • paint the south wall
  • paint the east wall
  • paint the west wall
  • paint the ceiling
  • paint the floor

You might of course give each wall a descriptive name such as “window wall”, “entry door wall” etc. instead of north/south/east/west. Many people can’t tell North from Up.

In the game you will represent the Customer/Product Owner when the team has questions about the job. The team has to come up with an estimate to paint the room. Distribute Planning Poker cards to everyone. Keep the number of participants to the size of a scrum team. Everyone else can just watch and still get the full benefit.

The nice thing about the game is that everyone can relate to the task of painting a wall, even if they have never touched a paintbrush. Furthermore, everyone’s assumptions about what is involved in doing a good paint job varies widely among white-collar knowledge workers.

Establish the “Anchor Feature”

In relative estimation it is useful to have an anchor feature that we can associate a known story point quantity with. Other features will be estimated relative to the anchor feature.

Pick one wall that looks like it is medium effort relative to all the others and tell the team that “this wall is a 5-story point wall”. That is your “anchor feature”. All other backlog items will be estimated relative to that wall. This establishes what a 5-story-point wall looks like.

Most engineers initially have a hard time separating the idea of Story Points from person-days when we talk about software features, but have no trouble at all accepting the abstract notion of a unit-less “5 Story Point wall”.

Now we’re ready to estimate.

Estimate one wall

Pick one wall that is a little less complicated than the anchor wall and ask the team to estimate how many story points that wall is relative to the anchor wall. Use the Planning Poker method to get input from each team member.

Simply ask “So assuming our anchor wall is 5 Story Points of effort, how many Story Points of effort is this wall?”

Make sure everyone provides an estimate, and that everyone flips their cards all at once. One of the key benefits of Panning Poker is to protect against the influence of expert estimates which may or may not be reflective of what the team can actually do. It’s essentially a variation of wide-band delphi estimation. And indeed you might get a wide range of responses in the range of 1 story points to 8 or even 20.

This is where the fun starts.

Talk about the high and low estimates. The value of Planning Poker is in the conversation which brings out unspoken assumptions, and you will really see that in this exercise. As the high/low estimators explain their reasoning for their estimates, you will hear things like

  • I assumed that we had to put masking tape on the trim and around the edges of the windows
  • I assumed that we had to remove all the covers on the electrical outlets
  • I assumed that we have to cover the floor
  • I assumed that the prep work was done (or was not done) ahead of time

In other words, different people make different assumptions about what the job really entails when the job is imprecisely specified, so they come up with different story point estimates. That is exactly what happens when software engineers with different skills and specializations give estimates on vague requirements. Many times you will find that there is an experienced handyman in the team, and he will be on one end of the scale relative to the others. That is ok, it’s usually that way with software experts too.

The other thing that usually happens is that the team starts spurring each other on with more clarifying questions:

  • are we using rollers or brushes?
  • do we assume that all preparation/making take is done before the job?
  • do we all work on one wall at a time, or several in parallel?
  • do we have to purchase supplies first?
  • Should we move the furniture out of the room?

and so on.

The conversation will flow back and forth a little as the team considers the now-spoken assumptions behind the high and low estimates. As the facilitator you just have to sit back and listen as the team starts peeling the layers off the onion. If the team gets stuck, you might volunteer some of the questions above, but never solutions. Your job is to make sure that the team talks about their assumptions and agree on the how between themselves.

It’s a game, so don’t waste the opportunity to have some fun with it. If you get questions from the team, don’t be shy to throw in new requirements or constraints to make the job harder. “No you can’t take the windows out of the window frames before painting” or “yes of course you must remove the windows from the window frames before painting” and “well yes, of course I want the floor painted in a black-and-white chequer-pattern. What did you think?” are good conversation-starters. The team may groan all they want, but every small requirement change makes the game a little more like reality.

As the team discusses their individual assumptions they will probably identify some new tasks. Most teams end up adding new items to the backlog:

  • remove electrical outlet covers
  • put masking tape around the windows
  • put electrical covers back on
  • Purchase supplies
  • clean up

After a few back-and-forth comments you might get to a point where the team has a new common enhanced understanding:

  • yes we will remove the electrical outlet covers
  • we will use rollers for painting large areas and special brushes around the windows
  • we will not cover the floor (it will be painted last)
  • etc.

Not too different from talking about how a given feature works, what the hidden requirements are an so on. The actual agreements and assumptions are not important, as long as the team ends up with a better shared understanding of the task. The new knowledge is an illustration of Story Elaboration, and you might even want to take the opportunity to specify some Acceptance Criteria, such as “no paint smudges” and “even color application” (might require two coats).

Do another round of Planning Poker estimation. The second round of estimation should have a tighter range since we have now had some conversations and clarification about the “requirements”.

Discuss the high/low estimates again and do one more round of estimations if needed. If you picked a good “anchor wall” and picked a slightly less complicated wall to estimate, then the Story Point estimates should settle around 3 or 5 Story Points. Good enough, let’s move on.

Estimate the ceiling

Now that the team has seen the Anchor Wall and produced a converged estimate for a simple wall, you ask the team to place a story point estimate on painting the ceiling. Again, it must be relative to the Anchor Wall of 5 Story Points.

Discuss the high and low estimates. Some people will estimate the ceiling as being easy, others will see added complexity in simply reaching high, using ladders, how to deal with light fixtures etc. In any case you will find more un-spoken assumptions that only come to light when you talk about the estimates.

This is also a good opportunity to point out that the customer requirement initially was just to “paint the room”. Nobody gave specific direction on what to do about things like the light fixtures. It’s a perfect way to illustrate that it’s critical to go back to your customer and clarify what the expectation is. I usually respond to the team, when they ask, that I like the way the light fixtures look so I don’t want paint all over them. Therefore I want the light fixtures removed and then put back in place after the ceiling has been painted. You can then show that it’s ok to split the story into three: (1) remove fixtures, (2) paint the ceiling and (3) reinstall fixtures. That is a lot more work than the initial expectation (do we need an electrician?), but hey that’s R&D. Sometimes we uncover unexpected complexity. Update the project backlog accordingly.

Check the backlog

As you have gone through the estimating process a couple of times you will see that the backlog has grown with new entries, and some stories have been split into smaller stories. That illustrates the mechanics of backlog refinement. In every case the refinement was a direct result of discussing with the customer and/or uncovering hidden assumptions.

Wrap it up

I never go through the whole backlog, but stop the game after estimating two or three backlog items. By then we have covered Relative Estimation, Story Points, Story Elaboration, Story Splitting, Planning Poker and Backlog Refinement. Not bad for 20 minutes of poker!

I’ve run the exercise a few times now, and every time the team has come out with a better understanding of how to use Agile estimation techniques in their projects. Hopefully it works for you too.

If it does, let me know!

If it’s a Pipeline, it’s leaking

Many times we view the Product Development System as a Pipeline where we pour effort and energy in, and out comes a product sometime later. You’ve probably used this analogy before, talking about “products in the pipeline” or “the R&D pipeline”.


Seems pretty intuitive, and I use that analogy too. Except I recently thought perhaps the analogy isn’t quite right. If you’re working in a Waterfall or phase-gate process, it’s not a single pipeline. It’s a series of smaller pipe lengths which are joined together by hand-offs:


The trouble with hand-offs is that they generate waste.Throughout the journey there can be more energy lost in hand-offs than actually make it out of the pipeline. In every joint, effort and energy leaks out.


I find this analogy is a little more fitting, and although it’s a simple visual it helps make the point about hand-offs at the simplest possible level. The discussion usually turns to “what are the leaks and how we stop them” and there is your entry to discuss Lean and Waste.

What do you think?


“Wind extinguishes a candle and energizes fire. Likewise with randomness, uncertainty, chaos: you want to use them, not hide from them. You want to be the fire and wish for the wind.” – Nicholas Nassim Taleb

Agile and Antifragile… one word you know, and another perhaps you don’t.

Taleb BooksAntifragile. The word is so new it doesn’t appear in any dictionary… yet. It was introduced to the world by one of my all-time favorite authors, Nassim Nicholas Taleb, in his 2012 book “Antifragile – Things that gain from disorder”.

One might imagine that the list of “things that gain from disorder” could be written on a single post-it note with room to spare. Short in length and narrow in scope indeed, but the more you dig the more applications you see. There are numerous parallels to product development here, waiting to be picked.

When someone offers you a way to benefit from disorder instead of being harmed by it, wouldn’t you be curious? Sign me up! Should be enough material for a few blog posts. Not sure how many – all I know is that this is part 1.

Disorder Defined

Things that gain from disorder… intriguing. Better clarify what is meant by disorder then. Disorder can be many things, so Taleb provides a rough summary of the “extended disorder family”:

(i) uncertainty, (ii) variability, (iii) imperfect, incomplete knowledge, (iv) chance, (v) chaos, (vi) volatility, (vii) disorder, (viii) entropy, (ix) time, (x) the unknown, (xi) randomness, (xii) turmoil, (xiii) stressor, (xiv) error, (xv) dispersion of outcomes, (xvi) unknowledge.

As a shorthand, I’ll refer to the family as either disorder or randomness, depending on context or the whim of the moment.

To a traditional Project Manager, these family members are all harbingers of bad news, like an unwelcome visit from the Mafia. To the Developer, they are facts of life. The “project management” activity aims to wrestle the disorder family to the ground and squeeze out as much predictability, control and stability as possible.

That, as Taleb likes to say, is a “sucker game”.

It’s a sucker game because the problem is unsolvable. We’ll never eliminate or control randomness. If we could, randomness wouldn’t be coming at us at inconvenient times from unexpected directions. The winning game is not to tame randomness (we can’t), but to manage our exposure to the effects of disorder by assuming change and volatility is ever-present. Here you can already see the first signs of parallels to Agile: we embrace change and new emerging information. We adapt to a changing environment. Variability and uncertainty are not to be resisted, but used.

We need a way, then, to help us get a handle on this disorder thing. You can’t exploit what you can’t see. And so we introduce the Triad.

Fragile – Robust – Antifragile

Everything in the world can be classified into The Triad: Fragile, Robust or Antifragile according to how they respond to disorder.

Something that breaks when subjected to disorder is Fragile. For example, a porcelain teacup which is dropped onto the tile floor has nothing to gain and probably will break.

The Robust neither breaks nor gains from disorder. Robust or resilient things retain their shape after being exposed to shocks. That is good, as they don’t get any worse – but they don’t improve either.

We typically think of the opposite of Fragile as robust or resilient, but as Taleb is the first to articulate, the opposite of breaking under stress is not to stay the same but to get better. What kinds of things could possibly benefit from randomness and disorder? Well, a lot of things, and Taleb gave us the word Antifragile to give the concept a name. Things that are antifragile respond positively to disorder and randomness. They grow and get stronger.

OK, we are engineers with logical minds trained in linear thought. This can be hard to wrap your mind around, so let’s look at some examples.

The easiest approach is to look at the opposite end of the spectrum first. Fragility is easily detected. Anything that looks like a line of dominoes that have to fall in place perfectly is fragile because any kind of variation or instability (one domino out of order is enough) will upset the plan.

For example, if you are traveling by air and your itinerary depends on making 3 different connections with no allowance for delay, then your plan is fragile to delays. The more such dependencies you have, the more fragile your trip will be.

Think about all the fun project Gantt-charts with carefully laid-out dependencies you have been exposed to in your lifetime. None of them (none!) executed according to plan. The bigger your project is, the more moving parts you have. The more moving parts, the more fragile you become because you have more opportunity for things to wrong. Size makes you fragile (this will be a separate blog post for sure). You can hide fragility behind buffers, but it doesn’t reduce the fragility of your reality. It just lets you pretend it doesn’t exist and delivers a bigger surprise when things go really wrong. This we mistake for confidence.

Robustness in R&D typically come in the form of buffers or backup-plans. Both are expensive because in both cases we trade stability for schedule time or resources. Since most R&D projects are people-intensive (easily 80% of project costs come from salaries), this is the most expensive way to purchase perceived predictability.

Mother Nature is Antifragile. Here is  system that depends on random events. Evolution can not do its work in a perfectly stable system where there is no variation. If there is no genetic variation, then there is also no way to improve the species. Genetic variation (mutation – say sharper teeth for a carnivore) is necessary for the improvement of species. Evolution is fueled by randomness. It’s a volume business, for sure, and most variations don’t result in meaningful improvements. But once in a while a new ability surfaces which ends up dominating. Here we see at least two members of the disorder family at play: variability and time.


There is a lot more in common between Agile and Antifragile than contracting the two words into AntifrAgile – although the word combination is cute and rather serendipitous. And maybe prophetic.

Yes, Agile methods embrace change as a fact of life but the dive into AntifrAgile goes much deeper than that. It boils down to a different way of looking at risk – and therefore also acting differently on a daily basis.  We stop trying to predict or eliminate random events, and instead put ourselves in a position where surprise is not an unwelcome guest but rather the wind that energizes the fire.

As we shall see later, like Mother Nature we can exploit disorder in product development rather than being harmed by it. Taleb outlines several strategies for how to do that in other parts of life, and I’ll try to relate them to the Lean/Agile mindset. As we draw the parallels, you might get a better appreciation into how randomness is also Agile’s friend. And – perhaps in the process we’ll tread into uncharted Agile waters. Who knows.


Ok that is almost enough for this first post on Agile and Antifragile. Maybe you can start to see the trajectory of how Agile and Antifragile intersect. They are overlapping in so many places, sharing much of the same DNA.

So what’s the big deal? Understanding how Antifragility can work to your advantage will unlock more options and maybe even push our application of Agile methods forward in new directions. I am a big believer in adopting and adapting ideas from other areas, and if we can overcome our domain dependence then we have one more source of inspiration to draw on which will help us move away from the Fragile world of Gantt-charts and into the more dynamic world of Agile.

And hey, it doesn’t hurt to get independent confirmation from other parts of life about the sensibility of Agile, and to see that Agile’s way of dealing with uncertainty has merit outside of Software Development.

Curiosity didn’t kill the cat…

..perhaps something else did. I don’t know – I’m a dog person.

I am starting to see a common thread, kind of a tapestry of supporting ingredients that either enables or blocks change. It’s not just with Lean/Agile, but any change effort. Many times the implementation of new ideas don’t get off the ground because they never had chance to take root in the first place. Why?

(can you mix conflicting aviation and farming metaphors? I think I just did)

I think there are at least three fundamental ingredients we overlook when we prepare for change: Imagination, Curiosity and Introspection. These are not Values, but Traits. Values can be taught and even enforced; Traits are cultivated.

(yes, the farming metaphor works better)


If we want to effect change, we first have to be able to imagine a world where (1) what we currently do is not good enough any more, and (2) there is a better way.

If you can’t leap that far, then you really don’t have anywhere to go to. It’s that simple. Many folks I have met and worked with over the years have done well and succeeded in their careers doing things a certain way so why change now? It’s hard to imagine that what has been successful in the past isn’t the best way to do business anymore (I’m working the best way I know!).  But change is constant -whether you accept that premise or not- and it is a harsh reality that what made us successful yesterday may be a liability tomorrow.

We have to imagine the new behaviors we want. What do small batches look like in your environment? What would it mean to rely on self-directed work teams? What implications are there from facing risk head-on (as opposed to the traditional avoidance maneuvers)? How would Planning change with a Lean/Agile mindset?

Purpose and motivation come from the question “Why?”. Tools, practices and processes answer the question “How?”. Imagination springs from the “What if?” domain.

Lean ideas are so far away from current popular wisdom, even counter-intuitive, so making the paradigm shift requires a good dose of imagination. In some people it’s innate, in others it needs to be cultivated.

Imagination plays a huge role in overcoming one of our biggest challenges: our difficulty in translating good ideas from one domain to the next. As Nicholas Nassim Taleb remarks, “Humans somehow fail to recognize situations outside the contexts in which they usually learn about them.” Taleb labels this phenomenon domain-dependence.

That is, we easily recognize good ideas in one domain (say Manufacturing) but fail to apply the same ideas in another domain (say Software development). Even years after Mary and Tom Poppendieck provided compelling insights on how to map the principles behind Lean Manufacturing to Software Development we have trouble accepting that the same laws of nature which influence manufacturing apply in knowledge work.

To see something in one place and imagine how it could apply somewhere else is the essence of innovation. You can’t do it without imagination and unfortunately we don’t pay much attention to that particular trait. Chances are you didn’t ask your most recent hire anything to gauge their imagination. You probably focused on skills and experience, right? If you have Imagination and Curiosity -the subject of the next section- you will acquire the right skills and experience. Imagination and Curiosity are the more important success factors.

More on domain-dependence in a later blog post perhaps – this is one of our biggest problems w.r.t. process innovation and progress.


Very well, we want to improve and achieve better results but without a certain level of curiosity your options are limited to variations on familiar themes. You can streamline this or optimize that without stepping too far way from the playbook or without asking too many fundamental questions. Curiosity doesn’t do well within your comfort zone – it needs to break out. New solutions develop when we are curious about how well we actually perform today, and curious about how things work in other places. Curiosity about how things work. Curiosity about why we do things the way we do. Curiosity about why (the ultimate “5-Why”-type-of-why) we are feeling the pain we do in our projects.

The best people I have worked with have all been very curious. Never satisfied that they know everything, but always having this internal unsettling feeling that there is something else that needs to be discovered or questioned, always wondering what’s there at the next level or behind that next door. For Curious People, the questions are more important and exciting than the answers, and every answer triggers ten new questions.

If you are curious, you don’t need management to tell you to use the 5-Why method. You already ask more questions than can be answered. Keep going, and use your Imagination to come up with new ways of working based on the answers you find.


This is perhaps the most difficult one. Introspection is the precursor to Reflection. Reflection fuels Humility. Humility is a necessary condition for un-learning, especially as we acquire more experience, success and seniority.

Yes, un-learning. Lean/Agile is a paradigm shift. To make a paradigm shift we usually have to un-learn something we know to be obvious and true to make room for the new paradigm. For example, we have to un-learn the “obvious” application of mass-production scale economy (and thereby the division of labor) to knowledge work and the usefulness of Pert-charts.

Once you are armed with curiosity and imagination, the easy part is to look at the system as a whole and identify where the waste is in the value stream etc. It moves the fault-assignment away from the individual and onto the system, which I totally agree with. But it could also (incorrectly) be a way to move responsibility away from oneself and onto the system.

It can be quite difficult to look inward for an honest assessment. But inwards we must look, because if you are leading change, then your own convictions and sense for what is the right thing to do must also evolve along the way. That is after all the Agile way. Inspecting and adapting at the leadership level requires introspection. If you don’t live along those principles, your team won’t either.

Introspection then enables us to stay open enough to consider new knowledge, to be flexible enough to adapt to change, and to be humble enough to continuously re-orient your own world view. Remember, finding the “one way” to “do Agile” (ouch! you don’t “do Agile”) and then pushing it through is just another way of commanding & controlling.

Bottom Line

So… the trinity of Imagination, Curiosity and Introspection. These values can’t be commanded from the ivory tower, but they can be cultivated at all levels. It’s an indirect approach. You reap what you sow… sometime later. I am fortunate to have been surrounded by people through my career which display these traits. As I realize now the importance of them, it only underscores how subtle these influences are. Or maybe it shows that I am a slow learner. In any case, hopefully this post triggered some thoughts on your end.

It’s a long-term and indirect investment with no clearly visible cause-effect relationship, but if you cultivate these traits then you are moving int he right direction – no matter where you end up.