Archive for September, 2009

The calumet in the form of a biscuit

Yesterday was spent in the company of supplier in Bristol. It might seem like an outdated solution to bother to travel to a supplier, but having worked close with both business people and developers, I truly believe that a personal meeting beats it all. In all our upcoming meetings, which probably will be held over the phone or using our web based conference systems, we will at least have a face and the meeting in memory.

Working with agile values we all know this. But in the days of digital communications and green values, it’s so easy to think that it don’t make such a big difference.

The problem is that in the case of software systems, the developers are not included in the actual meeting of clients. Perhaps XP set aside, many use proxies or let the manager meet the customers. If I can chose, I think it’s better if the developer meet the customers. Customers like seeing the guys working with their tools and developers will (I think) do a much better job if they see the actual people and hear the words from the source

Sitting there eating biscuits and drinking tea, it almost felt like the traditional calumet. The native Americans were not stupid when they applied this ritual. And the idea of two persons sitting in different parts of their world sipping on a pipe of their own is not the same thing. Why would we ever think that modern meetings are different?

Categories: Agile, Leadership Tags:

Why me? or Why Me!

2009/09/26 3 comments

I can’t say that I’m a big fan of Sammy Davis Junior but he’s the man behind the statement above. When he was young, he felt Why Me? and thought about that he was short, kind of ugly, one eyed and a jew. He was concentrating on why he had all these negatives. In other words, why was he a victim?

Later on, he became really successful, and the statement stood but with a different focus – Why Me! How come that he could become so successful?

One of my first blog posts discussed Aron Ralston and Between a Rock and a Hard Place. Dedicated climber and adventure skier Aron Ralston fell during a climb and got stuck between a rock and the rock wall. He also asked “Why did this happen to me” but he soon realized that the question was why it hadn’t happened earlier. And then he realized that he could do nothing about what had happened. Now he was there and he wanted to survive.

Self portrait of Aron of his actual situation when he was stuck. (source

Both Sammy Davis and Aron Ralston was in situations less than ideal. But there they were. But they both decided to do what they could. In the case of Sammy Davis he used his looks to create a new and different type of performer. Aron Ralston cut of his hand to break free.

Viktor Frankl was an Austrian neurologist who survived the holocaust. In his Man’s searching for Meaning, he states what made him survive was that he accepted what he couldn’t do anything about how he was treated but he could do something about what he did and what he thought about. While they without any pain killers operated on him as a part of a medical test, he thought about how he would talk in front of students about this experience.

We always find ourselves in these “why me???” situations. In some cases, we are born into them, they just happen, etc. In other cases, we ourselves place us there. And in some cases, someone else puts us there.

Habit 1 of The Seven Habits takes focus on these situations. And the key value is to try to do something about what you can do something about and accept what you cannot do anything about. It’s about being pro active and take responsibility.

What does it matter if you’re genetically predisposed to becoming obese? Even if so, you can do nothing about that but what you can do something about is what and how you eat and exercise. Whining about genes doesn’t help you, does it?

What can you do about your boss being a complete idiot? Will he become smarter of you complaining about it? You can choose to live with that, try to lessen the effects of it or find yourself another job.

In many cases we just stop here, whine about stuff we cannot do anything about. Ralston tried moving the huge block of rock. But he couldn’t so he affected what he could affect. How much time do you spend on trying to move those huge blocks of stone?

That does not mean that doing what you can is not painful? All these stories are filled with pain but the question you need to answer yourself is – what can you live with?

I took a CPR training this Thursday and people were worried about hurting the person in question. And the trainer, having seen some of the worst scenes imaginable responded: We pick life over injury.

We sometime don’t pick the situations we’re in but we’re better off trying to do what we can about the future and if we see ourselves in control of what we can control.

Categories: 7 habits, Leadership

Does the productivity decline if you don’t time box?

2009/09/19 1 comment

Having just read Dan Ariely’s excellent Predictably Irrational, I have a lot to reflect on. On my latest project, we’re using Kanban, which means that we don’t timebox, we don’t use sprints and we don’t estimate. But does research support the notion of excluding the concept of time boxes.

Dan Ariely made an interesting study.  He had three groups of students, which all were supposed to hand in three papers during a course in Consumer Behavior. He gave the three different groups different instructions concerning these papers.

Group 1:  They could hand in the papers at any time of the semester. The student would themselves set the deadline for each paper. If the self proclaimed deadlines were not be met, there would be a penalty. All students had the option to set the deadlines on the last day of the class but they could also use the deadlines to force themselves to start working earlier and work during the whole semester.

Group 2: This group would have no deadlines and they could hand in their papers at any time and there was no risk of penalties if they did hand in their papers before the end of the class.

Group 3: This group were given specific deadlines for each paper and there penalties if the deadlines were not met.

Which group do you think got the best grades?

The third group had the best grades. The second group got the worst grades. Ariely points at our tendency to procrastinate makes us delaying important tasks and the best way to avoid this is a formal figure giving us specific deadlines. But the study also shows that if we ourselves are given the option to set our own deadlines, this helps us to evaluate this risk and handle it.

If you look at the deadlines in group 1, the ones who spaced their deadlines did as well as group 3 while the students who placed their deadlines at the end of the semester.

So, what does this mean for software development? Does it mean that removing the iterations, independent if you work waterfall or kanban, increase the procrastination? I need to think more on this and this will for sure be a subject on our next team meeting.

Categories: Agile, Kanban Tags:

To retrospect or not retrospect; that is the question

2009/09/15 3 comments

Steven “Doc” List shared his and Chris Matts discussion on retrospectives. A site from Chris Matts:

I consider retrospectives to be an anti-pattern. If you are learning great stuff in your retrospectives, it means that your communication is blocked. They are “batches” of “feedback”. I prefer single piece flow of “feedback”.

It is important to stress that he means organized retrospective meetings. I don’t think anyone believes that reflecting on the past is a bad thing. But Matts has a point that the meeting might lead to people not taking care of issues straight away. And this almost like keeping bugs on a queue; you keep bugs in your process.

I think we must really think about how we can avoid this behavior, but still I believe that sitting down and under calm circumstances reflecting on the past gives a bigger picture. The problem might not be obvious to one single individual but becomes obvious when many look at something.

One of my favorite retrospective exercises from Agile Retrospectives is the time line. People gather around a time line and posts issues, feelings or incidents on the time line. By using color coded postit notes, you can afterwards look back and see the emotional state of the team during a time period. I use Mad (red), Sad (blue) and Glad (green) and the participants are instructed just to write an explaining word.

When there are ups and downs in the collective emotional state of the group. This makes it possible to pinpoint periods where many are facing problems and perhaps you can see patterns. Often the negative emotions move downstream to other team members.

If also enables team members to see this for themselves and perhaps gain knowledge about the feelings of others. And finally, it helps people reflect on their own feelings. How did I feel about the testing environment not being up and running when I had the time. I perhaps expressed anger but what I really felt was sadness that I wasted all that time. And yes, I did feel really happy about that visit from the project sponsor where he really answered my questions.

So no, I don’t think that retrospectives are an anti-pattern, if used correctly.

Categories: Agile

Another round of Microsoft Project Tutorial episodes?

2009/09/14 1 comment

I’ve received a couple of questions lately concerning Microsoft Project, which I haven’t covered in a while, so I’ve decided to write some more posts. I will, as I’ve previously posted, also post an example file for an agile project in Microsoft Project. But what are YOU interested in? Post a comment or e-mail me if you have any specific topics for me to cover.

Categories: Microsoft Project, planning Tags:

The non responsive UI – a nightmare for users and testers

If there is something I cannot tolerate as a computer, it’s a non responsive UI.

I’m currently updating my IPod music list and I’m so disappointed with Apple that they still haven’t fixed the responsiveness of the UI. If I click a song in the list, it takes seconds before ITunes starts playing the new song.

My least favorite program is in a class of itself, as always. When I select an e-mail in the Inbox it can take many long seconds before the right message is displayed in the preview. This has sometimes resulted in missed information and always a lot of frustration.

As a tester, the non responsive UI is also a big problem. I click something. Nothing happens. So, I click again. Something happens. Is that because I clicked once or twice?

When you’re buying new software for your staff, don’t be satisfied with a PowerPoint presentation, test the UI yourself. And that does not mean the salesperson showing what he wants to show with the data he wants to display. If you have a product list with 100.000 products, make sure you test the search functionality with that data. And make sure that you are handling the computer. Salespeople know their software, know where the loopholes are. But he won’t be there when the guys can’t complete their tasks because the software is malfunctioning.

We can all blame the software industry for sloppy work in this area but as long as the people buying the stuff does not demand this as much as they demand functions which they rarely use, why should things improve?

Categories: Business, testing, Usability

Bye, bye Scrum dashboard, hello TFS Work Item Manager?

2009/09/11 3 comments

Yesterday, my husband told me about the new funky WPF client for TFS and a couple of minutes later a colleague of mine had installed it and we were testing it. The UI isn’t all self explaining but it looks promising. I hope I can test it better next week.

Here is the link if you want to try it out

Categories: Agile Tags: