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.

The Product Vision


Since I wrote the last post – about the ever so common product owner-team gap – I’ve been considering the issue and how to solve it, from what seems to be every angle.

Perhaps the solution is simply, as I stated in the original article, to point out the problem to the involved parties, and make them work on closing the gap by approaching their counterpart. But recently, I’ve come to the conclusion that there might be another problem, just beneath the surface.

When analyzing the problem more closely, the true issue is almost never that there is a gap between the product owner and the team. Instead, the problem is that the product owner and the team does not share a common vision of the product.

The product vision is a goal, a common idea, of what the product will be in the future. It might exist in the form of a prototype, design sketches, requirement documents or (perhaps more common) simply as a more or less vague idea in the mind of the product owner. Now, if the team does not understand, or share, this product vision with the product owner, it is not that strange if the gap occurs. The product owner and the team will inevitable talk about different things, mean different things, because they have have no common ground. So, the first step is thus to establish such a common ground. One way of doing this, is to simply gather the team and the product owner in a room, and workshop until a common understanding of the product vision is reached.

Now, what I have found is that the much more common reason for the product owner gap, is that there is no product vision.  There might several reasons for this, but the most common one is that the product owner considers the needs of the stake holders, but does not consider how the changes will work together as a whole. This is, instead, left to the team to figure out. While this might work with a brilliant, dedicated team, it is almost assured that this will fail with a team in a startup phase, or a team that is suffering from some dysfunction.

In this case, it is important for everyone to understand that there will be no great product, unless there is a product vision. Be it implicit or explicit – it must exist – how else can the product owner assure that the right stuff is being built?

Do you recognize this pattern? Please let me know in the comments.

The product owner – team gap

Product owner team gap

A fully functional, high-performing scrum team includes both a product owner, a scrum master and a development team. The product owner’s formal responsibilities are prioritization and funneling requests from the outside world into the product backlog, while the team and the scrum master grabs work from the backlog and turns it into potentially shippable increments.

However, this is not the full story. Many product owners struggles with the many responsibilities that comes with the role, and therefore – sometimes as a desperate measure to prioritize among their many business activities – delegate a lot of the responsibility to the team and to the scrum master. On the other hand, many teams expect all contacts with the outside world to occur through the product owner,  or that they do not need to worry about managing the product backlog (since that is the responsibility of the product owner).

When the product owner delegates too much to the team, it might leave the team feeling abandoned by the product owner. A good team might seize the opportunity to go ahead a prioritize the backlog themselves – which might work, but also might lead to suboptimal end results. A more challenged team might loose their agile practices altogether. After all, what point is there in having a demo, if nobody cares about the results?

Similarily, when the product owner is unable to fulfil the team’s expectations, the product owner might be frustrated by the teams inability to take the initiative. From the product owner’s point of view, it might seem that the team is waiting around to be spoon-fed ready-to-go-tasks.

I think of this as the product owner-team gap. That is, there is a gap between the decision level, where the product owner has the majority of the responsibility, and the operative level, where the teams technical expertise is required to refine and execute work.

This gap might seem superficial, because in no overview of Scrum there is such a gap. In reality, though, it almost always exists, at least at first.

One of the key ingredients in getting the entire scrum team to a higher level of performance, is to make sure that this gap is bridged. Either the product owner understands the importance of taking a step towards the operative level, and makes an effort not only to be present at refinement meetings, sprint planning meetings and so on, but also to truly understand the teams work environment and the teams needs and wants. Or, the team takes a step up to the decision level, and helps the product owner understand and prioritize the backlog. This means – among other things – that the team must make an effort to explain the contents of technical work on a level that the product owner can understand and relate to. The team must also explain why they need a product owner present in their day-to-day work.

For either of these solutions to work, it requires patience,  good understanding of agile values and preferrably the presence of an agile coach. Also, a key to success is interest in making it work. Without that, as usual, all approaches will fail.


How will they solve it?

I’m sure you have all been there. You know, that discussion that does not really solve anything. Perhaps you took part in it yourself, discussing that problem that your organization is having. All of you in that room agreed that it is a big problem for you, for your entire team, for the entire organization. You talk about how wonderful it would be if this problem could go away, you analyze all the terrible situations that will occur if it does not. You leave the meeting with a sense of having reached some profound conclusion, some deeper understanding of what is wrong with your organization, and you wish that they, the people really responsible for fixing what is wrong, could receive the same epiphany.

Here’s an unpleasant truth: unless you act on your new-found knowledge, what you just did constituted waste, and it should be eliminated.

”Come on”, you say, ”we must be allowed to have discussions about our problems. What about our retrospectives? Surely we can have those?”

Yes. Of course. But here’s an easy tell-tale sign if your discussions consititute waste:

  • If you are talking about ”how we will solve the problem”, it is a valuable discussion.
  • If you are talking about ”how they will solve the problem”, it is probably waste.

The difference in only one word, but it it makes all the difference in the world.

Please also see this  video from Jeff on this topic.