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