Arkisto: May 2010

Do the Work only once

31. Mayta, 2010 | Kirjoittaja: Antti Niittyviita

Teuvo the Tester is responsible for regression testing the end user product’s weekly releases. It is a damn boring job and takes up a surprising amount of time as well. Teuvo runs the tests according to the test specs in the Excel sheet and reports the results with either pass or fail. Teuvo naturally comments any discovered defects after the fail grade. In addition, any discovered defects need to be reported to the defect control system in the product development. The identifier of the bug report is then copied into the Excel sheet after the fail and then we are satisfied with the steps taken.

Last week, I noticed the headline: “10 tips for enhancing a business” in Kauppalehti. You can read those 10 tips in Visma’s announcement here. I found the text an excellent summary of making sense of things. I think that the most important tip in the list was the first one. The lesson is plain obvious to anyone who thinks: “Do the work only once.” But what does that mean, from Teuvo’s perspective?

After a typical fail, Teuvo spends

  • 5 minutes of work to confirm the defect,
  • 10 minutes go to investigate how to repeat the defect and for an impact estimation,
  • 5 minutes are spent to write down the defect in the test results and give details for what it results in,
  • 5 minutes is easily taken up by the defect database when registering the defect in it, and
  • 30 seconds are used to manually copy the identifier to the results sheet.

In total, Teuvo took 25 minutes and 30 seconds. Of this time, 5 minutes and 30 seconds of time goes to doing the work twice, which translates into consuming 22% of Teuvo’s work time.

Fixing the defect is a chapter entirely of its own. When the defect is in the database and no one has bothered to give it any thought in a week, what happens during Teuvo’s next test cycle?

Teuvo runs the tests as before. The same defect is haunting this test cycle, because the information from defect database does not reach Teuvo. 5 minutes are taken to run the test case anew and to verify the same defect. It takes 3 minutes more to update the defect database that the defect is also in the new release and that is has the same impact on the product. Suddenly, the same defect has caused extra work to a combined total of 40%. Of 150 hours of work time spent this way, 60 hours would go to doing the work again. I find those numbers quite daunting in both time and money.

Homework for you, dear reader: Try to figure out a similar scenario in your own project.

It is nice to showcase these grievances, but what about their solutions? How, for example, in Teuvo’s case one could have saved work time and target it in a more sensible way?

Our team has two mnemonics we follow:

  1. Make sure that the systems communicate with each other. When Teuvo reports the defect once, the report gets automatically copied to other systems.
  2. Ensure that the information has a backswitch. When the defect has remained undisturbed for a week, it also shows that way in Teuvo’s test control.

So, if you want more with the less: Do the work only once!

Goals and Own Goals

21. Mayta, 2010 | Kirjoittaja: Antti Niittyviita

At this moment, they are playing for the world championship of ice hockey. There are millions of people in front of their TV sets, either supporting their own teams or being otherwise interested about it.

The division of work of a hockey team is more or less the following: The coach decides who plays and in what role. The offense strives to score goals. The defense and the goalkeeper try to keep their own end clean. The team is playing for their fans, who co-live with the team. Fan pressure has been known to sometimes even cause coaches to be fired.

Scoring goals against the opposing team is most often successful only if the defense players support the offense in a meaningful way. A good teamwork with the offense and the defense makes it possible to have a greater number of different attack variations, increasing the chance to score goals. When a team scores, the entire team celebrates with the actual scorer.

Comparably, the purpose of the defense is to keep the puck out of the team’s own goal and it is impossible, if the offense is not interested in playing near their own goal. Typically, a goal scored by the opposing team is brought about by a risk taken at the opposing team’s end, meaning that the defense is helplessly late coming back to their own end to try and defend. A defense player is either a hero or a villain, depending on how that aforementioned scenario ended – a scenario, which could have been entirely avoided with a good five-player defense.

In order to go all the way, a team has to be well lead, and there has to be seamless cooperation with the offense and the defense towards winning. A successful performance is rewarded by the fans.

The above remains true for software development. A developer tries to play towards the goal, the tester tries to keep the own end pristine. Neither can succeed without the other. When the division of work is flawless, the end user appreciates.

There is no team in the world that can outsource successes to a single group of experts. A team solely playing offense is sure to lose.

Regarding the Role of an Expert

14. Mayta, 2010 | Kirjoittaja: Antti Niittyviita

Customer orientation and flexibility. Those two are values, which most companies of Finns advertise. The customer is always right. True enough?

This is what we have been taught, but let us think about it some more.

It is important to feel comfortable on intercontinental flights. It is even so important that the cabin has staff to ensure it. A passenger is brought a blanket, slippers, movies, or even served drinks. They even go as far to mix drinks that baffle the imagination. They also serve food, be the customer a vegan or a barbarian. Customer oriented, I say.

But what if a customer reaches a conclusion during the flight that he or she knows best how to reach Los Angeles from Sydney and demands that the pilot alter the plane’s flight altitude? Or if the flight path should be changed to make a stop at New York, according to a wish by a passenger?

The pilot will not even consider fulfilling those wishes. The pilot follows the flight plan he had planned, because it is the most functional with that plane type in those circumstances. Besides, the weather service has informed the pilot about a cloud of ash in the sky. The pilot is the expert of this story, the guru who knows what is the best way to proceed in this situation.

Suddenly we don’t need flexibility or customer orientation. As long as the passengers reach their destination safely and on time. That, if anything, is the role of an expert.