A Story Mapping Workshop

Last Monday, I facilitated a workshop on Story Mapping at Agile Monday Nuremberg. I got some positive feedback on that workshop and thus, I will share the format and materials here for anybody interested.

Materials

• Slides for introduction (you can find my slides here)
• Flip chart paper or some other kind of wallpaper for every group
• 2-3 fine liner for every group
• Sticky notes

Execution

Keep the presentation short

1. Introduce Story Mapping in 5-10 minutes using just one or two slides.
2. Let people split into groups of at most five people per group and brainstorm what app they want to "build". (5 min)
3. Next, the groups will write the key activities for their app. (10 min)
4. After activities are written, every group thinks about the tasks needed for the activities. (10 min)
5. The next minutes will be used, to plan for a first release of the app. (5 min)
6. Let every group present their result, i.e. the app and the first planned release to the whole group. (3 min / group)

Duration: The whole exercise will take approximately 90 minutes, depending on the number of groups.

Three things, you should bear in mind as facilitator:

Participants working on tasks for their app

• Try to keep the introduction as short as possible. People will learn how to create the maps by doing it and speaking about the result to others.
• Set strict timeboxes, to help people focus on the current task.
• Encourage people, to try to explain their idea using their map inside their group, before they present it to the whole group. If they can explain it easily, this is a good indicator for a good Story Map.

Bottom Line

Some results of our Story Mapping workshop

The take home message of this workshop will be: Story Maps are a really simple tool and make it much easier to communicate to various kinds of stakeholders about your application and key goals.

Feel free to use this format and material for your workshops on Story Mapping. I would be grateful, if you leave comments or any other feedback and share your improvements on this.

Story Mapping on One Page

Impact Mapping on One Page

A Walk Along the Rim

Grand Canyon in all its beauty

- or: How Does it Feel to be Agile?

In a recent blog post I asked myself, how one could possibly detect, wether a company is agile or not. I want to take this question a little further: What does it mean at all for a company to be agile? How would this feel like?

I am sure, there is no one answer to this question, but I would like to present you a metaphor, that is often in my head while talking and discussing about "agile companies".

It is the metaphor of the Grand Canyon. Everybody has heard of the Grand Canyon. Plenty of people are dreaming of visiting the Canyon but many of them have only seen it on pictures.

One of the most awesome things you can do there is to take a walk along the South Rim (especially at sundown). There are essentially two tracks, you can take for that. There is a very solidly built street about 10 meters from the rim and there is a small hiking trail directly along the rim (which you can see on the second picture).

Hiking trail along the South Rim

The difference between both ways is on the one hand the view you might expect, which is really good from the street, but mind-blowing from the hiking path. On the other hand the latter is somewhat thrilling to walk (you will not find to many people there :)) because it is really close to the abyss. The street on the contrary is very safe (I am tempted to write SAFe ;) - but I will not).

Why do I like this metaphor?

Agility is - at least in my eyes - closely related to flexibility. Being able to adapt to new and unforeseeable situations quickly. Speaking about organizations, high flexibility implies less structures and processes. Less structures and processes again mean a lower perceived degree of security. And that is the hiking trail. You must find a good balance there.

Everybody has the free choice to select the right path for himself, to see the Canyon. But those, who always want to stay safe (at lease perceived) will probably not come to see the whole beauty. While those taking the hiking path might be far out of their comfort zone. But after all they will be rewarded by one of the greatest views of their lifetime.

Public Secrets of Mount Change

Change is hard!

To change something does always mean, to risk something - to loose something. In exchange we always have the chance and hope to win something. Ideally, we loose something bad and win something good. But we do almost never know...

What we know is, that it is deeply human trying to adhere to the current state.We call that e.g.

• Loss aversion
• Risk aversion
• Ambigutiy aversion
• ...

So: Change is hard!

Does this mean that you should never change? No! But if you think you have to face a big change initiative, you should be able to really answer two questions for yourself:

1. Is there a desire, necessity or urgency perceptible that will make the effort of climbing Mount Change seem smaller than bearing the consequences of standing still?
2. Do you have a clear vision, mission or goal that will ensure that people roll down Mount Change together and in the right direction?

Only if you have clear and simply understandable answers to these two questions, you should start your efforts. For that you will not forever start and never reach the top of Mount Change. Nor will you roll down the hill and fall of some cliff because some people took the wrong direction.

Don't misunderstand me. You are not done with answering these two questions. But it is an important point to start. And you are ready to take up your hiking stick, then. Good reads on the change topic are:

• "The Corporate Culture Survival Guide" by Edgar H. Schein
  This book exposes the rich set of experiences of Edgar Schein, who is one of the first, most famous and influencial organizational psychologists.
• "How to Change the World" by Jurgen Appelo
  This book stresses out a view on organizational change that is based on systems- and complexity theory. It is not a complete collection of steps for a succesful transformation, but a brilliant guide to getting the right attitude towards organizational change.

Is This Company Agile?

Recently Boris Gloger tweeted the question:

Why do you work for a non-agile company? (1) › bor!sgloger - http://t.co/4L3LcTNOAa
— Boris Gloger (@borisgloger) October 3, 2013

This made me think: "If I would switch positions to another company - how could I find out, if it is really agile?".

My first approach to answering this question was to answer the following two questions:

• Which interfaces are there between me and this company?
• How can I see, if it is only the interface looking agile or the whole company beeing agile?

This resulted in the following list of companies interfaces:

• Web Page
• Building
• Job Interview
• Friends working there
• Social Media
• Classical Media (e.g. Newspaper)
• Rating Sites (e.g. WorldBlu, Kununu, glassdoor)
• E-Mail
• Phone call
• Job Advertisement
• Products
• Customers

I tried to figure out, how one could possibly learn about the agility of an organization by observing those interfaces. And failed. The only interfaces, that are likely to give some clue about agility are the two "organic" ones where you meet somebody working in this company:

Job Interview

In 2012 I participated in a Stoos Stampede session, where some guys collected a large set of really nice questions for a job interview. Some other guys even ordered them in a nice way. I think this is a good resource to look at before your next job interview.
Anyway - you should take a round trip through the company and have look in the faces of people. Observe their interactions and just listen to what happens, what does not happen and how people behave.

Friends working there

Probably the best source for information about any company is your network. Look out for friends and people you know, working for this company. You should ask them every question, that you are interested in and will very likely get an honest answer.
However: Even friends and relatives have different receptions of reality and different tastes!

What else?

After looking on the other interfaces for several days and trying to figure out, how agile companies differ from non-agile companies, I realized that this is probably a mission impossible: Being agile is a deeply cultural thing (as you can see e.g. here and here) and you will not be able to assess a companies culture by observing artifacts only.

So - what else?

I then remembered a really good book, I read some months ago: "The Corporate Culture Survival Guide" by Edgar H. Schein. Schein proposes a cultural model in this book, which consists of three levels:

• Artifacts: All the things you can see, hear, taste, ... All of the non-organic interfaces mentioned above are artifacts.
• Espoused Values: This are the values, the organization communicates actively. E.g. "customers first" or "employees first".
• Tacit Assumptions: This is the real hot stuff. Tacit assumptions are things everybody in the organization knows implicitly and which determine the factual behaviour of employees. This is the core of the companies culture.

(I already explained this and other culture models in a former blog post)

Schein additionally proposes a workshop format to assess a companies culture. This consists of seven steps where three steps are actually used to investigate the tacit assumptions, i.e. the real culture of a company:

1. Identify and list artifacts: Look at all artifacts, you can observe. To do this for a company, you are not part of, you can use the interface list above and observe, how the company behaves over this interfaces. Do they react fastly on customers questions? How does the building of the organization look like? What about the design and usability of the website?
2. Identify the organizations espoused values: Try to get all statements about companies values, you can get. A good way to do this is the web site, where you might find a blog or other content about companies values. Another way is to search the web for the companies vision and mission. Especially the latter one will probably contain some espoused values.
3. Compare values with artifacts: Write all identified artifacts on the left side of a whiteboard or sheet of paper and all espoused values on the right side. Look out for conflicts between espoused values on the right and artifacts on the left. If you find a conflict, you have likely found something that points to a deeper lying tacit assumption held within this company.

If you have this list of tacit assumptions, you will probably get a good feeling for the agility or non-agility of a company. If you take this list to your job interview at this company and discuss it with your counterpart, you are very likely to get a good sense for the agility of the company you are interested in.

Do you have any other ideas, how one might be able to find out how agile a company is before one joins the company? Please use the comments section and spread your ideas!

Update 1: Further Readings (Blog posts recommended to me after publishing this, etc.)

• "Perspectives on Rightshifting" - Bob Marshall

Trivia from the Scrum Guide

I just re-read the current Scrum Guide and I always wonder how things, that are very clearly expressed in this simple document are still frequently discussed, or not known...

I tweeted some of those trivial items and will bundle them here:

#Trivia from the #Scrum Guide: "For the Product Owner to succeed, the entire organization must respect his or her decisions."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "No one tells the Development Team how to turn Product Backlog into […] potentially releasable functionality."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "The number of items selected from the Product Backlog is solely up to the Development Team."

— Fabian Schiller (@fabianschiller) October 20, 2013

"The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements […]"

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "When a Product Backlog item […] is described as 'Done', everybody must understand what 'Done' means."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "[…] what 'Done' means […] varies significantly per Scrum Team […]"

— Fabian Schiller (@fabianschiller) October 20, 2013

#Scrum Guide: "If there are multiple Scrum Teams working on the system […] development teams must mutually define the definition of 'Done'."

— Fabian Schiller (@fabianschiller) October 20, 2013

Business Value Estimation

This interview is translated from german. You can find the original version on Sven's blog.

Some weeks ago, Sven Schäfer started to estimate business value with his team. They are using the regular planning poker cards to put a value on the story cards indicating how much the customer will profit from this story. I asked Sven to answer me some questions on how this is helpful for them:

You are now estimating business value in your team for some weeks. How did you get to the idea of estimating value in the team?

Sven: Business value - or the answer to why I am doing something - is something that is not discussed very frequently within our team. It is not an essential part of our requirements, too. But deep inside myself I do feel the need to know why I am doing things. I want to do something useful, at last. And I want to know this value is represented adequately somewhere. I do not want to believe only that something is useful, I want to see it somehow. Estimating the value is one option to make this visible for me.

What benefit do you see in estimating business value in your team?

Sven: Most important is the fact, that we are now talking about it frequently. That is, I am talking to other colleagues about what is in for the customer with a certain topic and what the topic contains. I do often not understand, why certain people are doing things, the way they do. I believe, that the discussion helps me to understand that. Speaking about the "why" just helps to understand other people better.

What exactly does "business value" mean to you?

Sven: First of all, I am thinking about money. If I am working for a company, then value always means, that a little more money comes out of an action than you put into it. That is value creation.

What do you do, if your customer does not understand how you estimated the value of a story?

Sven: If the customer tells us, that an estimate is not correct, she will probably have a good reason for that. She will be encouraged to inform us about the reason and give us a better estimate. We will then use this better estimate. Our estimation is only a first shot. If the customer tells us something better or more correct, then we are glad to learn.

Do you observe any positive or negative effects on the team from this value estimation?

Sven: I cannot say this from the perspectives of my team mates. For me personally it is helpful, because I do understand others in the team much better now.

The topic was mentioned positively twice in your teams retrospectives, already. So it seems, you are not the only person, to like this estimation.

Sven: I believe, that it is a big help for our product owner when he tries to prioritize the backlog. I think it is much easier for him, now that he has concrete estimates of the business value.

So the estimation of value seems to work well and to be helpful for your team. What do you think, whould be the next step for your team to advance a little?

Sven: We will definitely have to try to make this estimates more transparent to outsiders. Our customer must realize, that we are doing and working with value estimates and we will have to end up in a discussion with our customer. This will probably be a little bit unconvenient at first, but that is probably necessary to get talking.

Do you see a value for your customer in your team internal value estimation?

Sven: Of course, our costomer has not only one view about the importance and value of specific requirements, too. Every customer team has its own problems and priorities and they somehow have to decide on what is the most important thing for all of them and the whole company. Our value estimation and the discussion that is linked to it, could be a good foundation for the customer to be able to prioritize requirements better.

One last question: What do you think would be a huge step forward for your team?

Sven: I think, it would be exactly this discussion about business value with our customers.

Great! Thank you very much for this interview.

Team Communication

Tally sheets might help your team

There is a simple tool to let your team reflect on their communication. It might help you, if there is somebody on your team who talks very much and some people who remain mostly silent. The tool is: a sheet of paper and a pencil. Just participate on a teams meeting, search a quiet corner and make a tally sheet of who in the team spoke how often. After the meeting is over, offer the team to share your observations and let the team decide, what to make of this observation. Maybe a very healthy discussion will follow...

If there is no discussion coming up, there is eventually no problem with this fact or the team is not ready to tackle this at the moment. You might try it some time later again.

The Agile Coach Journey

Over the course of an agile project, the role of an agile coach changes massively. I tried to draw a little comic on the agile coaches change on the path to agile.

Honestly - I somehow do not like this drawing as much as I liked the "What is Agile" drawing. After all - I am obviously still in heavy practicing mode ;-)

Great Teams!

Last week, I attended the ALE 2013 unconference. This is definitely one of the most awesome conferences I have ever seen. There is lots of energy, ideas and passion around there and it is an extremely inspiring environment.

I used the opportunity of open space to facilitate a session on "Great Teams" there. I will share the result of this session here. The format of the session was very simple. Every attendee got the opportunity to tell the story of a great team he was part of or has seen. After the story was told, I asked something like "If you should pick out one thing, that made this team a great team, what would it be?". Many attendees told great stories and we finally came up with the following list of things, that make teams "great".

Do you have stories to tell? What is the one thing, that makes your team great? Feel free to use the comments section!

I Have a Dream

I have a dream that one day, in our industry where business people are seen as mercenary beasts and product developers as assembly line workers, those business people and product developers will go hand in hand and together deliver the greatest possible value for customers, they can.

I have a dream today!

;-)

Do you have a dream, too?

Lessons from our Lean Startup Experiment

So - last week, two friends and I conducted this four day long lean startup experiment. Which lessons did I take away? The first and foremost lesson is: It's great fun, to work focused and hands on in such a small team on a nice product!

Further lessons were:

• You should formulate your hypotheses clear and write them down on a piece of paper. Do really ask yourself which assertions you want to verify - and if the experiment you are conducting will indeed give you evidence for that.
• Even if you did this, you will be inclined to neglect negative evidence - especially if you are in love with your own product. Your head will always tell you that everything was wrong (data, experiment, people) - but not your idea. This is a real challenge! And it makes the first point even more important.
• An MVP is not necessarily very small. There are some hypotheses, you will have to invest a good amount of work into, to proof or disprove them.
• You should have enough time and reserves to do some pivots. Otherwise your are relatively certain to fail with your first or second wrong hypothesis.

I asked myself after the experiment if we did pivot at all. Since we did not write up our hypothesis formally (we only talked about them), I did not know immediately. But thinking about it, I found that we pivoted quite some times in that four days. On the first day we switched from the idea of building a mobile app to building a website first. There were further pivots - and I think all of them helped us to get a much better understanding of what we should build.

Conclusion: Taking a lean startup approach really forces you to get in touch with real people - potential users. Those people are able to give you extremely valuable feedback in very early stages of product development. It's a great approach for product development - but there is still much more to be learned and done to build great products!

Lean Startup Experiment - Day 4 (and last)

At this moment we decided to finish our lean startup experiment. We were currently coping with technological difficulties with a relatively simple feature. It is now clear, that we will not be able to accomplish everything we wanted to until Friday evening. Thus, we all agreed to stop and use the last day somehow else.

Why did we struggle? A short retrospective revealed the following issues:

• We did by far not do enough marketing - thus we had almost no real customer feedback on our site (there was exactly one person subscribing the service :-(). We did get some feedback indicating, that potential customers did not really get the idea of our page.
• We did not prepare well enough for our experiment. We used a whole lot of technologies, we did not really know. This broke our neck today.
• One week is really short for delivering even a relatively simple project in a serious manner.
• Summertime is a really hard time to stay focused on such a project ;-)

But after all, we all still learned a great deal. Not only technology, but also how to work in short cycles as a small team. Setting small reachable targets every day and having short status syncs worked extremely well for us.

A big thank you to all readers of this blog and all supporters giving us valuable feedback on our little product! We will now go on and enjoy a great free three days before going back to business as usual :-)

Lean Startup Experiment - Day 3

Day 3 of our experiment is over. It was a day full of work and (from our point of view) huge progress on the project. We improved the layout massively and included some hints on the page about our intentions. We got the large image view working and took care of some legal aspects. You are now able to register yourself as a prospect customer by clicking on the login button and sending an email. We solved several infrastructural problems including deploying our app to the Amazon cloud (EC2).
If you would have asked us this morning, if we would be able to accomplish this - nobody of us would have said "yes" probably :-) It was a great day and we learned a great deal of things about all the new frameworks and technology we never used before!

Sven working hard to keep the backlog up-to-date. We are working to fast :-)

We are very proud of our layout. Especially because there are no designers in our team. If you like our design, too - or hate it: Please tell us! We need feedback! Fastly! (You may use the comments section, for example)

The current UI prototype contains some description on what we want to achieve. We love it :-)

Key learnings of Day 3

• Working with lower outside temperatures is MUUUCH better!!!
• JavaScript is shit
• JavaScript is cool
• We did not get any customer feedback today - which we regret. We will have to improve on that massively tomorrow!
• On the other side - we got a lot of things done, which was really great fun!
• IT guys cannot live without becoming sarcastic - even if successful ;-)
• We think the purpose of our project is not clear enough for visitors on the first view. We will have to improve massively on that!
• We are not able to acquire enough prospect customers by doing marketing over Facebook, Google+ and Twitter only. We will have to try out other marketing mechanisms.

Our main goal in the next two days is to come so far as to be able to go outside and sell our idea to passers-by. Functionality of the site should be so far, that those people will immediately see a value for themselves in using our project. Ambitious goal! Let's see...

Lean Startup Experiment - Day 2

The second day of our lean startup experiment is over now. What did we accomplish? What did we learn?

What did we accomplish? 

The first thing we did this morning was to reprioritize our product backlog. We then managed to sketch some (seventeen!) paper prototypes and chose the one we liked best in fifteen minutes. Afterwards we kicked the complete technology stack we wanted to use yesterday and set up a new one. But still we managed to get a first UI prototype online this evening. You can find it here: http://thatsmykid.de/

First UI live prototype of ThatsMyKid

Key learnings:

• The prioritization of a product backlog in a lean startup project is stable for at most half a day...
• Do not start lean startup experiments if it is 35 degrees celsius outside - can be quite demotivating :-(
• The open working environment at Coworking Space Nuremberg is really cool and enjoyable.
• The new technology stack (Meteor, JQuery, JavaScript) is really good for rapid prototyping.
• Having an hourly status (review) meeting before commiting code helped us a lot to stay focused and avoid trouble.
• Technology is waste (it takes a LOT of time - even if you are not an expert with it)
• Driving three different technological approaches to our first prototype was a good idea, since we learned very fastly, which one would fit our project.
• No design is the best design (at least almost none :-)
• If you have your first UI prototype this is REALLY motivating!

This day started out very frustrating but had an amazing turning point when we first saw our UI prototype in the first review working. The deeper we dive into technology and minimal feature set, the more obvious it becomes, how massively complex a simple application must be. We are optimistic to learn a lot during the next three days and are glad that we love our design so much.

Lean Startup Experiment - Day 1

At this moment the first day of our lean startup experiment is at an end. What did we accomplish today? Essentially, we "proved" our hypothesis, that there might be some interest in an application as we imagine it. Additionally we got some valuable feedback for our app based on the paper prototype we constructed in the morning.

Paper prototype of ThatsMyKid

Sven showing our valuable feedback vom passers-by

Key learnings for today:

• The paper prototype massively helped us to show people, what our idea of the app is. The feedback for our prototype was very helpful and good. Having something to present and touch is an invaluable advantage!
• Feedback from potential future customers can be very motivating. Get feedback from customers as fast as possible!
• Establishing a backlog - even for a product you have a relatively clear vision of - is hard. It is hard work to focus on the key features of your product!
• The last step today was setting up the infrastructure to build a first prototype, which was very time consuming. We didn't expect it to be that hard. Even if many Google services (which our technology stack depends heavily upon) are really easy and convenient to use.

Preliminary ThatsMyKid logo

A lot is done. But there is still more to do...

We are now keen to see, what we will be able to deliver after the second day of our little lean startup experiment. Stay in touch!

A Lean Startup Experiment

Today we (Sven Schäfer, Sven Winkler and myself) are starting a lean startup experiment. We all took one week of and want to explore, how to apply lean startup methods and how much of an app we are able to develop in this time. The experiment startet this morning at 9:00 CEST in the coworking space in Nuremberg. It will be finished on Friday evening - no matter what we accomplished in that time. We are now eager to learn :-)

Our first step currently is to formulate and validate our first hypothesis, which is: "In addition to Facebook and Google+, there is still room for an app that allows parents to share and show photos of their children in a clear, easy and secure manner."

We do currently try to validate this hypothesis in two ways:

1. We set up sites on Facebook and Google+ and uploaded photos of a paper prototype of our new app. We liked and postet on this platforms and will observe how many likes and "+1" we will get. If there will be a great number of likes, this is one indicator, that our hypothesis might be right. If nobody likes - we might be wrong with our assumption.
   Help us with feedback and have a look at our social media pages on Google+ and Facebook. 
2. We will soon go outside into the city of Nuremberg and try to show our paper prototype to some passers-by. We will observe their reaction and therefrom derive, whether our hypothesis is right or wrong. This channel has the advantage, that we can ask for additional feedback and maybe adapt the initial idea and to formulate new hypotheses.

First paper prototyp of the ThatsMyKid app.

Retrospectives of all days can be found here:

• Day 1
• Day 2
• Day 3
• Day 4

Scrum as a Diagnostic Tool

Use the Scrum lens for inspection

What is Scrum? If you ask this question, you might hear a rich variety of answers. Reaching from „a method to process tasks“ over „a project management framework“ to „an instrument for organizational change“.

But this is not Scrum. These are different applications of the Scrum framework. Scrum is essentially just a collection of useful and proven to be succesful rules and practices. It is a theoretically close to ideal state for product development.

If you assume the Scrum framework to be a close to ideal state, then you can use it to find problems in different contexts – even without applying  it immediately. Let me give an example: Some years ago I was in trouble with a classically led project. At the same time I learned about the Scrum framework and thought: „How would it be, if we wanted to practice Scrum tomorrow?“. After asking myself this question, several issues why this would not work came to my mind, immediately. E.g. we would find no Product Owner, the customer would never work with us on a daily basis and we could never deliver software every two weeks. Thinking for a while I realized, that these issues where just the problems the project suffered from. Thus, trying to imagine using Scrum in my current situation helped me to consciously realize what the real problems were.

This idea is scalable: If you want to know what the real top five problems of an organization are, just go to a diverse set of people in this organization, explain shortly what Scrum is and ask them if this would work for them. Then carefully listen and note the reasons mentioned for the impossibility of using Scrum. After several interviews try to cluster and prioritize the issues you found and I bet you will have a very close picture of what the central and demanding problems of the respective organization are.

Just try it. This is much cheaper than hiring a consultancy and will – probably – deliver very similar results ;-)

Leadership Dojos

I see – and hear of – many organizations having trouble with leadership. Starting with the question „what is leadership?“ reaching to problems in concrete application of leadership skills in daily business. One urgent question is: „How can we make clear to leaders in our organization, what leadership is and what our organizations expectations to leaders are?“. Seminars and trainings are a frequently chosen approach in trying to sharpen the understanding of leadership in a company. But I have my reasons to doubt this tools are working.

A very pragmatic and effective way to deal with problems of alignment and lack of practice in software development and coaching are coding dojos and coaching dojos. I tried both tools and found them to be very useful in making clear what the expectation of the trainer is and recieving valuable practical lessons. Transfering this concept to the topic of leadership could look as follows:

1. Choose a standard – but not so easy – situation from the field of leadership (e.g. a worker is not motivated, there is a conflict between two co-workers, etc.)
2. Try to model the situation as good as possible and prepare a role play. There are three roles: the „leader“, the „challenger“ and the „observer“. Distribute these roles to at least three people („challenger“ and „observer“ might be taken by more than one person)
3. Take a time frame of approximately 30 minutes and a room where the prepared situation would be likely to happen in reality.
4. The „challenger“ will now try to play his prepared role as good as possible and the „leader“ has to try to „solve“ the given problem. The „observer“ is not allowed to speak and just observers the situation and makes notes for a later discussion.
5. After playing the role play for 30 minutes the game is stopped and the observer tells the leader about his observations. At this point expectations of an organization to their leaders can be made clear in a very practical, effective and sustained way (if the observer knows about these expectations).
6. Restart at step 1 based on the feedback oft the observer.

Did you try something like this before? What are your experiences? Do you have further ideas for concrete situations to role play? Feel free to use the comments section for your feedback!

Build Flexible Organizations!

It is said, that one of the huge challanges of our time is the great volatility of end customer markets. To face this fact, many companies debate, how to cope with this new market reality. Not surprisingly there are thousands of solutions out there, eagerly sold by consultancy companies:

• You need a flexible and highly adaptive IT ecosystem (see SOA)
• You need to be flexible in handling your requirements (see, Agile, Scrum)
• You need flexibility in your high level planning processes (see Beyond Budgeting, Beta-Codex)
• You need flexibility everywhere. Google for "flexible it solutions" and you will find more than 60.000.000 hits...

But having implemented this "solutions", lots of companies find themselves in situations where they are not really satisfied with the flexibility they gained. Why?

It is just not sufficient, to demand all your processes, tools and people to be flexible. After all it is not your processes, tools or people reacting to the market - it is your entire organization as a system, reacting.

Thus, if you want to stay competitive your first priority should probably be to design or redesign your organization in a way that the resulting system is capable to cope with change as a whole. In other words - you should try to build an organization that avoids organizational dept. 

One of the major challanges of our time might therefore be, to build a sustainable organization where management, leadership and structure are much more situational and much less permanent.

Promote Your Teams

Promote your teams!

Last year I wrote a blog post about self-organization. During the last weeks I talked, read and thought a lot about this topic and my (not so groundbreaking) conclusion so far is, that self-organization describes a great variety of possibilities to organize yourself.

An interesting and fundamental model of levels of self-organization can be found in Hackman's book "Leading Teams". He describes four such levels:

1. Manager-led teams (team executes team tasks)
2. Self-managing teams (team monitores and manages work process)
3. Self-designing teams (team designes itself and the organizational context)
4. Self-governing teams (team sets its own overall direction)

Hackman writes, that well functioning teams are mostly on levels 2 and 3. But even on those two levels you can certainly find more distinct levels of self-organization and team responsibility.

After all I read and saw so far, the effectiveness of a team correlates strongly with its ability to self-organize. The more a team is able to work on level 3, the more effective it can be. But sadly not every team is able and/or willing to take the responsiblities necessary to function well on level 3 without damaging its context or parts of the team.

After this being said - this sounds very much like a classical career path to me. Not for individuals, but for whole teams. If your goal is to develop effective teams in your organization and you believe, that a high level of responsibility and self-organization is necessary to become effective as a team - then why don't you make this explicit by having a team career path? This might be one way, to empower your teams step by step. Of course it must be clear which levels exist, and what preconditions and responsibilities are bound to what level. Additionally you will surely need some expert coaching for your teams to guide them on their way up the team career ladder.

Don't get me wrong - I do not say that you should abolish individual career paths. I just suggest to have an additional career path for teams, too. Furthermore the rewards for climbing up this career ladder must not be financial ones, but just giving a team more freedom and rights in its actions if it has proven to be able and willing to take more responsibility.

What do you think about the idea of team careers? Do you have any experiences with concepts like this?

Empower! Your! Teams!

Empower the Team!

I have seen it time and again: Teams that would probably be able to be high performaning, but are not able to live up to their potential. Why? Because they are used, seen and organized as efficient task processing units.

Most teams could deliver a much greater performance and experience, if they would only be given serious challenges and the freedom to act.

Unleash the potential of your teams and

• compose them in a way that they are able to resolve real holistic challenges (you might call it cross-functional)
• let them use their creative potential by not giving them only tasks - but challenges (maybe a Product Owner that writes some demanding and sufficiently unclear User Stories)
• let them really self-organize and find the best local process to resolve those challenges
• let them evolve as a team (and not only a bunch of individuals) - e.g. have carreer paths for teams
• tell them clearly what they are responsible for and what not
• give them some useful coaching (e.g. a ScrumMaster)

You might now say: Hey, that sounds like I should do Scrum with my teams. But the bad news is: Scrum is only a process and might probably help you to identify the problem of an underperforming team. But it will not solve your problems. Besides this, Scrum has the disadvantage to introduce the roles ScrumMaster and Product Owner, which empirically draw to much attention away from the teams.

So - don't wait! Not for Scrum and not for any other useful or useless framework. Start tomorrow and seek ways to EMPOWER YOUR TEAMS!


Disclaimer: I love Scrum! It is the best framework for software development I have seen so far. The roles Product Owner and ScrumMaster are very essential and useful roles and in my opinion absolutely necessary. Nevertheless you should never forget, that the ultimate goal should always be to deliver a great product - which lays in the hands of the team in great parts!

Testivus zum Thema Test Coverage

vor einigen Tagen bin ich auf eine nette Anekdote zum Thema "Code Coverage" von Alberto Savoia gestoßen. Ich finde die Geschichte so gut, dass ich sie gerne ins Deutsche übersetzten möchte:

Testivus zum Thema Test Coverage

Am frühen Morgen fragte ein junger Entwickler den Großmeister:

"Ich würde gerne ein paar Unit-Tests schreiben. Welche Code Coverage sollte ich erreichen?"

Der Großmeister antwortete:

"Mache Dir keine Sorgen über Code Coverage. Schreib einfach ein paar gute Tests."

Der junge Entwickler lächelte, verbeugte sich und ging.

Später am Tag kam ein zweiter Entwickler mit der gleichen Frage.
Der Großmeister zeigte auf einen Topf mit kochendem Wasser und sagte

"Wieviele Reiskörner soll ich in den Topf werfen?"

 Der Entwickler schaute ein wenig verstört drein und antwortete

"Wie soll ich das sagen können? Das hängt doch davon ab, wieviele Personen davon essen sollen, wie hungrig sie sind, was sonst noch an Essen angeboten wird und so weiter."

"Genau."

sagte der Großmeister
Der zweite Entwickler lächelte, verbeugte sich und ging.

Gegen Ende des Tages kam ein dritter Entwickler und fragte die gleiche Frage zum Thema Code Coverage.

"Achtzig Prozent und nicht weniger!" 

Antwortete der Großmeister in hartem Ton und schlug mit seiner Faust auf den Tisch.
Der dritte Entwickler lächelte, verbeugte sich und ging.

Nach dieser letzten Antwort ging ein junger Auszubildender auf den Großmeister zu:

"Großmeister, heute habe ich gehört, dass Sie auf die gleiche Frage zum Thema Code Coverage mit drei verschiedenen Antworten reagiert haben. Warum?"

Der Großmeister stand von seinem Stuhl auf:

"Lass uns einen guten Tee trinken gehen und darüber sprechen."

Nachdem sie ihre Tassen mit heißem grünen Tee gefüllt haben erklärte sich der Großmeister:

"Der erste Entwickler ist noch neu und fängt gerade erst mit dem Testen an. Momentan hat er eine Menge Code und keine Tests. Er hat noch einen langen Weg vor sich; sich zu diesem Zeitpunkt auf Code Coverage zu fokussieren wäre nur deprimierend und recht nutzlos. Er wird weiter kommen, wenn er einfach übt gute Tests zu schreiben und auszuführen. Über Code Coverage kann er sich auch später noch Gedanken machen.

Der zweite Entwickler aber ist schon recht erfahren mit Entwicklung und Testen. Als ich ihn gefragt habe, wieviele Reiskörner ich in den Topf werfen soll habe ich ihm geholfen zu verstehen, dass die Menge von Tests abhängt von der Anzahl und dem Gewicht verschiedener Faktoren. Diese Faktoren kennt er weit besser als ich - es ist immerhin sein Code. 

Es gibt nicht die eine richtige Antwort und er ist clever genug mit dieser Wahrheit umzugehen und damit zu arbeiten."

"Ich verstehe", sagte der junge Auszubildende, "aber wenn es nicht die eine einfache Antwort auf diese Frage gibt, warum haben Sie dann dem dritten Entwickler gesagt: 'Achtzig Prozent und nicht weniger'?" 
Der Großmeister lachte so herzlich und laut, dass sein Bauch - der darauf hindeutete, dass er nicht nur Tee trank - auf und ab wippte.

"Der dritte Entwickler will nur einfache Antworten hören - auch wenn es keine einfachen Antworten gibt ... und am Ende folgt er ihnen dann sowieso nicht."

Der junge Azubi und der grauhaarige Großmeister tranken ihren Tee in nachdenklicher Stille fertig.

Hier noch einmal der Link zum Original-Blog.

The Limited Backlog - Addendum

In an earlier post I argued to limit the size of your product backlog. Some days ago, I met a co-worker who told me that some agile experts told him, that product backlogs always have to be limited in size. Superficially, this looks like the very same statement, I made in this former blog post. You might eventually be surprised to read, that I disagreed with the statement, my co-worker made.

Why? Because it is very important to understand why and when limiting the size of your backlog makes sense! The main argument for limiting the size is to avoid the maintenance costs of many backlog items. Especially, if there is a probability, that they will never be implemented at all or the items are deteriorating fastly (what a waste!).

Now comes the pitfall: If limiting the size of your backlog leads to emerging "backlogs" in other places (e.g. at your customer!) you might eventually even increase the overall costs of maintaining the items, if the maintenance costs at the other spots are even higher than they would be in your backlog. This is definitely not what you wanted to achieve in the first place, when you limited your own backlog.

So if you do indeed limit your backlog (which is still extremely valuable), watch out and have a careful look, if the discarded items do indeed vanish, or are only cultivated elsewhere.