Category Archives: article

Reducing Waste in Testing – The Problem

Testing is the most important part of any kind of software development methodology, but it is also the most neglected one. Nowadays, when an organisation does testing, it produces such a high amount of waste that the whole development process becomes very expensive, which makes it harder to win projects over the competition and risks the existing relationship with the customer.

When an organisation follows Lean thinking, then it is capable of finding and eliminating waste through Kaizen, which means more output with fewer resources: less expenses and more revenue.

Lean thinking does not bother with testing and technical details, it just gives you the idea and approach, the rest depends on you, and how you implement it. In this post, I’m going to share how I would find and eliminate waste created during testing.

There are different kinds of waste (you can read more about them here), but first let’s have a look at their consequences on the level of the organisation: wasting money, losing trust and revenue.

Most of the organisations work like this:

This is a quite common structure. A large company (the customer) outsources some work to a start-up company (the organisation), and provides services to somebody else (the external customer). The same roles appear at large multinational companies as well, where the organisation may be a division inside the large company.

Before going any further it is very important to clarify the two processes of testing:

  • Verification: what I implemented is working
  • Validation: I implemented what the customer wanted

Without giving any spoilers on the upcoming paragraphs, I can tell you that in nine cases out of ten, the root cause of the testing-related problem is the misuse of these processes.

Read more »

VN:F [1.9.14_1148]
Rating: 10.0/10 (1 vote cast)

How to Narrow Down What to Test

An old friend told me that they did not do automatic testing at her company, or any kind of testing for that matter, because in terms of money they are better off if they do ad hoc testing and bug fixing one week prior to the delivery date. Then I got into an interesting discussion where the topic was that the customer does not pay for tests, she pays for a working software. I was really surprised at the attitude of companies towards testing. So I had to find out what experts think, and at the end I found the following quote on stackoverflow from Kent Beck (more on the topic is available on hacker news):

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

This was almost a game changer for me, but then I remembered why I liked [automated] test cases in the first place. They give me confidence that my change does not modify existing functionality, and I don’t have to do manual tests repetitively. So I’m still good, and I learnt a new thing: when I talk to people about testing or work for somebody else, then I have to consider the time (money) factor, but in my own projects I’ll write as many automated tests as I can.

I have to admit that testing, especially using automatic test cases, costs a lot. This looks like an extra expense in short time, but saves a lot of trouble in the long run. Unfortunately, not every organisation is mature enough to realize this, or can afford to spend expensive coding time on things that have no value to the customer. Nevertheless, I know that deep down they want to do testing, so in this post I’m going to share several methods that can be used to find areas which are worth testing, so that companies do not have to spend more time on testing than what is absolutely necessary.

Read more »

VN:F [1.9.14_1148]
Rating: 10.0/10 (1 vote cast)

Kanban on Organisational Level

A couple of days ago, I talked to the head of an organisation, who was having a hard time to get an overview of the current work of her organisation, and struggling to have enough manpower in order to deliver products in time. This is a common problem, I had talked to other leaders who had the same issue, and in fact I was in a similar situation before myself. As a solution, we introduced Kanban on the organisation level.

The Problems

Before jumping into the middle, let’s have a look at the problems which triggered this introduction in my case:

  • Missing overview of the ongoing work items
  • Not enough manpower to deliver

Why is it hard to get an overview? It is a very good question indeed. Usually the head of an organisation – later on in this article I’m going to refer to her as leader -, has to deal with several things during the day, and it is very easy to lose track of the recent events, which may change on hourly or daily basis. Usually she only gets back into the picture when something turns south, but usually by then it is already too late.

In a healthy organisation, everybody is working on something, but for how long, when will it be finished, how much effort has been spent on it? These are also very good questions, and usually one has to dig quite deep in the organisation to find the answers. These answers are crucial for acquiring new work items into the organisation. Unfortunately, they are very often incorrect, and takes time to get them, so leaders take new work items based on inaccurate data, and then the organisation becomes overburden.

I truly believe that using a Kanban system can help solve such problems. Let’s see how.

Read more »

VN:F [1.9.14_1148]
Rating: 9.0/10 (1 vote cast)

The Calm Period

We are about six weeks after pimping my team – let’s see what has happened since then. A massive change is usually followed by a calm period. During such a period the team adapts to the effects of the change (new environment and methodology) and only small additional changes are applied, something like fine tuning. This is what’s happened in our case, and I think it’s worth sharing these small things.

The team moved to a different part of our landscape where we could try out a new seating layout. First not everybody was happy with it, but now everybody likes the place, and I heard someone advertising it to other teams. So far so good. Unfortunately, we weren’t that successful with the methodology and our way of working. We started to work on a poorly designed feature on a fairly complex code base, while we did not make ourselves masters of the Kanban + XP methodology. However, we tried to solve the problem with a slight change of the board and our way of working.

Previously we were using items, but after watching the Single Piece Flow in Kanban presentation, we started to use and talk about MMFs (Minimum Marketable Feature). We broke the feature down to MMFs and did a release plan.

Read more »

VN:F [1.9.14_1148]
Rating: 10.0/10 (1 vote cast)

Pimp my Team

Abstract

From the middle of January 2011, our organization has been working in a new structure. There were different outcomes of this change, one of them was that my former firefighting team has been dismissed, and so has the team introduced in my Kanban Nightmares article. This post is not about ther organizational change and its effects, but about the start-up of a new team in the agile world. I’m going to launch my first series of posts in which I’m going share – because sharing is good – the life of my new team in an agile perspective.

The title of the article is influenced by MTV’s Pimp My Ride series, in which talented and creative engineers are customizing cars. The team members and I are the engineers, and our way of working is the car. While watching the show, I got the impression that not every customization is necessary for having a well-functioning vehicle, but if I take away the fancy, unnecessary extras, the engineers are doing a damn well job. This is what we are going to do: customize our car, maybe a little bit too much, and after driving it a little, we are going to add new or remove existing extras in order to have a very good car. The show has the following chapters:

  • Introduction of the car owner, and her situation
  • Meeting, where the engineers discuss the customization – similar to a planning meeting
  • Assembling the car - short session about how the engineers are building the car
  • The showdown – the engineers present the car to the owner - explain what they have built and for what purpose
  • Test drive

Before starting the actual post, I would like to thank Daniel H. Pink and Olaf Lewitz for their insights on demo cancellation and rewarding systems, which topics will be presented shortly.

Read more »

VN:F [1.9.14_1148]
Rating: 0.0/10 (0 votes cast)