Tag Archives: continuous integration

Make the Customer Try Out Your Product

I’ve been participating in demo meetings with customers and product owners for years now, but we seldom talked about interesting things or rarely made significant decisions during these meetings. There can be several explanations to that, but I’m pretty convinced that we were doing these meetings wrong. The chart below depicts the categories help you understand why I think this way. Here are the content of the user stories brought to the meetings:

The figure represents quite a typical progress, nothing is wrong about it at first sight. Let’s add to the picture what has been discussed after each sprint during the mentioned demo meeting. For example, during the demo meeting of sprint 3, we mostly talked about user interface (UI) issues and only a little about functionality:

In most of the cases the team presents a subset of user stories during the meeting, and the customer just sits there – because it is a presentation after all – and has a couple of comments on the user interface of the product. Sometimes, they talk about real functionality, but that is not enough. Everything is just fine until the product is released or delivered for system testing:

This is the point when the customer really “enters” into the “functionality” section and even into the “non-functional requirements” section and starts using the product. What happens now is a disaster, because

  • the delivered software works differently than it is supposed to work
  • nobody really remembers how to use the product
  • it doesn’t meet the performance criteria

I think everybody has been in a similar situation who is doing Scrum. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (2 votes cast)

Saving the Continuous Integration

I really like continuous integration, that’s why I’m always sad when I see one dying. Unfortunately, I’ve seen it happen a lot, and in every case its lifeline looked like this:

The introduction of the continuous integration is usually started by an enthusiastic team member who read about it, realized “it was cool”, and it was just what the team needed. She quickly affects the whole team, they set up the build servers and are really happy with it.

The first fracture happens when the first unexpected failed build appears on account of a test case failure. Nobody knows why the test fails, because it works locally, also works on the server, but mysteriously sometimes it just doesn’t work in either of these places. The team is aware of the phenomenon, closes the case saying “don’t worry, we know that sometimes it fails” and moves forward. As time goes on, the team adds more test cases, and another failing test case appears on the horizon. Mysteriously, just as before. The same decision is made, because a team can live with two known failing test cases, can’t it? Unfortunately, this question signs the death sentence of the continuous integration build, because failing test cases decrease the faith in the system, and team members will start ignoring the results, because they are not trustworthy. Criminologists call this phenomenon broken windows syndrome:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside. (source: wikipedia)

Occasionally, some of the team members pull themselves together and decide to “fix the build”. They might even get management support. Unfortunately, the broken windows are more powerful than them: while they are desperately trying to fix the test cases, other team members are going forward and building software based on an insecure base and creating more failing test cases: the broken windows are working behind the curtains. At the end, only the initiator checks on the build, because everybody else has already given up the fight with the windmills. This is the end of the continuous integration for the team: “flatline”.

For me, sporadically failing test cases are like diseases, and should be handled accordingly: until it is not known what the problem is, they should be separated from the reliable (healthy) test cases. If a team relies only on reliable test cases and keeps the unreliable ones in a test quarantine, then the team won’t lose its faith in continuous integration and it can live and support the team. Let’s see how to set up a test quarantine. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (2 votes cast)

When Expand and Collapse Got Beaten

Today’s post is an instructive story about mixing various good patterns and ideas. They are very useful separately, but when one uses them together, they may lead to problems which nobody wants to deal with at all.

We found several different defects in a certain feature, and in order to reduce handover costs I collapsed them together to make an “umbrella defect” (defect1+defect2+…defectN) and put it into our Queue. When my colleague started to work on it, I was quite happy with the result: less handover costs less context switching and more focus on a faulty feature. It was really nice until our deployment day came. Or Kanban board and version tree looked like this:

The mentioned umbrella defect appears as ‘UD‘ on the Kanban board, and it covers ‘UD1.1‘ and ‘UD1.2‘. Based on our Kanban board, there is no impediment to the deployment, but right before the deployment we realized that not everything we wanted to deploy had been tested since we were using one-track. One-track means that we don’t have branches, labels or tags, we just have the trunk where we have our latest version. One-track is an excellent thing, but it seems that it doesn’t work well with collapsing.

Read more »

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)

Weekly – CW18

I’m still a bit busy, but nevertheless here is the collection for calendar week 18, 2011:

  • Most of the agile articles are about success and good things, which makes the whole agile initiative a bit mythical. Therefore I was happy to read an article, which makes the whole thing a bit more realistic: Jacub Holy tried to refactor  a huge class from Hudson. Although it is not a success story, it is a good reading, because there several good ideas and takeovers in it.
VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)