Transparency instead of planned slack


A fellow agile coach pointed out an interesting difference between the planning of traditional project management and agile methods, that I think deserves a blog post on its own: transparency.

When you plan traditionally and draw a Gantt chart, based on activities and allocated resources, you create the critical path – that is, the sequence of activities that must be finished on time in order for the final deadline of the project to be met. Most project managers know that this critical path, given the vague time estimates given and the sometimes poor understanding of the complex tasks at hand, will not hold. To counter this, they do one of two things:

  • They inflate the time estimates by some factor (by 2 or pi or some other arbitrary number)
  • They insert buffers into the critical path, to be used if needed

I can imagine that many project managers, especially for larger projects, do both.

The main issue that I have with this – and I say this not only as an agile coach but also as traditional project manager – is that it is not very transparent. The practice might need to be explained to the project team (”hey, we said it would take 2 days to do task x, why did you write a week?”) and it might be hard to motivate for the customer (”hey, why have you planned two weeks of doing nothing?”). There is also the factor of Parkinson’s law to consider: if you show everybody involved that a specific task will take 4 weeks to complete, it somehow always seem to take no less than 4 weeks.

Now, the precise (albeit faulty) planning of traditional project management does not exist in agile methods. Thankfully. I prefer the transparency of agile methods. We do not claim to know precisely how long something will take; instead we make a promise that we will work with a sustainable pace with the most prioritized features first. We do not plan in advance for one sprint of doing nothing, just in case. It’s done when it’s done. Also, after a few sprints we will be able to tell the customer when most of the things in the backlog – given that it is not re-prioritized too much – will be finished.

So, how come that many customers still request a traditional project management approach, with a fixed date, scope and cost? Sometimes, it is because they have to fulfill legal obligations or their own contracts, but most of the time I think it is that they simply do not know that there is a better, more transparent way. It is up to you, the reader, to enlighten them!


The deceptive role description


The request

In some organizations, it is not uncommon for people to ask for a role description, i.e. some piece of text that describes what they or their colleagues are supposed to be doing. The reason for the request varies, but typically goes in one of four categories:

  • The person asking is unsure of what he/she is supposed to be doing
  • The person asking is building an argument towards a co-worker, that is believed to be doing the wrong things
  • The person asking want it to argue for a raise with his/her boss.
  • The person asking is recruiting for a specific role

The response

If you respond to the request by quickly emailing a document, chances are that you are doing the people involved a disservice. Here’s why: there is nothing wrong with role descriptions, except that they are deceptive. They give the illusion of clarifying mandate, responsibilities and tasks, but in reality no piece of paper will give you anything but perhaps a starting point for a discussion.

In my experience, no two people are alike, no two people will interpret a role the same, no matter if they both follow the same role description to the letter. And rarely, if ever, does a role description cover everything that you want a person to do, and you certainly never want a person to be limited what is in the role description.

(Sometimes, the person asking is just being difficult, because they do not like their new role. In this case, the response ”I’ll get you a role description, but only if you promise to do everything in it” gives interesting results.)

In all categories listed above, what the requester really need is support in their specific situation, not a document that was written by some consultant, years ago, for a different organization, in another context, with a different goal. If you, or somebody else, can give this support, then great. Otherwise, there is a trick outlined in the last paragraph.

The solution

Here’s the point: if you honestly want to know what you are supposed to be doing, ask! Ask your peers in the same role as you, your colleagues, your team members, your boss, your customer. They surely have an idea. Dare to ask for feedback on how you are doing, and have a discussion with people you trust about your priorities. And suddenly – and all without a role description – I’m sure you will find yourself doing things, good things, that will help both you and your organization to new heights.

Waiting for the guy with the keyboard

Have you ever been in a meeting, where most of the people in the room stare at the screen, watching somebody typing stuff into a document or a form? It’s painfully slow, the funny guy in the room makes fun of the typist, some of the attendants starts fiddling with their mobile phones, another starts doodling on a piece of paper. All the energy that was supposed to be in the room is gone, and you start to wonder why you even bother with these meetings – after all, it’s only the guy with the keyboard that is doing any work.

How did you end up in this room? That’s bound to be different for different teams, but typically it has to do with the backlog. You decide, somewhere along the way, that it is too much work to keep both a digital copy and an analogue version of the backlog – and since it seems easier to just use the digital copy, you skip post-its and whiteboards. The result: you end up waiting for the guy with the keyboard.

How do you fix this?

The first step is to realize is that you have a problem. This can sometimes be hard, as people might not see what is going on. If you are the scrum master – and often end up as the guy with the keyboard that the rest of the team is waiting for – then it might be tough to see how the meeting is perceived by the rest of team. After all, for you, the meeting is probably quite stressful, right? But if you see blank stares, people start fiddling with their phones or correcting your spelling mistakes, take a hint!

The second step is to realize what the problem actually is. Surprisingly, many teams do not see this. Instead, they start blaming the process, Scrum or meetings in general. As a scrum master, you might be tempted to give in. You start to get that it might be quite boring to watch somebody type, and you start to excuse some parts of the team that probably will not contribute anyway. Or, you start to have the meetings less frequently.

And suddenly, your decision to save work by using only a digital tool has influenced the heart of your process!

There is a very simple solution. Go back to post-its and whiteboards! By all means, use a digital backlog tool, but be prepared to spend some time to prepare before every meeting (to print index cards or similar, and to bring post-its and pens) and to do some typing after every meeting. But trust me, having an engaged team that collaborates instead of waiting for the guy with the keyboard, is certainly worth it!


During the last year or so, I have been caught up several times in discussion regarding ”agile requirements” or some similar catchy phrase. ”Christoffer”, they say, ”as an agile coach, what is your take on requirements? Should we have them? In what format? Who should write them? Where should we store them? And can we really start developing stuff without having them ready and approved?”

The problem with these questions is that there really is no straight, ”do-it-like-this-and-all-will-be-well” answer.

I’m writing this post in a hope to address these questions, and more.

Requirements are neither the paper nor the ink

Let’s start by clarifying an assumption, that is often not fully understood. A requirement is not a paragraph on a piece of paper in a binder on a dusty old book shelf. Neither is it a user story, entered onto the back of an index card on a Kanban board. Those are not requirements – those are the artifacts of the requirement.

A requirement represents knowledge of a need or want, presumably related – at least on some level – to a system that an agile team is (or will be) working on. You need that knowledge in order to develop something. You cannot develop something without requirements.

How do you extract this knowledge? That depends. Usually talking to the person(s) with the need/want helps. Workshops or surveys might also be viable tools.

Who extracts this knowledge? Someone with the required skill set, obviously – but you already knew that. Does that mean that you need a requirement analyst in your team? No, not necessarily. Ask the team if they are comfortable with doing the requirement analysis themselves. Perhaps they have both the technical skill and the communication skill required.

How do you document this knowledge? Again, that depends – it could be in the form of use cases, user stories, mock-ups, prototypes, or whatever suits that particular form of knowledge. Document only when there is a clear purpose with the resulting artifact. If everyone involves have a sufficient understanding of the requirements, there is typically no need to document anything.

The artifacts are still important

Here is a huge, potential pitfall. Because, typically, we believe that we have sufficient understanding of the requirements, while we actually do not. We believe that we have collected all possible knowledge of the need, while we in fact have not. Or, it could be that the need changed, as they often do.

One purpose of creating requirement artifacts is thus to create a common ground, as a help to capture this knowledge and use it as a basis for discussion. But be aware that the use case or user story or whatever you use will change many times – because that is, after all, one of the purposes.

And, obviously, agile methods to the rescue: create something small, based on a few of the requirements – as far as you understand them at this point in time – and then show the result to the one with the need. This will help everybody’s understanding of the actual need, and lets you adjust the end result as you go along.

A philosophical view

A requirement can be viewed as a part of a perfect – albeit constantly changing – knowledge about a need. The artifact used to capture this knowledge  (be it that dusty old binder or that index card) will therefore always be fundamentally flawed. There is no way that an artifact, however detailed, can capture all that knowledge. So let’s not try.

Instead, embrace the fact that requirements evolve and change. Thus, your requirements – in whatever way you choose to document them – will not be done until the need is gone. Let’s not wait with development until then.

Talk to your customer support

I just finished having one of the worst customer support experiences of my life, it feels like these experience are getting worse and worse across the board. But I have a thought about how they could be a lot better for both the companies and the customers if we just think about it a little different.

The customer support problem

I spent many years working customer support for a lot of different products and companies. And I can say, people who are angry about automated systems and outsourced employees for customer support don’t understand the problem fully.

Customer support is a money loser for any company and the larger the company gets, the bigger a problem it becomes.

Think about it this way: (Not real math)

  • You buy a product for 20$.
  • The companies profit margin on that product is 5$.
  • You have a problem with that product and call customer support to speak to a person.
  • A customer support person costs 10$ an hour.
  • You spend 31 minutes on the phone with the agent.
  • This company has just lost money by having you as a customer.

The company is actually in a very tough spot here and in a lot of ways it’s not their fault.

Are you willing to pay for support? Probably not…
Are you willing to pay more for the product? Probably not…

I am actually not angry at the company for this, I understand the problem and why it’s hard to solve.

How companies respond

Companies have to make money. Period.
You also want your product for as cheap as possible most of the time.
Customer support needs to be made to cost less.

This is why you end up in annoying automated systems, this is why you get outsourced representatives in cheap countries, this is why they try everything they can to make you use the website.

And actually most of the time this is a sensible approach. Customers support is 99.9% repetition (made up number), every customers support job I have ever had consists of solving the same 4-5 issues over and over again. Automated systems and cheap people reading scripts is a fairly effective means of solving this. Most people have a very smooth experience when they have the 99.9% issues. And if they don’t they might also make you go away and deal with it yourself, which is also a way of keeping their costs down.

At the end of the day it comes down to this, a company of any significant size works to make their customer support cheaper, because in order to get you to buy their product in the first place they need to keep the product at a competitive price.

A different approach

But what if we approached this problem slightly differently? What if instead of addressing the symptom, the high cost of support, we addressed the underlying root cause, the issues causing the support requests.

What if had the people who build the product, in software: development teams, spend time with the customer support? Or even spend time doing customer support?

I have worked with teams who took this approach in the past, and I can tell you that we see a very different outcome.

The development teams start understand where the problems in their product are, and they are able to attack them at the root cause. The 4-5 most common problems are the first to go.

  • They are able to identify the ones caused by errors and fix them, these calls stop coming in.
  • Then they learn about the calls that are caused by people not understanding the product, they make changes that make it easier to use, these calls stop coming in.
  • Sometimes they see the issues that are too costly to address the root cause of, but a lot of the time they are able to provide the support some tools to address them faster and easier, these calls now cost less to address.

A different way of looking at the problem.

In the first way the company tries to solve the ”customer support problem” they do make it cheaper, but they do so with a lot of upfront investment and ongoing costs.

They need to build and maintain that automated phone system.
Taking on an outsourced support partner is a huge initial and ongoing cost. They need to compare companies, negotiate terms, sign contracts, train people, pay people, deal with legal requirements of that country, quality control the partner is delivering on it’s obligations, the list goes on and on.

But with the root cause approach, every time they fix a problem they save these costs into the future and often for only the upfront investment.

It also provides a much better experience, which creates happy customers, which makes their brand better, which makes more people buy their products.

At the end of the day the root cause approach is better for everyone.

Not a silver bullet

This won’t fix everything, issues will still be there. Some people would still require support and be a higher cost. But maybe the companies support costs are low enough that they can see this as a cost worth taking? And if not, well, they still have a much better experience for the customers who had the original 4-5 issues.


What is Value?

Understanding Value

We talk a lot about value in the Agile world, but value is hard to define, and a lot of the time I feel organisations misunderstand the value they deliver.

Take one minute and try to answer this question. Write down your answer.
”What is the value your organisation delivers?”

Now, Take one minute and try to answer this question. Write down your answer.
”What is the value your Toyota delivers?”

Did you answer something like a car or other vehicle? If so, consider this, if tomorrow Toyota invented a personal transport system that could safely, cheaply and instantly transport you anywhere, would they lose all of their customers?

Of course not, because that’s a great product, but the main reason they would keep all their customers is because they would still be delivering the same value. The value that Toyota provides is not cars, it is transportation.

If they invented a transporter that could transport groups of 5 or less people and 1 cubic meter of luggage, a distance of 900 km, at a speed of 200 km/h before needing to be refuelled, with an entrainment system,  would they loose all their customers? Again, the answer is no, because they don’t just provide the value of transportation, they provide that value under certain constraints. They don’t cross oceans, they don’t transport huge amounts of cargo. They transport a certain thing, at a certain speed, at a certain cost, in a certain situation.

The car is not the value they provide, it is the mechanism by which they provide it.

But why does any of this matter?

Because getting too locked into the mechanism leaves you vulnerable to disruptive innovation, while at the same time stifling your own innovation. All a competitor needs to do if offer the same value with better constraints to hurt you.

Blockbuster declared bankruptcy in 2010 due to being unable to compete with companies like Netflix and Redbox.

But Blockbuster had every advantage in this fight. They already had access and agreements with the content distributors, they already had a huge and loyal customer base. If they had adapted quickly when they saw this change in the market they likely would have blown theses companies away.

Blockbuster didn’t provide the value of renting movies.

Many people don’t know that Netflix has been around since 1997, they provided DVD and Blu-Ray rentals via traditional post for a very long time. Netflix realised that the value they provided was not that of renting movies. They provided the value of entertainment, and by changing the mechanism and constraints by which that value was delivered they were able to take the world by storm.

Do you think it matters now?

Agile is about being able to adapt, not about being able to deliver features faster. Agile organisations need to focus on the value they deliver, not the mechanism by which they deliver it.