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?

Why me? or Why Me!

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 healthline.com)

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.

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

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.

To retrospect or not retrospect; that is the question

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.

Another round of Microsoft Project Tutorial episodes?

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.

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?

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

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

http://tv.telerik.com/tfs-tools/video/intro-tfs-work-item-manager-and-tfs-project-dashboard

What is the problem with your problem?

The other day, I visited a web site with an e-com solution as a wanted to make a purchase. I looked at their product catalog and found that they had the product I wanted.

I turned to the site’s web shop, ready to complete my purchase. But when I searched for the product, I couldn’t find it.

I looked again at the product description. Yes, there was nothing indicating that this wasn’t being sold, or that there was any problems with the stock of the items.

But I still couldn’t find the stuff on the web shop.

And there I could have left it, gone to someone else, but since I’m myself developing e-com solutions, I became curious. So I contacted the help function.

I provided a link with the product description and described how I’d tried searching for the item.

The response I got was that the product was only sold during summers. Yes, I could imagine that the product was for summer days but since people go on holidays during the winters, you might want it anyway. And besides this; why market a product you don’t sell?

The response was that there was no error in the e-com site. The stuff wasn’t supposed to be sold so you couldn’t buy it. And that was it. He wasn’t even interested in why I was spending all this time on this question. So, bye bye.

This is just an example how poorly some companies treat their customers. When a felt error is reported, the definition of a Case or an Issue is being thrown in the face of the reporter and the staff doesn’t anything about taking care of the person’s complaint. What really happened during our discussion was:

I: “There is an error”

He: “Your complaint does not meet our definition of an error. So, bye bye. Since I don’t really care about your feelings about this being an error, stop wasting my time.”

Perhaps this had a good explanation. Perhaps they couldn’t remove stuff from their site based on season. Perhaps the person responsible was sick or something. But since the person I contacted didn’t even wanted to recognize that this was perceived as an error, I lost my trust in his business.

But I also have a happy story to tell. My bike was stolen a couple of weeks ago and I contacted by insurance company and filed a case.

A couple of days later I was called by a person from the firm and after verifying that she had the right person on the phone, she before anything else expressed her condolences for losing an almost new bike. I don’t know if she really cared but the mere fact that she bothered to try to see it from my perspective made all the difference. She recognized me.

This affected our whole conversation and I probably feel better about our deal than I would have hadn’t she been such an empathic person. (Btw, the company is TryggHansa!).

We can all learn from this; from the project manager rejecting a new requirement, the developer getting bugs reported, a boss hearing some complaint from his staff.

Read more in

Wired to Care: How Companies Prosper When They Create Widespread Empathy

The mandatory stuff

When I have a story writing workshop or some other brainstorming activity, one important task is of course to learn what is really important. Since I’m in the mental moving from scrum to Kanban, this has become more than important. It is crucial.

So, these are my phases of a story writing seminar:

 

The objective

During this part, we discuss the overall objective of the project. What we’re doing and why. I try not only to explain what the customer wants but I want the team to really make the objective theirs. I want them to form their own Commander’s intent so they not only know what the objective is but also what it’s not. We don’t have time for nice to haves. Most of the time…

 

Brain storming stories

This can be divided into a number of separate parts. If it’s a new group or the developers are not fully aware of the business, this should start with the discussion of the different user groups or personas.

Then we move over to the brainstorming of stories. Presented with the objectives and the user types, everyone gets to write their own stories. A tips here is not to push the user story format. When you make it mandatory, people will debate you, but if you instead say that you want to know not only what but why and for whom and that this is an excellent form for that, you get more in a story format. Don’t be afraid to see developers and operations as users. Some stuff you need for these groups too. And writing stories with yourself as user type makes developers learn how to use the format.

 

Grouping stories

After everyone has written their stories, I usually send two or three team members to the whiteboard to group the stories. I let them decide on groups.

After that we say the stories out loud. We select the stories we need, sometimes write some more and some of the stories are discarded after we explain why this is not necessary.

 

Highest priority

I then get everyone to mark on each story if it’s mandatory or not. Everyone get’s their saying.

We then sit down and I pick up the stories which at least one person said was mandatory. I then ask the following question about each and every story:

– If we don’t do this, the project will be worthless and unsuccessful?

This will make the number of mandatory stories much much smaller. When I was more junior as a product owner/project manager I thought the mere asking if the story was mandatory was enough. But the important question is if the story makes the difference between success and failure.

If a story is still considered as mandatory we look at the objective. And I ask the question:

– So, how will this help us reach the objective(s)?

A number of stories will lose their status as mandatory right there and then.

What is the first thing to do?

The next phase is to understand what we need to know where to start. If you have multiple sub groups, you should ask each group what they want to start with. Now the team often remember The Other Stuff, as development and testing environment, setting up build scripts and all that so be prepared for some extra story writing.

When every sub group has identified what they want to start with, they must say if they are dependent on another group to start with their first task.

If the groups depend on each other, use The Theory of Constraints to specify the priority. With that I mean that you should try to optimize the usage of the bottleneck resources.

Is this it?

This is an exercise which should be done regularly. As long as you have stories, you can focus on the next most prioritized items but you will need to go through all phases many times during a long project

The objective of the objective

Before I start a story writing seminar, I think it’s important that the participants know what is the purpose of the project and what is not the purpose of the project. I’ve never heard about a project where there is no deadline and money is not the issue. You must always focus on the right stuff to get the project to become a success.

So, what is a successful project? Well, I guess if it’s a project which meets the objectives. And to meet the objectives you need to complete the tasks which leads to forfilling that objective and you must probably try to spend as little time as possible on tasks which does not lead to the objective.

It is one thing to have someone tell you what the objective is. It’s a little better if you’re shown some kind of picture, but what ever the form; if an objective is just broadcasted to you, you might know it. But is it yours?

Mike Cohn has some interesting exercises for forming a project objective, but until today I hadn’t really grasped why I really found it so important that the team participate in these exercises and that you don’t simply tell the guys why we’re spending all this money.

When I presented the exercise, one of the guys frankly spoke out and asked why they were forming the objective and why the business folks didn’t do this. How were they supposed to know.

A very good question.

But when he said that it became so clear to me that what I really wanted was to know what they believed and thought. Everyone has their own picture and if they don’t tell what they think and believe, we cannot debate their idea.

So, out the window went the exercise and I simply asked everyone what they believed and thought. We listed all this input and then based on that we formed a simple Moore’s product vision for the project.

We then went back to the list and marked which items were mandatory to meet the objective and how they helped.

When we during the upcoming exercises formed user stories, we could really lean on those decisions. Both what was included and what was not.

One of the hardest tasks when you’re hosting a workshop is when people question your exercises. But if they cannot understand why they are used, you should probably not use just that one on that occasion. You should instead know what you wanted with the exercise and think if there is some other way you can reach that goal.

But the best thing is how much you learn about an exercise if they don’t go as planned. I’m even more confident in the relevance of a project objective, but the reason for formulating one in a story writing seminar must be clarified to the group.