Montag, 22. Dezember 2014

The Salary Dilemma

The last couple of months my colleagues and I have been evaluating different alternatives for „Personalverantwortung“ (I’ve asked several native English speakers and it seems like there is no appropriate translation, so I will use the German term).
We’ve talked about what exactly we mean by referring to Personalverantwortung at Jimdo and we came up with seven different elements. One of these elements is, obviously, remuneration. People want to get salaries, and there needs to be some kind of mechanism in place to decide upon the salary level. The „traditional“ mechanism for doing this is some kind of line manager who does (mostly annual) performance reviews with individual salary negotiations. Perhaps that’s the best (or the least bad) solution in many contexts, but as I mentioned, we wanted to evaluate other options. So what we did was 1) read different articles on this topic (eg [1],[2],[3]), 2) talk to a lot of our teams about this topic. The conversations were very insightful in many different respects. What I found most interesting was a thought that was expressed in almost every conversation. It goes like this:

„The person/group who decides on my salary need to be very close to me, so that they can evaluate the quality of my work. At the same time this person/group cannot be on my team, because my behaviour towards this person/group will be different as soon as he/she sets my salary. Oh wait a minute...“

This is what I call the salary dilemma: Whoever decides on the salary of a person needs to be close and not close to this person at the same time.

A line manager has to deal with exactly this problem: He/she is supposed to evaluate people. In most cases he/she is either very close to the team and therefore might cause disfunctional behavior (eg people not asking for help when their annual review is close) or he/she is far enough from the team to avoid this kind of disfunction. But then the remuneration will most likely become very similar to roulette („Haven’t heard anything bad about you. What about a 3% raise?“) Both options don’t look very promising. I am not saying that it’s impossible to find a good balance, and I have seen very good managers doing a great job in creating a high-trust environment with their teams. But I believe it’s very challenging.
Of course we can replace the line manager with a different person or some kind of committee, eg a peer group. This might be better in some respect, but the dilemma stays in place.

I am aware that there are many very different models for renumeration like self-selected salaries, uniform salaries, salary formulas etc. And we’ve been thinking about ways to avoid or minimize the effects of the salary dilemma. At this point we are close to run a couple of experiments to learn more about not only remuneration, but the whole topic of Personalverantwortung. I might blog about this (and all the other insighst I’ve had so far) later.

But for now I am asking for your input:

How do you deal with the salary dilemma?

Please leave a comment or send me an email to arne[døt]roock[ät]jimdo[døt]com

P.S. I would like to thank all the smart people with whom I’ve had the opportunity to discuss this topic: Not only my great colleagues from Jimdo, but also Russell Healy, Simon Marcus, and Jim Benson. You guys rock!


Montag, 20. Oktober 2014

Lean Kanban Central Europe 2014

Only three weeks to go before the 4th edition of Lean Kanban Central Europe takes place! Although I am not involved in the organization any more, I am still part of the Board (and proud of it). As Pawel mentioned in this blog post, we are constantly experimenting with some elements of the program. This year‘s biggest change will be that we will have dedicated tracks for different topics: Kanban, Leadership, Learning, Management, and Project Management.

I chose to organize the project management track. The reason for this is that I have met many project managers who realize that the traditional way of managing projects is not sufficient any more. With LKCE we want to show them new perspectives on project managements, provide them with new tools to experiment with and create a forum for sharing experiences with their peers.

I will kick the track off with my talk The Beauty of Problems where I will show that problems are so much more than nasty things we need to get rid of. They are great opportunities for learning and improving the system. The talk will be heavily influenced by the work of Russell Ackoff and contain some of my own experiences.
After the Pecha Kuchas (Keynote style as last year), Martin Jensen will argue that Culture is THE Competetive Advantage Martin is a smart guy with a great deal of experience with change in large enterprises like He is also a very entertaining speaker. If you haven‘t done already, you should definitely watch his talk from last year.

Joshua Arnold will continue with his talk Value and Urgency: The Power of Quantifying the Cost of Delay Anyone who has ever heard The Don (Don Reinertsen) talk will know a little bit about the concept of Cost of Delay. Unfortunately, few people have really first-hand experience with it. Joshua is one of them. Check out his great experience report from Maersk Line.
After his fabulous keynote from last year, Troy Magennis agreed to speak again at this year‘s edition. His topic is Risk Management and Forecasting Using Un-reliable Data Troy is the guy who not only understands statistics, but also is very capable to explain it to others and to show them how it can be used in daily work without being a statistician.
Conference days are long and it can be hard to maintain attention. Shorter talks might do the trick at the end of the day, and therefore I decided to close the track with a couple of Lightning Talks (10 minutes each). Tim Lossen will talk about the Failure Culture at Wooga, and my brother Stefan will share his experiences with participatory decision making models.

Pawel, Klaus, and Markus grabbing their well-deserved Whisky ;-)

Looking at the talks I think we‘ve managed to put together a great variety of good speakers and interesting topics. Thanks to the rest of the board: Pawel, Klaus, Wolfgang, Karl and Markus. You guys rock!

See all of you in Hamburg. If you haven‘t done yet, register today:

P.S. In case you wonder about this year‘s keynotes: After trying for the last three years, we finally managed to get Henrik Kniberg as well as Tom and Mary Poppendieck. No further introduction required:-) The third one will be Don Reinertsen who will speak about Robustness this year.

Donnerstag, 22. Mai 2014

Stop bashing managers!

Recently I‘ve heard people say things like: „If we only could get rid of all managers, life would be good.“ Or „A truly agile organization does not have any managers.“ While I agree that many organizations do need a different kind of management, I deeply disagree with the notion of getting rid of all managers. Here’re some reasons why.

It’s insulting
At the Lean Software and Systems Conference 2012 (before being renamed to Lean Kanban North America) I saw a great Lightning Talk which startet with the following, made-up, pie chart (and as you know, I like made-up charts):

What the chart basically says is that in reality we have very much managers, like it or not. And my experience is: Most of the managers are good people. If they do what we consider bad management, it is mostly due to strange policies and bonus systems that were in place and influenced their behavior.
If we say that we need to get rid of management, we will most likely insult all these people – no matter if we intend to do so or not. They will hear things like: „These guys think that I have done a bad job in the last 10 years.“ I don’t thing this is the way to go if we want to change the world of work.

Setting missions and aligning teams
Although I consider myself a pacifist, I am a big fan of the concept of Auftragstaktik and its implications for business. If you haven’t done already, I really recommend reading the book The Art of Action by StephenBungay. You can also find a free interview with him here.
We like autonomous teams that figure out how to accomplish their mission for themselves. They experiment their way forward through unknown territory and they will figure out how to do it. But where do the missions come from? And how do we make sure the missions of our different teams are aligned with each other? Sure, in theory the teams could set their own missions and coordinate them with other teams. My experience just tells me that this is very hard (if not impossible) for teams to do.

Managing interactions  and (re-)designing the system
According to Russell Ackoff, „The performance of a system is never the sum of the performances of its parts. It’s the product of their interactions.“ If we agree with Ackoff’s statement (and I’ve seen a lot of evidence for this at different occasions) then someone has to manage the interactions of our system’s parts. In the Agile world teams are probably the most important parts of an organization. Who is responsible for managing how the teams interact with each other? Again, theoretically it could be the teams themselves. In practice I doubt that this will work very well (and I will argue why in the section about local optimization).
Another aspect that’s relevant when talking about Ackoff and Systems Thinking is the design and re-design of our system. As far as I can tell, Ackoff was not convinced that continuous improvement is always the best solution. My friend Markus Andrezak likes this quote by Ackoff very much: „To be ahead of the competition you need o leapfrog them.“ What is true for product development is also true for our processes. Ackoff’s examples of how to improve organizations contain a lot of major re-designs. Deming argues in a similar way: Because it’s the system that causes the biggest part of the performance (Hi, PawelJ I think Deming talks not only about variability here, but also about performance!), and not the individuals, we need to change the system if we want real improvement. According to Deming, this is exactly what (good) managers are there for.

Recognizing local optimization 
Agile teams are supposed to work on accomplishing their mission with a laser-focus, and thereby with great speed. That’s one of the main reasons why we set them in place. But this focus comes with a price: local optimization. The Don of Lean (Don Reinertsen) argues that we will most likely see local optimization when the benefits and the costs of an action occur at different places in the system (see this great talk by Don for deeper insights). This fits my observations with autonomous teams: They tend to sub-optimize the whole in order to optimize their team’s outcomes. Nothing to complain about here. We cannot expect teams to focus on their missions and take care of the whole company at the same time. And, again, it’s exactly what Systems Thinking tells us (you can probably tell by this post that I’ve been reading a lot of Ackoff’s stuff recently:-): „If you optimize the parts, you will sub-optimize the whole.“ If I get this right, one conclusion of this is that someone needs to have a bird’s eye view on the system to recognize when local optimization is about to happen. Yes, I do think the big picture is important (although it has become a kind of a bad word).

Russell Ackoff - read his books!

Changing the team setup
Teams are capable of doing remarkable things. I’ve seen teams that were considered to be the worst performers in the company improve dramatically and perform really well after some of their boundaries were changed. At the same time it’s true that sometimes teams are highly dysfunctional and that they won’t change without external influence. As a last resort, taking people out of the team, adding new people to an existing team, or even abolishing a team completely can be the right thing to do. Teams have a very hard time doing this without external help. In many cases they will not even realize that there is a dysfunction or, when they do, they won’t talk about it to anyone.

First of all we should not offend all the people with management titles out there.
Further more I’ve argued that we need people who are not part of our autonomous teams. They need a good standing in the organization and mus have a good understanding of our systems. They are responsible for managing the team’s interactions, re-designing the system and observing and acting upon local optimization. And sometimes they need to change the setup of a team. For me, that’s exactly what a good manager does. So let’s stop bashing managers and start working on establishing another understanding of management!

Donnerstag, 2. Januar 2014

Why I work with Jimdo now

Today was my first day with my new employer Jimdo. For the last nine years I worked with it-agile in different positions, the last three years as a coach/consultant and trainer for Kanban. I‘ve learned so much during this time and and got to know so many different companies - small startups and agencies as well as medium sized companies and some large multinational corporations. I still think it-agile is one of the coolest companies on the planet, and I am really grateful to my colleagues, especially Henning and my brother Stefan.  And if you are into Agile and like to coach and train people, I strongly recommend that you consider applying for a job there!

So why did I decide to leave it-agile then? As you can imagine, it was a very tough decision. The main reason is: I am really curious what it feels like to go to the "other side of the fence" and work with a product company long term. For me, one of the biggest upsides of working as a consultant can also be a big downside: You see a lot of different organizations and talk to so many interesting people. At the same time chances are that you leave an organization and start a new engagement when the first steps are taken (and starts becoming really interesting). And even if you are involved for a longer period of time, you will always stay an outsider - you can participate in the successes of your client, but still you are always the external consultant. So I decided that it‘s time for me to move on and start a new career as an embedded person in a product company.

Why Jimdo? I first met the Jimdo guys back in 2010. Since then we always stayed in touch and one day they asked me to do some coaching with them. So they have been my client for the last three years, and many Jimdudes became my friends quite quickly. When I first visited their office, I felt immediately that this company is special, and there were so many situations where this impression was renewed. Here are just a few examples: Having a Feelgood Manager (watch this video about Feelgood Management (German)), an architect (and I am not talking about a software architect here) and a chef working at Jimdo; a napping room and a fancy aquarium room everyone can use when he/she needs to rest; no time tracking; really self-organized and empowered teams etc.

And these are only the obvious, observable things. Even more important is the really amazing company culture! And of course a great product with a great deal of innovations to come in the future! You might have noticed, that I am quite excited about my new employer;-)

What will I do at Jimdo? Here you can see a clipping from my contract of labor.

For those of you who don‘t understand German: It says that I will be employed in my role as "Dr. Rock" from January 2014 on. What does it mean to work as "Dr. Rock?" I don‘t know exactly, and neither do the founders who hired me:-) The important thing for both parties was that we wanted to work with each other and that there was a huge amount of mutual trust. So we decided to sign the contract and figure out later what exactly my tasks would be. Now you might understand why I wrote that Jimdo is special.

And what did I do on my first day? Started my two day internship at the awesome support team. And as expected, I learned really much about our customers!

P.S. If you are interested in Jimdo, check out the blog post I wrote about the Open-Prioritization-Meeting, the support and our trip to Stockholm

Montag, 16. Dezember 2013

Reviewing Lean Kanban Central Europe 2013

Exactly six weeks ago the Conference Lean Kanban Central Europe 2013 took place. After Munich in 2011 and Vienna in 2012, it was Hamburg this time - not only my home town but also one of the best places in the world:-)
My involvement was threefold: As organizer, board member and speaker. Here are my thoughts from these three different perspectives.

The organizer‘s perspective

What we try to do with LKCE is to create a special atmosphere. Therefore the venue is critical for us. We avoid typical conference hotels etc., which makes the organization more challenging and also more expensive, but I am confident that it‘s worth it.
This year we choose the Curio Haus as the venue, and it turned out really well. An old building with great atmosphere, plenty of space for socializing, two prestigious ball rooms and great staff!

In my opinion the only real downside was that the third rooms was too small. I didn‘t see that coming as I thought the attendees would behave differently - one big learning for next year!
Experience has told me that there are two very important things when organizing a conference (besides the venue and the program): Stable Wi-Fi and good coffee supply. Both worked great this time:-)
What I like about old buildings is that they provide great opportunities for extras. This year we used the big cartridges in the hallways for exhibiting 16 great quotes. When David Anderson saw this, he tweeted them one by one with the hash tag #EssenceOfKanban. Jasna Wittmann is the artist who did the great calligraphy!

Another thing we lay emphasis on is to have a great social event on the first evening. This is, again, a costy thing to do, but we see great value in attendees chatting with each other over a beer in an exciting atmosphere. This year we booked the Miniatur Wunderland, which is the world‘s biggest model railway with its 900 trains + 12,000 wagons traveling several hundreds of kilometers is brought to live. Over 200,000 figures in different parts of the world like Scandinavia and the North-East Sea with its 30,000 liters of water, Germany or America.

All in all I am very happy how the organization went and I want to say thank you to my colleagues who organized all this!

The board member‘s perspective

For the third time in a row we had the great board with Markus Andrezak, Pawel Brodzinski, Karl Scotland, Klaus Leopold an me (Hermanni Hyytiälä couldn‘t make it this time). These guys are not only really knowledgeable, but it‘s also a lot of fun to work with them!

The board members get a bottle of the Whisky "Work in Progress", which needs to be limited:-)
We choose to have a mixture between invited sessions and sessions choosen from our open review process. The program worked well for me. What we took away from the feedback was that there is demand for more practical sessions like experience reports and that we need to create even more opportunities for the attendees to get in touch with the speakers and other attendees. We already started a discussion how to do this...
I couldn‘t attend too many sessions, but my personal highlight was Stephen Bungay‘s keynote on The Executive‘s Trinity. Stephen is an expert on military history and strategy and the most eloquent speaker I have ever witnessed. Although I consider myself to be a pacifist, I find the concept of Auftragstaktik etc. really enlightening for business (and I am happy Stephen said in his talk people should do better things than slaughter each other!) I really recommend reading his book The Art of Action. His keynote from lkce13 is not publicly available on video, but if you are interested in leadership and management, you should read this free article.

The second talk I want to point you to is Troy Magennis‘ keynote on cycle time forecasting. Especially if you are working in a big project environment, predictability is important for you and you are not satisfied with your estimates, you should definitely check out his presentation! As far as I can tell, his stuff is rock solid and it contains a lot of surprising news. And it increased my interest in statistics:-) You can watch his keynote here.

Almost all presentations, including Pecha Kuchas, Lightning Talks and experience reports from companies like Ericsson, Siemens, Spotify, SAP, Jimdo have been videotaped and are available here.

The speaker‘s perspective

I had a full blown presentation about Kanban, Leadership and Alignment with Jimdo together with my dear fellow Fridtjof Detzner which went quite well.
In addition I gave a Pecha Kucha talk (20 slides on auto pilot, each 20 seconds). The Pecha Kuchas were well-received the last two years, so we decided to do them keynote-style this time (i.e. no parallel sessions). That was quite an amazing feeling to speak in front of 300 people in a big old ballroom! My topic was "Learning from Fake Charts". I wanted to talk about some things that puzzle me regarding things like Toyota, Complexity or Lean Startup, without taking myself too serious. So I came up with 12 fake charts to make my points. The preparation was really fun, and I was quite satisfied with the outcome. But once again I had to learn the hard way how much effort it takes to create and practice a smooth Pecha Kucha! If you have 6 minutes and 40 seconds, you should have a look at the video:

Next year

As I will leave it-agile and start working with Jimdo from January on, it-agile will loose some knowledge and experience about the conference‘s organization (although I am sure that most people over-rate my personal contribution to the success of the event). Therefore decision was made to simplify next year‘s organization and do it in Hamburg again. I think it‘s a good choice! LKCE14 will take place in the Curio Haus again (with a bigger third room, we promise!). The date is already set: Nov 11-12 2014. Check out
I will stay involved in the conference as a member of the board and by sharing ideas and experiences with the it-agile guys.
I am absolutely sure that the best LKCE conference is always the next one, so stay tuned!

P.S. We‘ve invented the KanBanana at the conference:-)

Dienstag, 12. November 2013

Open Prioritization Meeting

When I first visited Jimdo back in 2010, I saw a thing called “Team Wall” - a big wall painted in black, magnetic paint. The idea behind it was simply to use all the creativity of all the great people who work at Jimdo. So everyone who had an idea on how to improve the product, took a piece of paper, wrote down his suggestion, and attached it to the wall. This seemed to work out very well, because not long after starting, the wall was dotted with paper. However, what seemed to be a huge success, turned out to also yield a couple of problems. Many of the ideas hung on the wall for weeks or months - and many of them were never followed up at all. They were good, but did not fit within the business strategy. Or - they were good, but too many other ideas were even better. Nadja, the Flow Manager at Jimdo, often said: “This is not a black wall; It‘s a black hole!” This state created a lot of frustration. They were asked to share their ideas, but most of them were not pursued. And the reasons for this never became clear to them, so the idea wall was abolished again.

The team wall story is another example of a huge problem that occurs over and over again when companies create (or even just allow) big queues. These queues are almost always seen as a “place of unloading”, but without a common understanding of what happens to all the items after they are put in the queue. Furthermore, queues have this really annoying habit of growing and growing. So when items are not being removed, it becomes less and less likely that the things in the queue will ever be completed at all. The bigger the queue, the more effort it takes to manage it. This means that things will be overseen, duplicates sneak in, etc.

Queues lead to overburdening (stress, poor quality, frustration)

Jimdo’s experience with the team wall was one major reason for introducing a concept which they call Open Prioritization Meetings. The first team to start this meeting was the Feature Team, which is called “Captain Feature”. The mission of this team is to maintain and improve the Jimdo CMS, which is pretty much the core of the whole Jimdo application. Besides the end users, the Feature Team has a couple of internal customers: The Shop Team, the Payment Team, the Support Team, the Country Teams, etc. So, the Feature Team can also be seen as a service provider for their colleagues. This again led to a huge queue, although this time, a digital one. Over time the different teams had created tickets for each of their requests, and put them into the issue-tracking system. Very often, the expectation was: “Now that I have placed my order, I just have to wait until it is finished.” But the Feature Team’s capability was less than the overall demand. So the queue (in this case, it was called “Backlog”), grew and grew. And again: dissatisfaction was the result. The Feature Team wanted both to help their colleagues, and to build new features for the end users. This turned out to be impossible, and led to stress and frustration, aware that the queue was constantly growing. The other teams realized that their requests were not being processed, but there was no transparency with the reasons behind this. The Jimdo founders, yet another group of important stakeholders, couldn’t understand why it took so long to build new, strategic features.

Since introducing the Open-Prioritization-Meeting, many of these problems have been solved. This is how it works: On a bi-weekly basis, everyone who has a request for the Feature Team is invited to come to their room and bring his ticket(s). The different stakeholders then pitch their ticket, explaining why they think that this particular ticket has a high business value for the company, and should be done next. After this, the team, together with Fridtjof (one of the founders), decides which tickets they will accept for the next two weeks, and which ones they reject. The principle behind this meeting is: “Never make promises you can’t keep!” A prerequisite for this is that the team must know its capability: How many new tickets can they manage? How big can these tickets be?

The tickets that are not accepted at this time, are returned to the stakeholders immediately. Sometimes people are told: “Please come back with this request in 8 weeks.” And sometimes it is decided that a request won‘t be done at all. Of course it is frustrating for the person whose ticket is rejected - but it‘s better having this initial frustration, than having false hope that cannot be fulfilled. In that case, the frustration would kick in later - and much harder. The Open-Prioritization-Meetings ensure that there is no Backlog of stakeholder requests. In our experience, this is the best kind of expectation management!
And, by the way, the Open-Prioritization-Meeting usually only takes 30-45 minutes.

Although this format is quite new, we’re already seeing a couple of positive effects:
  • The team’s capability is more visible. Now it’s possible to avoid overloading the team - and at the same time, measures are taken to increase the capability.
  • Queues lead to stress. (“Look at all the work we have to finish! We can never do this!”) By abolishing the queue, the stress level decreased.
  • During the meetings, the stakeholders communicate directly, as opposed to the ticket system before. This prevents misunderstandings and builds trust.
  • The different teams have valuable discussions about what their most important request is, because they know that only 1-2 items will be accepted.
  • Everyone who is present at the meeting learns the reasons why certain things are worked on, and others aren‘t. Fridtjof is forced to lay out the company strategy on a regular basis (“Your idea is good. But this year we want to focus on another target group. The reasons for this are X, Y and Z. So we won‘t do your thing this year.”) In this case, Open-Prioritization-Meeting is a means of educating the employees, with respect to understanding and improving the company strategy.
  • In the duration of the meeting, there is an incredible amount of knowledge and experience from different disciplines gathered in this one room. So it‘s possible to find simple and creative solutions immediately: “I have an idea how we could do this with very little effort. Would you be satisfied with an 80% solution?” or “Can you do this by yourself, if we give you access to this system?”

The Feature Team was the first team to experiment with Open-Prioritization-Meetings. The positive outcomes have encouraged others to do a similar thing. Right now, more and more other teams are starting to figure out how this meeting should look in their environment.

This story is part of a free ebook about Jimdo which is called "Doing things differently. Leadership, Management and Alignment with Jimdo." You can download it here.

P.S. Eleven (!) years ago, Ron Jeffries wrote a blog post about what he calls "Petition the king" We did not know about this when we started the Open Prioritization Meeting, but both formats are very similar (unless there is no King at Jimdo:-)  Thanks, Yason Yip for pointing us to this! And as an answer to Ron‘s question in the last paragraph: "No, it‘s not madness!"
Read Ron Jeffries Post

Donnerstag, 24. Oktober 2013

Supporters to the teams!

Yesterday I wrote about customer support and how it is separated from the rest of the organization in many cases. (Read Blog Post).

At Jimdo, one of my clients, we discussed this topic quite often, and Jimdo (once again) is doing things differently when it comes to support work. Here are some details which might be worth sharing.

Quite some time ago, there was a whole lot of support tickets that were directly related to the work of the payment team (or „painment team“ how they used to call it at that time). Everyone who has ever tried to provide credit card payment for his services knows that everything related to payment is a big pain in the a...
So at this point it felt natural to have a support person directly in the team. This was a huge lever! The developers could understand better what problems the customers were facing, and the supporter got a better impression of what was going on in the payment team and shared this knowledge with the other supporters. They were so satisfied that they never thought about releasing the supporter from the team again. The opposite was true - they conducted an experiment: What would happen if we pair-program with the supporter? Sounds silly? Again, it was a big success! They gained an even better understanding of the „other world“ (development and support). And something else happened: Not only were they pair-programming, but also pair-supporting. So the developers were „forced“ to deal with real support tickets and use the same tools the supporters use day by day. Here again the very simple trick paid off: Bring together the people who are facing a problem with those who can solve the problem! It turned out that sometimes a developer could simplify support work with rather little effort (e.g. writing a script to automate things), while the support person did not even know that this was possible! So it was no question that the experiment was successful, and know paring with the supporter has become a kind of standard in this team.
The payment team might be the perfect fit for pulling a support person in. But why shouldn’t the same principle work for other teams as well? So kind of the next logical step was to do this for all other development teams as well.

P.S. When it comes to support, there is another interesting thing going on at Jimdo, which is called Support Alarm Party. But that is worth a future blog post...

P.P.S. Jimdo is one of the the most fascinating company I have ever seen. Fridtjof (one of the founders) and I will present the Jimdo Story at Lean Kanban Central Europe 2013 in Hamburg, Nov 4-5. Also we have written a small online booklet called „Management, Alignment and Leadership at Jimdo“. You can find the German version here. And this is the English version