Archive

Archive for August, 2011

Draftning a first example

2011/08/30 2 comments

Yesterday, we worked on values, objectives and user stories in one of our projects. We were also given a short introduction to SBE by our coach Joakim Holm. SBE, for you who like me are new to to the concept stands for Specification By Example. I will not with my so not even basic whisp of knowledge about what this really means at this point even try to explain it, but we will formulate solid, important requirements and test cases in the form of specifications which can be executable. I will probably go into more details in later posts but if you want to readup on the subject, just google Specification By Example and you’ll find someone who can explain this much better than me.

So, back to my first encounter with these specifications. When I saw the way they were written, I first didn’t really understand how they relate to user stories – why do both? What is the difference between the notes on the flip side of a story card and a specification?

A bit skeptical, I during the first session started writing user stories. This is familiar grounds for me and we found a bunch of good stories. So I left the user story writing workshop with the intention to write a number of related specifications, exemplifying the user stories. No probs, hey. I know how to write this stuff, don’t I? I’ve written tons of user stories and as many test cases.

But this was no cup of tea. Writing these examples was so much harder than expected and I went home with a draft for one specification and more questions for our next session. Some of the questions are of course questions about formulating examples but most of them are domain questions and a large portion are directed to the developers and the architects. Which I guess is the purpose of this work. Keep you posted.

Categories: Agile, sbe

the story of a tunnel

When we talk about professions, we like to know if someone is good at the profession or if he’s bad. A good professional should probably be successful more than the bad one, or? So what about project managers? What is the definition of a good project manager. He should be successful at managing project, then. But what is successfully managing projects? Does this mean that the management should be successful or that the project should be success? But what does it mean to successfully manage a project and what is a successful project? This post focuses on the latter statement: the successful project. In many definitions, you take requirements, budget and time (and sometimes quality) and look before and after. If you can check as many of these groups as “as planned” then the project is a success. But then there is the sense of success. This should not be understated.

We in Sweden can be proud to be on the top three list of building projects. The problem is that it’s not the best but the worst building projects in the world. Just after the opera house in Sidney, we find the soon to be completed building of the tunnel of HallandsÃ¥sen. So, why has this tunnel made it into a list just two places below the Panama canal?

For you who are not up to date with Swedish politics, it all started with the railroad and the heavy industry in Western Sweden. In order to ship all the heavy goods, they wanted the railroad to go through the hill created in the last ice age, instead of over it. This would not only cut time but also enable heavier train loads. It was a sure thing but also a political necessity. It was important to show that we spend money on trains and not just cars.

The problem is that the hill was not helping out here. When they started to drill, it also started to rain in ground water into the tunnel. Not little, but a lot. And the wells in the surroundings were drenched and the tunnel needed to become more water proofed. Then the cattle on the hills started to become sick and die. The water became contaminated by the material they used to seal the tunnels. Also, it was not as easy to drill as they had expected. It was slower and harder. I don’t think anyone disagrees with me when I say that during this time, everyone saw the project as a failure. So there were haltings of the project, companies were sued and there was also legal proceedings regarding the spoiled water.

The projected was halted and then restarted. In 2015, the tunnel is predicted to be opened, 23 years after they started on the tunnel. I mean, Apple started selling the IPod one year after he launched is idea to his team and here it takes 23 years to dig a tunnel which is 8,6 km long. The tunnel was originally thought to cost 1 BSEK but will probably cost at least 12 BSEK in the end. Cattle died, people had to get new water supplies and of course we had all the scared people when we had the poisoning scandal.

A couple of weeks ago, I saw a TV documentary about this project and it was interesting to listen to how people involved saw the project. The engineer who saw this as the most interesting thing he’d ever done. He loved the technical challenges and probably saw the project as a success since they’d been able to overcome all these technical problems. We had the farmer who’d found his dead cattle one morning, who definitely saw the project as a failure: all that wasted money and of course the sadness over his lost animals. Then there was the project manager, focusing on the target: getting the tunnel DONE. He was a bit disturbed about the failed time plans, missed budgets etc but his work (even if there were probably many project managers along the way) was to be completed. They had not given in. The politician then. He was the most interesting person to listen to, from my perspective anyway. He also saw they project as successful, since it would be completed. But here comes the interesting part; he felt that it had been mandatory to complete the tunnel, even if it meant spending all that money since otherwise the spent money would have been waste. Come again? If you’ve wasted 2 BSEK, this money will still be waste even if you spend 10 BSEK more. But if they would have cut the project, then they would have spent the money but would not have a tunnel. Now we spend 12 BSEK and we get a tunnel. That is of course true, but think of all things you can do for 10 BSEK…

Finally, the reported turned to the potential customers. The heavy industry guy. As we all know, they don’t sit down for 23 years and just wait. They’ve found other ways and he didn’t see any big use of the tunnel.

The funny thing is that different stakeholders in a project can have such different opinions on the successfulness of a project. But who’s opinion matter?

Categories: Agile, Business, Leadership

Time estimation at school

2011/08/22 1 comment

Today was the first day of school for my son, beginning first grade. And is it not symptomatic that on his first day of school, his teacher gave them an estimation task. Don’t get me wrong. She seems to be a wonderful teacher and the exercise felt thought through but it’s in any case interesting that developers learn to participate in estimation before they learn how to write code.

The teacher told the class that she had one piece of straw for every day until Christmas break and she asked the students if they knew or wanted to guess how many days there were before the end of term.

Some students said 10, others 100 and someone said 30 000. It did feel like estimation of stories in other words…

My son waved his hand eagerly and was then given the word upon he said “as many days as you have straws.”

I wonder if he’s a natural at planning poker or just a little joker. Or perhaps he’s been reading Hitchiker’s guide to the galaxy.

Categories: Agile

Hey! May I have your attention?

Many of us who have children suddenly experience a change in what grab their attention. Suddenly they see things they would never even noticed before. If you don’t have kids you might have experienced this when you grew a new interest in something. When I got hooked on cycling, I saw cyclists and bikes very differently and I also became another type of driver: since I know how quickly I can ride my bike, I pay more attention to potential bikes on a road than your average non cycling driver. Sometimes this can be derived from more troublesome events. A couple of years ago, I was attacked by a probably mentally instable man while running to work and since he attacked me from behind I’ve since then become much more aware of scruffy looking old guys with big black dogs while running. Not that I’m afraid, but I do take notice of them.

What we pay attention to is personal but there are, as John Medina points to in his Brain Rules, also some cultural differences. Urban Asians view visual scenes pay a lot attention to the context of the scene and the contrasts between foreground objects and background objects while North Americans pay attention to foreground objects before paying attention to background objects and context. This means that different groups presented to one visual presentation will probably see very different things.

When we present something or try to make a visualization of something, we take for granted that others notice the things we want them to notice. But then again, we all know that you yourself don’t direct your attention to what the presenter had in mind. How many things have you thought about the presenter’s weird accent and missed the context of the presentation? How many times did one of the items in the presentation grab all your attention, making you miss the rest of the content?

We cannot force people pay attention to what we had in mind but we can do what we can in order to help onviewers pay attention to the important things. And step one is probably to recognize that we all pay attention to different things.

Categories: Leadership

The word resource

2011/08/20 2 comments

Yesterday I blogged about resource planning and not long after publication, Dave Rooney (http://practicalagility.blogspot.com/2011/08/im-not-resource.html) 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.

Our magical memory

When we say that we recall, I guess that we take for granted that memories are like goods in our warehouse, and when we recall a memory, it’s like our brains go and grab those memories in the warehouse. But as we can see from research (again, see the book Brainrules for some references) every time we access a memory, we change it. Sometimes slightly and sometimes very much. And when you think more about it, it do make sense.

My husband and I met 20 years ago and some of the memories one of us tell someone, they get to hear over and over again when we meet new people. What has is some instances happened is that the memory has been shared so many times that the main caracter change. Just this summer I heard my husband share an old memory not once but twice with some new friends. The problem was that it was not his memory but mine. Over the years, the story has become as much part of his history as mine. It is almost like our memory works like a whispering game where the story changes for each person who’s ears the story goes through.

It is also so strange what sticks to our memories. I’ve a good memory for odd details (pestering my friends with weird facts all the time) and numbers. I can still recall my grand mothers phone number even if she’s been dead for many years. My husband and my son share the habit of not remembering names of people but it’s so strange. My son can have known someone for years and still don’t recall their names but he knows all the names of all the Bayblades and he can even recognize a recognize and know the name of a Bayblade in the store. Some things are probably more interesting to remember than other.

Categories: Agile