Archive for the ‘planning’ Category

The word resource

2011/08/20 2 comments

Yesterday I blogged about resource planning and not long after publication, Dave Rooney ( posted a comment about the word resource.

I have some memory of this discussion, but I’ve not paid it any attention until now. I viewed the film and I can see some point to making a distinction between the words “person” and “resources”. But what words should we be using? When I use the word “resource planning” I cannot simply switch this to “people planning”. I don’t plan people and let plan their own work. I will gladly switch to other terms if the suggested terms are better and makes sense not only to the software development community but also to the customers and the developers themselves. When we create terms like scrum master and product backlog, we force our customers to use terms which they don’t understand and which does not make sense to them and for what good? It can also lead to so many misunderstandings. I’ve heard so many times how the word “sprint” has been interprated as what it means in sports. You exhaust yourself, which is not what I hope we want for our teams.

But I must take it upon myself to be less slack when I use the word resource and I can admit that that I’ve sometimes used that word when I should have said person or people. Not that I don’t like those words but rather due to corporate vocabulary. But here I’ll try to do better.

What do you think? Are you offended about the word Resource and if so: why? What should we use instead of the word resourc planning?

Thanks Dave for putting the spotlight on this.

Categories: Agile, planning

Calculating the need for resources

2011/08/19 2 comments

Most of us need to calculate the need for resources but the question is what you calculate.

One thing you can calculate is how much resources you need to complete a task. The first question is of course what do you mean by completing a task. If you’re working with software development, is it the coding, or does it include all the things you need before and after the coding (branching, getting to know the code, writing tests, merging, validating test environment) and does it include stuff that other people do. Another question is if you say something takes 10 days, do you mean 10 days of actual work or do you mean days between you start with a task and when you end the task, the latter concept is what we call Duration in Microsoft project.

In other words you need to know
* The definition of done
* Decide if you calculate Duration or Work

The next thing is that you need to start thinking about the difference between cost of delivery and cost of creating. Lets say you have a task which takes 40 hours of hard labor to complete. Lets say your resource actually completed the task in 40 hours. But chances are great that he will bill you more than 40 hours. People take breaks, the help other resources with their tasks, they do other stuff. Do they report these side things on your project? You bet! Imagine the opposite! Two resources are working on different tasks but on the same project. First one of the resources want a second opinion from his team mate. So he strolls over and they talk things over for 15 minutes. Would you want all resources keeping track on stuff like that. This is one of the reasons we want team rooms but it also gives us a situation when tasks cost more than the cost of their delivery.

As we are budgeting our projects, I must surely keep this in mind. In my budget, I must take into consideration that this happens so even if I use the scenario that 60% of time is spent on tasks, I need to calculate that they work 100% anyway. So I need to take into consideration:
* The number of hours tasks take
* The number of hours tasks bill the project

In other cases, thing become more complicated. Take the product owner role. That person should sit 100% of his time with the team but he doesn’t have to work 100% on project tasks. He can do other stuff in the team room (as long as he can be pulled from these tasks whenever someone needs help and that the other stuff doesn’t bother the other team members). If you do have a product owner who works 100% in the project that is perhaps more of a warning sign: you might have a product owner proxy or someone who’s not involved in everyday business work.

The probability of thing(s)

It is so easy to think we grasp probability and on a logical class room level we might but in real life situation, in comes our illogical brain and messes with us. This example is taken From The Drunkard’s walk (

Imagine Linda, 31 years old, single, outspoken and very bright. In college she majored in philosophy. while a student, she was deeply concerned with discrimination and social justice and participated in anti-nuclear demonstrations.

Now rank the probability of the following statements on a scale 1-8 based on their probability where 1 is the most probable and 8 is the least probable.

Linda works in a bookstore and takes yoga classes
Linda is an ensurance sales person
Linda is active in the feminist movement
Linda is a bank teller and is active in the feminist movement
Linda is a phyciatrical social worker
Linda is a teacher in an elementary school
Linda is a member of the league of feminine voters
Linda is a bank teller

Now look at your list before scrolling down.

If you are like the average person you would rank the scenario

Linda is a bank teller and is active in the feminist movement

as more probable than this scenario:

Linda is a bank teller

Look again.

If you were at a math class these scenarios would read

Linda is a bank teller = A

Linda is active in the feminist movement = B

This would lead to statement “Linda is a bank teller and is active in the feminist movement” = A +B

So, how could A+B be more probable than A alone? It’s not but our minds are playing with us. Giving that personal description, we get an image of a feminist activist and that seems so probable that we forget about maths and logic. And if we look again, even if Linda was a feminist in her youth, this might not be true anymore.

You might not have fallen for the little trick here, but most people do. They search for patterns and a pattern is often more appealing to our brains than the logical rules of probability. I cannot help thinking about estimation poker when I see this example. Also, we humans love story telling and by just adding another statement to the description of Linda. By describing her using two words she become more probable than if described using one word.

What do you think?

Categories: planning

Random rantings on randomness

I may be a bit black and white here, but I often find that in the question of measurements and estimations there seems to be two clear sides and the battle is tense:
– Measure everything! You get what you measure! If you can’t measure it, don’t do it!
– Measurement leads to people doing what ever to get high scores, not high results! We spend so much time on measurements that we don’t have time to do any changes. Depending on the measurement point and method, you can present any result.

So where am I? I see myself somewhere in the middle and I cannot decide where my heart is. Probably nowhere. So hence I turned to randomness. Or rather, Audible did. I have an Audible subscription and every month I get a new free audio book and since we were on holiday, I took the time to get some new nice reading. I seldom have something special in mind and pick something that sounds interesting. Since this was the way I found Predictably Irrational and Made To Stick, I find this method very good. I find books I would never have selected otherwise and many times I’m very happy with my choice. And this time I found Drunkard’s walk by Leonard Mlodinow. I was directly hooked. Math was never my strongest subject, but here I was drawn into the history and almost magical world of randomness. The book also covers how the workings of our brains clashes with the workings of randomness. We are pattern seeking entities and randomness is random.

To summarize, what is hard for us to grasp is that there is a small chance that something specific improbable will happen to us but very probably that something improbable will happen. As an example, the chance of you dreaming of your aunt the night before she dies probably feels improbable but the chance that someone of her many friends and relative do is not as improbable as one might think.

In the first edition of the Ipod, Apple spent a lot of energy making the random song selector working randomly and they did such a good job that people complaint about it not being random. Again, the chance of The Winner Takes It All being played twice on your morning jog is not that high (if you have that song and loads of other songs on your device) but the chance of any song being played twice is not that low, given that you have that song on your device. With a true random song list, it is not unlikely that one song is played every time you use your device. But when you change the question to what the chances that specifically The Winner Takes It All is played everytime, the chances drop dramatically.

For you math geeks, this is nothing new, but for me so thoughtworthy and there are some aspects of randomness which I will continue bothering you with.

So I leave you with a question to the next time. Imagine that you are participating in a game show. You have three doors in front of you and behind one door, there is a wonderfil sportscar. The game show host tells you to pick a door. The game show host, who knows where the car is, then opens one of the doors you didn’t pick, knowing that he opens a door behind which there is no car. He then asks you if you want to stick to your choice or if you want to change. Should you?

Categories: Leadership, lean, planning

A clear objective is no silver bullet

I’ve many times, as so many others, stressed the importance of clear and shared objectives, but is that enough?

Just because you and everyone else know the objective does not mean you share the same view on how you measure if the objective has been reached and what is key to reach the objective. I believe that the measurement and and the main road is as important. The high focus on just setting the objective(s) is simply not enough. If the group does not share the same view on how success is measured and what is important in order to reach the objectives, I believe there will not be a factual common objective within that group.

Categories: Agile, planning, Usability Tags:

Requirements Specification or Overview

Today, I had a meeting during which one of my current projects were discussed. One of the participants asked me about the requirements specification. And my response was: we don’t have one; we’re trying to working with an agile approach. The response to this was quick – agile is not an excuse not to document. But I never said we don’t document.

For me, specification is not a positive word. If you consider the word “Law”, a picture can be the law book, and the book worm, preferring reading and reciting rather than meeting others. Here I find the word specification.


But the word “Law” can also have another side, illustrated by the following picture, when you way stuff. There is seldom a right and a false side. We just have to find the most fair way to view things. Here there are no specifications, but rather an idea, discussions and a general impression of what we want more off and what we need less off. Could you call it a requirements overview? I guess there is no correct word. My discussion partner asked if we instead had a backlog, but that term does not catch what I’m after.


We have mission statements, flowcharts, prototypes and user stories which describes what experience we want for the users. If you want to call that a specification, you may, but I need a better word which does not bring that book worm picture to my mind.

Categories: Agile, planning

Cutting features or processes

The other week, I was participating in a process modeling workshop. We’ve been struggling a bit with project scope and objective, but now I think we’re getting there by focusing on cutting processes rather than cutting features.

In most projects I’ve been involved in, we’ve cut features. I’ve actually been part of two projects in which we added features, but this is as you all know not the normal scenario. When it comes near the project end, the ax is produced and we start cutting trees.


Or in some cases, we take out the lawn mover instead, making everything smaller.


But what is often the case is that the cut feature has some perhaps unexpected consequences. By cutting feature A, feature B and C becomes pretty useless, since they depend on feature A. Or if you use the mover, slimming everything down makes a lot of things useless since they don’t take the reality’s complexity into consideration.

But if you instead clarify the processes, you can see these dependencies and  cut processes instead. This in many cases means that you instead of cutting one feature, cut more. This is more like closing off a road.


It also becomes easier to communicate to stakeholders: what processes we should support and which processes are not supported. This does not make it easier. People never like their stuff being cut.


Categories: Agile, Modelling, planning


Most of us don’t want anything bad to happen to our kids. In order to keep them safe, we make choices which secure their safety and we set up rules and regulations to prevent those unsecure situations. If it can save the life of a child, we should of course do it. To be on the safe side. Or should we?

David Eberhard, a Swedish psychiatrist, describes in his book “I trygghetsnarkomanernas land” (In the safesideoholics land) he describes a time when everything should be on the safe side but also a time when teens get a psychosis when they are dumped for the first time, where the psychological health is on an all time low and when more and more people get burned out.

Eberhard does not buy the official reasons for this: that the pressure is so high today. He believes that the cocoon like state we put our kids in are ruining their chances to learn how to cope with risks, failures, pressure and sorrow. So, when they are finally in a  risky situation they don’t recognize it (since they are used to everything being safe) and when they are faced with a sad situation, they panic. Our “On the safe side” mentally are killing their possibility to live life to its fullest.

The social pressure is also a factor: we talk negatively about the parent who lets her kids cross the street on themselves and these stories are great headline news. It’s better to follow the crowd. To be on the safe side.

I recognize the situation all too well. I have friends who’ve brought their kids to the E.R. for symptoms I would say points to a common cold. Not just once, but many times, and still they continue this habit even if they keep coming back with the same conclusions from the doctors. To us other parents they say: well, it was perhaps not anything dangerous this time but you want to be sure when it’s your kids, don’t you? I don’t know how many times I have had to bite my tongue: No, I don’t think it’s OK to waste precious E.R medics time. And no, I don’t think it’s OK to spoil the weekend for that kid, having to spend yet another day in the waiting room. And I don’t think it’s OK that really sick people get to wait even longer because of this.

What is really sad about Eberhard’s conclusions are though that he thinks that the main concern of these parents are not the kid, but themselves. No parents can forgive themselves if they did something (or didn’t do something) which caused harm to their kids. In other words: we are afraid of the feeling which we would cause ourselves if something happens.

Sometimes while reading this book, I started to think about all these projects out there. All these efforts to introduce agile values in software development. Yes, it’s probably sick to think about that all the time, but I couldn’t help but see the consequences in my work situation.

What happens when the failure afraid, security manic safesideoholic parent come to work and get to plan that project? What does he feel about an agile approach, when he don’t get an estimate in hours but in story points? When he cannot see which date which functionality is delivered a year in advance?

No wonder that many thinks that the traditional waterfall approach is nice and comfortable. It feels great to wait with starting the development to after we have that thick pre study. We have really done everything to get to the bottom with this problem. If they project goes south, no one can say that we didn’t analyze the problem before we got started.

And what are the consequences for the project and the project group? Well, if you’re into agile values, you probably have an idea about this not giving ground for the most innovative development.

Categories: Agile, Leadership, planning

Creating a mindmap specification

2010/04/30 3 comments

In one of my projects, one of the lead developers asked me for a flow chart, describing the things we’re building. Far from the scrum product backlog, yes, but I decided to give it a try.

I downloaded XMind, a free software with a PRO version with really useful functions, but since I’m just testing the concept as a product owner, I decided to test the free version.

The result, many hours later, is a number of connected flow charts which all looks something like this:


I started with setting up the basic flow chart, and identified the main steps. All these main steps were given their own page in the workflow workbook and then I started drilling down. I looked at all steps and identified which functions I wanted to be available from that step and if there were any special scenarios. To help me out, I have the work from our user interface designer, so all I had to do was translate his work into this flowchart and identify these special scenarios. Well, “all I had to do” is perhaps to simplify the task. I will not hide that it was hard and sometimes gruesome work. For each step I covered, I identified more special cases which I need to find solutions for.

But after a while I got to really like this approach. I focused on one step at the time. Took a good look at that step and tried to think about if I’d really seen all the ways to which one could come to that step and I tried so see which steps were possible from there. The nice little note functionality made it possible to add all those special scenarios and questions.

In a couple of hours I had documented all those discussions we’d had in the project group and I would say that what we have is a number of user stories, but in another format. I can better see the links between stories, and it’s easier to track what the story applies to, without having to write too many X:s under “As a X” if I’d used the user story format.

Also, the diagram does something that user story cards don’t: it puts the story in a context. Yes, a user story does say why we do the story, but it does not show what happens next and what we take for granted has happened before.

So, what about the output? There is a HTML export function which exports not only the image but also the comments and pictures.

WHat about the next step? the next step is to see if the developers like it or not. And if they do, we have to find a way to build using this. But the first step is to see if this is the way to go. What do you think?

Categories: Agile, Modelling, planning, scrum, Usability Tags:

Pain is temporary, planning lasts forever

2010/02/22 1 comment

Do you know who this guy is?


His name was Trofim Lysenko and he was the father of vernalization. He thought he could make wheat cold- and humidity tolerant by exposing it to this the same way you can learn a person tolerate pain by exposing him to it. It might seem like evolution but the difference is that evolution does not act on the current generation; it affects future generations by making the tolerant strains more common.

Lysenko make farmers plant soaked seeds in frozen lands. The result was a disaster. The yield did not triple as Lysenko had promised and instead it decreased or ceased.

This would have been the end to this story hadn’t it been for a number of sad coincidences. We are in Stalin times and land. So, even if the plan failed and people died by the millions, the practice did not only stay but grew all over the Soviet Union. It was not until the 1960’s that the Soviet Union lifted the ban on genetics and slowly started turning away from vernilization. The cost in human lives is incomprehensible but we’re talking about millions of individuals, starving to death. So, what went wrong?

Well, if we for a second ignore the guy with the huge mustache and just look at Lysenko and his crew, I would claim that the problem was not the idea. Yes, it proved wrong, but having wild ideas is not a problem. The problem was that they stuck to the plan even if it obviously did not work.

Realizing that you are wrong is often painful. Depending on your pride, it can be very painful but if you’re a sane person this pain should subside. This pain is temporary.

If you instead use the scientific approach and keep on planning, keep on evaluating, if you stay agile, you can exchange that pain with the joy of succeeding.

I don’t know if Lysenko realized that he was wrong. He died in 1976, and I find it hard to believe that he never in the deepest roots of his heart did not realize that he had been wrong. One or two of the guys on his team must have wondered, anyway. And still, it took so many decades before actions were taken.

In software development, we project managers often find ourselves in Lysenko’s shoes, having made the wrong assumption about a problem or a plan. And we need to face the fact that we were wrong. We need to meet our stakeholders explaining the new plan and the new hypothesis. The pain will not be lesser if we wait. Just look at Lysenko, how many find it OK that this continued for so long?

Hence, Pain Is Temporary, Planning lasts forever.

The saying is of course also a game with another famous saying from Lance Armstrong. The original is “Pain is temporary, quitting lasts forever”. And if you stop planning, if you stop acting on changes and new input; you have quitted your responsibility. The project manager who keeps holding on to the failing plan is quitting his responsible as a manager and becomes an administrator. I guess he’s not as bad as Lysenko, but most of us aren’t working for Stalin.

Categories: Agile, Leadership, planning