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.


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.


Story points and hours


A very common question from teams starting out with Scrum, is that about story points vs hours. How is estimation done? Can we use hours instead of points? Isn’t it the same thing? (Hint: it’s not.)

Before we proceed, I would like to make it clear that there is no definitive, general answer to how estimation should be performed, or whether you actually should be doing estimation at all. Every team must find its own answer. However, I find that the following is a good starting position.

And to get us going, we should start with the ”why?” before getting to the ”how?”.

Story points

Story points, or just points, are used in Scrum to estimate the complexity of an item in the product backlog. The estimation are typically done during refinement meetings or at the sprint planning meeting at the latest. Poker planning or swim lane sizing are common estimation methods. The purpose of the estimation is not only to get a complexity estimate – and therefore help the product owner in prioritizing – but also to check that the team has the same idea of the effort involved. The estimate is then used during sprint planning by the team to know how much work to commit to for the upcoming sprint, perhaps based on the number of points done during previous sprints.


Hours are used when estimating the tasks that needs to be done in order to reach the acceptance criteria specified in the product backlog item. If the remaining effort on each task is updated regularly during the sprint, it is possible to create a burndown chart that visualizes how much work remains to reach the sprint goal.


Story points Hours
Estimate of… Complexity Work
Estimated at… Refinement meetings Sprint planning
Can be used to answer… How much work can we manage in a sprint? How much work remains in a sprint?
Are updated… Never; or possibly at start of next sprint if not done. Regularly.

There is no conversion factor between points and hours. Never. Ever. There is a correlation between the two, however. You would expect an item with small complexity to have tasks that sums up to a small amount of hours – but this does not always hold.

Misusing the estimates

It might be tempting to reuse the hours estimate for other purposes than the one stated above. For example, you might feel tempted to grab the number of hours from a number of tasks, multiply by some hourly rate to get a cost estimate. That is a bad idea, since that was not why the estimate was made. In fact, any idea to map the hours of the task estimates to any other measurements of hours, such as the team’s available hours, is probably a very bad idea. If you need such an estimate, ask the team explicitly for this.

Story points and hours

Do we need to do both story points and hours?

If you do not care about how many points you commit to, but instead use some other method (perhaps your gut feeling?) to know how much work to put into a sprint, then you do not need points. Beware, however, as it is quite likely that you will miss out on necessary discussions during refinement meetings.

If you do not plan to visualize the amount of remaining work, or use some other way of visualization, or if you are unable to regularly update the remaining effort, then you do not need hours.


Each agile team must find its own way in doing estimates (if at all), but to avoid the common pitfalls you should understand how Scrum has been implemented before. Story points and hours are used in different circumstances, and the estimation for product backlog items and tasks have different purposes. Be aware of this.

And when someone asks you to estimate the entire backlog in hours, remember to ask ”why?”.

The Backlog Team Incompatibility

In theory it is simple. You form a cross-functional team, you set it up with a visual, prioritized backlog, and away you go on your journey towards agile.

In theory, your team can handle anything you throw into the backlog. The team is a software factory that churns out quality code with regular intervals and everybody in the team is happy with their new role as a team member.

Theory – meet Reality. Reality – this is Theory, that I’ve told you so much about.

In reality, all team members cannot – because of skill set or experience or role (or even, in some cases, their long term career plan) – handle (and not even contribute to the completion of) the work items that goes into the backlog. Regardless of the reason, I call this the Backlog-Team-Incompatibility (BTI).

There might be several causes for the BTI to occur – perhaps the team was originally formed for some other purpose, or the team has members with some competence that is no longer required – but it does not matter. Somehow, the BTI must be handled, and sooner rather than later.

The short time span

Depending on the team, it might be the scrum master or the team members themselves that becomes aware of the BTI. A team member suddenly has no more suitable tasks, and the new tasks on the board are simply not a good fit. Do not worry! This happens to all teams, all the time. Take this as an opportunity to pair program, learn new things, share knowledge, work on that system documentation, set up a build server or test routine or something else that the team will benefit from.

The average time span

If a team member consistenly is suffering from BTI, and the team feel that they have exhausted their possibilities of resolving this situation, the product owner must be notified. Perhaps there might be suitable tasks with currently a lower priority that could be worked on? It is in the best interest of both the team and the product owner to keep the team both intact and productive, and if that means that the team temporarily does not completely work on the highest priority items, the trade-off might be worth it.

The slightly longer time span

If the BTI persists over time, the issue must be brought to the team member’s manager. Remember, it is not because the team member lacks

thermometer-309120_1280competence he or she lacks suitable tasks – it is just a ”case of BTI”. Again, it is usually preferrably if a solution can be found without making changes to the team. Perhaps the team member can use training or coaching to find suitable tasks.

The longer time span

If the BTI still exists over a longer period of time, the team member’s manager must take action, and remove the team member from the team. Again, it is not anyone’s fault – it is just an incompatibility.

 A final word

It is important that the issue is discussed early with the product owner and the manager – exactly when depends on your situation, the severity of the BTI and the economy of the project (for how long can you afford to not utilize every team member?). The team or the scrum master can and should try to solve a BTI by themselves, but this might prove to be very difficult. And if the BTI is not resolved, the delivery, the team, and the team member will all suffer.


Agile for the non-development team: a practical guide

I have no idea what this has to do with the article, but they sure are cute!

I have no idea what this has to do with the article, but they sure are cute!

Disclaimer: This article was intentionally written for an audience that do not know or care about the terminology of many of the agile methods. If you are a hard-core agilist, please look away.

Let’s say you have a group of people that want to try agile, but you are not sure where to start. If you have been working without any real method before, then Scrum might seem a bit heavy-handed, and Kanban scares you off with rules and an unfamiliar terminology you do not quite understand.

This is how you (might) do it.

  1. Start off by taking any large piece of the wall (or a whiteboard), and create three columns: to-do, doing, done. Take all your current and upcoming tasks from all your group members and put them down on post-it notes. You don’t have to write an essay on every note, just enough to make it clear what each note represent. Put them up in the appropriate column.
  2. Explain that each member of the group is responsible for updating their own notes, moving them along the board, and putting up new ones as new tasks appear.
  3. Make an agreement with the group that they meet every other week for two hours and discuss how to improve the process.

Really, the only necessary and mandatory step is 3), the other ones are just there as a conversation starter.

Depending on your group size, the two hours might look different. The important thing is that you have a meaningful discussion, and that you walk away from the meeting with at least one action, change, or experiment that you want to try for the upcoming two weeks.

Issues and experiments that might solve them

I cannot tell you what issues you might run into – that will be different from every group – but here are a number of issues that might come up and experiments that you could try to solve them:

”I cannot work on my tasks, because x is on vacation”.

Working in a group, or a team, requires each task to be the responsibility of the team, not a single individual. Try collaborating more, making sure that every task can potentially be done by at least two different people in the team (who do not go on vacation at the same time).

”It is unclear what ‘done’ means”.

Book a meeting where the team decides on what done means for different tasks. Create a short definition and put it up next to the board so that everybody can see it.

”Our to-do column is overflowing”.

Only put up tasks that you are planning on doing for the next two weeks (or whatever time span seems reasonable) in the to-do column. All other tasks can be in a longer list in a spread sheet or on a physical to-do-list.

”I do not know in which order I should be doing my tasks”.

You probably need to have someone help you prioritize your tasks. Who this person is, depends on your business. Preferably, it should be someone from the receiving end of whatever your produce.

”My tasks are too big, and just get stuck in the ‘doing’ column forever”.

You probably need to break down your large task into smaller ones. It is a good idea to do so before the task end up on the to-do-column, but not too early either – the prioritization might change. Gathering the team to discuss upcoming tasks regularly will help.

”My tasks have a good size, but they still seem to get stuck in the ‘doing’ column”.

You are doing too many things at once. Try to prioritize and get one task finished before starting a new one. You could try to set a reasonable limit on the number of notes in the ‘doing’ column. This means that instead of just choosing a new task when you get stuck with the current one, you must ask for help in order to get it to ‘done’.

”I do not know what others are working on”.

Perhaps a short meeting everyday can help? Focus on this meeting is to update everybody, but also to be able to ask for and offer help to the other group members.

”I can see that a lot of tasks are in ‘doing’ column, but not who is responsible”.

Simple: if you are responsible for a task, write your name the note.

”What we are doing are being questioned by outside stakeholders”.

Set up a meeting, perhaps every two weeks, where you show what you have done, are doing and why.

”There are too many external disturbances”.

Explain to the outside world that you are now a team, with a prioritized workflow. Any additional work should ideally go through that workflow. Invite people to your meetings, so that they can see how you work.

This is agile

Wait! you say. Is this all there is to it? Is this agile?

Well, yes, it’s a perfectly valid start. Communicate. Be creative. Dare to try. Improve. Go for it.

Introducing: Agile

Will it work with…?

Since a while back, I have a new assignment: introducing agile methodology in a major organization. I’ve also recently been in contact with other organizations, interested in replacing their current methods with agile. Now, these aforementioned organizations do not have that much in common, but they all voice concerns about making the transition to agile: ”will it work?” is an obvious question, while another – but just as common – is the extension ”will it work with our existing methods, roles and processes?”gears-520888_1280

Now, I find the latter question more interesting, because somewhere in there is a bigger issue. It indicates a conservative desire to keep everything as it is, while benefitting from the new. Perhaps that is human nature. But more serious is that it, when probing with follow-up questions, indicates an organization where several such method initiatives have come and gone over the years. Each such initiative have been preceeded by discussions on effectiveness, communication, structure, tools, etc. From many co-workers point-of-view, there is no difference between ”introducing RUP” or ”introducing agile”. It is just another one of a long line of changes supposed to improve their process, driven by consultants (such as me), after a while being replaced by another intiative when the results did not live up to the hype.

Methodology inheritance

The question ”will it work with…” thus also implies, that the employees have to live with a large flora of more or less related methods, roles and processes, sometimes being forced to perform tasks that belongs to a role long since obsolete. They still do them, because they always have done them, or sometimes, put bluntly, it might be a bit unclear as to what their current role actually are supposed to do.


You might by now see where this is going, but here it is spelled out: there is no point in blaming your existing methodology for its supposed short-comings, when you are actually not doing what the methodology tells you to. The same is true for agile. You could with some effort apply Scrum, do it by the book, and still not be very happy with the result. You could with much more effort apply SAFe – or some other agile scaling framework – after which you would throw your hands up in frustration since nothing has improved. The only thing you achieved was more confusion.

Inspect and adapt

Here is the catch: you do not ”apply” agile. You are agile. There is no agile ”method”. You inspect and adapt. And this is the difference between ”introducing agile” and all those other, previous initiatives: agile is all about attitude and mentality, and really very little (or nothing) about a preset number of documents and rituals.

Since nothing is a very tough starting point, there are a number of methods or frameworks that previously haveinspect_and_adapt proven to be successful that you can start off with. But they are not intended to be used as-is, and they are certainly not intended to be the ultimate agile goal. ”Introducing agile” is thus, in itself, a large exercise in inspect and adapt.

Thinking agile

When done correctly, the people in the organization will start to think agile, which in turn might lead to it actually making the necessary changes in order to achieve the desired effects. By inspecting and adapting, we can make agile working with just about any other method (if truly necessary, otherwise our agility allows us to remove the obsolete obstacles).

Now, the road to agile is not easy. It requires quite a lot of work, inspiration, education and perseverance. I know a consultant that might help you with that. 🙂