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.