blog.fossmo.net

Have you ever experienced how pacified you can feel when a co-worker takes control over your keyboard and mouse? It feels like he or she is intruding into your personal sphere. You might have asked for help, but not to be invaded. It's strange to think of how much "power" the person controlling the mouse and keyboard has. If the person holding the keyboard and mouse isn't aware of the "power" he or she got, and don't bother to include the other person, it's likely the person falls into a apathetic state just watching the screen, and not focusing on how to solve the problem.

When doing a sprint planning you should avoid using a electronic storyboard. My experience is that you end up with one person, probably the scrum master, running the whole show. The other team members will probably sit pacified looking at the screen. Doing nothing, or in best case trying to participate but not being able.

You should rather use a story board hanging on the wall in your office. Perhaps a whiteboard or maybe a board made of gray paper. And Post it’s, of course. This way everyone can participate in the process of adding tasks (and user stories). This promotes cooperation and builds team spirit. Everyone can have hands on experience with the process. It builds understanding for the problem being solved. It lets the team work more in parallel. While one team member is finishing writing one task (or user story), another member can start with the next task (or user story). I'm not saying that an electronic story board can't be used, but you should have very good arguments for using it. It's to pacifying!
If you disagree, remember one of the statements in the agile manifesto; "Individuals and interactions over processes and tools".
What is your experience with electronic story boards?

Tags: scrum

Everyone is into TDD these days. Right? If you want to call yourself a serious developer, you need to write unit tests. Blogs and seminars are filling your head with: "TDD or loose your night sleep". "TDD or write tons of documentation". "TDD or have a crappy design". I could go on forever...
Developers are eating this information provided raw, looking for the silver bullet.

"Everybody is doing it, so I have to do it too".

I guess if you are a teenager, this is a very valid argument. It's hard to stand out of the crowd at young age. Just follow the rest and everything will work itself out.

But, your not a teenager, right?

I guess what I'm trying to say is; look into the pros and cons before deciding to start using it. Read some scientific research. You have a much better chance of succeeding then, as everything else in life.

I posted a question on an up and coming Q & A site called Stackoverflow. I asked if someone could point me to some information about scientific research done on TDD. I got one lousy answer and the guy answering just goggled for the answer. No one knew. I find this a bit disturbing. A lot of people throw themselves into TDD head first. Doing this was okay 6 years ago, when TDD was in its modest beginnings. But, not today. You can find a lot of scientific research on this area this days. Try goggling for it.

Does it really matter if you don't know of any research done in this area?
Probably not. If you really enjoy something, the chances are that you are good at it, and you should continue doing it. Blissfully ignorant. On your home projects. But, if you have swallowed the red pill and want to expand your use of TDD from your hobby project at your basement, and into your organization, you should know something about the research done in this area. How can you put up a good argument for TDD if you can't referee to good sources?

It's like going in to a wage negotiation with your boss and say:
"I want a higher salary!"
"Why?"
"Because!".
"Because, what?"
"Because!"
"Get out of my office!"
"But...."

This won't get you the 50" wide screen TV you always wanted, for sure!
You need some hard facts. A good starting point are these papers:

http://users.csc.calpoly.edu/~djanzen/pubs/janzenTDDSoftware08.pdf
http://iit-iti.nrc-cnrc.gc.ca/iit-publications-iti/docs/NRC-47445.pdf
http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf

Tags: tdd

"When in Rome, do as the Romans do!"

This is a old saying. It was first said by St. Ambrose who was the Bishop of Milan over 1.600 years ago.

In Rome they fasted on Saturday. When the bishop of Rome visited Milan, St. Ambrose was asked why they didn't do the same in Milan (I guess a bit condemnatory). St. Ambrose then replied:
"When I am at Rome, I fast on a Saturday; when I am at Milan, I do not. Follow the custom of the Church where you are."

Later this was changed to "When in Rome, do as the Romans do". The meaning of this, in a developer context, is that you should adapt to the environment you are working in. Do as the others do.

Well, enough with word origins. The reason why I referee to this origin is that I don't think it always is a good idea to follow it.

Have you ever worked with people who uses this phrase a lot:
"We have always done it this way, so why should we do it any different now?".

It's probably the same guy who says:
"Why do we need to write unit tests and use continuous integration? It only slows down the development. Let’s just do it the old way, we are getting it done this way too."

This guy is probably right. He will get the things done, but he will use a lot more time because he will spend a fare amount of time in the debugger hunting for bugs. Probably this is the guy who creates a new solution every time the product needs to be extended, because he is afraid of breaking something. He doesn't  have a safety net.

This brings me to the point of this post. If you are a consultant or a permanent employee, you should not always follow what is done in the company you work for. Maybe the way things are done, isn't the best way? You should try to change this. It's your obligation as a responsible developer. I'm not saying that you should start a revolution. You should be critical, but understanding. Try to convince your co-workers to start using continuous integration if they already aren’t doing so. Get them to start writing unit tests. I guess the best way to go about this is; Show, don't tell. If you start writing unit tests and using CI, the co-workers will see the advantages of using these techniques. After a while they also want to start using it. I'm just using unit test and CI as an example, there are lots of other ways to improve. A starting point can be one of these books: The pragmatic programmer, Code Complete or ShipIT. 

If you are the one fitting the above quotes, you should cut your co-worker with the new ideas some slack. Give his ideas a shot; it may lead to something wonderful. If you’re the one with the ideas; don't give up after just one try. Talk about your ideas. Find some hard facts that support your statements. Be enthusiastic and passionate. 

Tags: thoughts

In many projects I have been working on, I often have seen that it can be problematic to get the product owner to create users stories with business value. The product owner understands what he or she wants, but forgets to focus on what is important to the business. If you run into this in a project, you should tell the  product owner that he or she never should create a user story that have no business value.

If the customer find it difficult to get the userstories down on paper, a pattern like the one below can helpe the product owner (or also the team) to get started: 

As a ROLE I want to ACTION so that BUSINESS VALUE (IS MEET)

Every user that interacts with the system should be put into a ROLE. Roles can be a user, a administrator, a report viewer and so on.

The ACTION is what the role is doing to the system.

The BUSINESS VALUE shoud be something that gives value to the business (or at least value to something using the system).

Here is a example of a user story that contains a business value:
As a user I want to log in with a password and a username so I can buy a Ipod.

And a example of a user story that probably doesn't contain any business value:
As a user I want to click a button so that the background color changes to green.

The last example does not give any business value to the customer and shoud never be added to the backlog in the first place. If the product owner later wants to add this story, it's ok, but it should be proritized last in the sprint.

Next time you are doing sprint plannig you should try to follow this simple rules, and I think you will end up with less features to be done in the sprint and you also will give the customer a application full of business value.

Tags: scrum

There's a lot of bloggers posting about something called the Circle of Interest. I was encouraged by Gøran Hansen to post my Circle of Interest. The main idea of setting up this circle, is to show what you are focusing on at the moment. Circle of Interest was started by Paul Stovell. Other people I know posting on this is Jonas Follesø.

Gøran has a good description on what a Circle of interest is over at his blog.

Tags: circle of interest

I just read a very good article about how to create a loosely coupled application.
It's written by James Kovacs for MSDN magazine.
It's named "Tame Your Software Dependencies for More Flexible Apps".

Link to the article is found here: http://msdn2.microsoft.com/en-us/magazine/cc337885.aspx

Tags:

If you think my posts are ridiculously bad or if I, in a stroke of luck, posts something interesting, don't be afraid to give me feedback. One of my ground philosophies are that most of us can't improve without feedback. If someone does a good job, let's say at work, it's very important to tell them. Likewise, if someone doesn't do such a good job, they need to get that information to improve. Negative feedback, of course, need to be told in a more gentle way.  Don't just go up to a co-worker and say: "Your programming skills suck!". Try to be constructive and tell him/her what he/her needs to focus on, but don't shade the problems. Be honest.

I like to focus on positive feedback. If you work in a project team, the best way to get people more inspired is to tell them they are doing a good job.

Finding positive things to say, is often more difficult than finding negative things. In a project I worked on, we were told to sit down and look for positive and negative sides about how our team worked. We found a lot more negative than positive. When I thought about the team and the work a bit later, I came to the conclusion that there were just as many things that were positive as negative. Even more positive than negative stuff. I think it's easier to focus on the negative things, so I guess we have to put a little more energy into finding positive things to focus on.

If you want to build a better team or get people to do their best, give them feedback. Mainly positive.

I guess one of the most valuable characteristic a person can hold, is the ability to take feedback and filter out what's constructive and then adapt to it.

A person I worked with, had low self-confidence and lacked interest, to a degree, for the project we were working on. He was given feedback, mostly positive, and after some weeks he was one of the leading developers in the project. It was a real nice experience.

Please help me improve my blog by giving me feedback!

Tags: