Becoming agile

Agile, through the storms

Archive for the tag “Acceptance Criteria”

Spot the Differences

Everyone’s talking about agile. This is the hype in software development process – the fashion, the Mode. It is so much in the Mode that we sometimes forget that our purpose in life is to produce quality, endurable, appealing software. Scrum, or any other agile framework for this matter, is a means, not a goal in its own right.

A friend gave me permission to share this image with you: Can you spot the differences?

Let’s hypothesize what has happened here:

  • Two error messages were displayed in a very different fashion. Why?
  • Because they were introduced by two separate developers. Why?
  • Because one is technical and the other is more business oriented. Why does this matter?
  • Because there was no one shared mechanism for messages for the user. Why?
  • Because it had to be finished within the same iteration. Why does this matter?
  • Because in agile there is no time to build such infrastructures.

Is that really so?

Scrum is no excuse for technical mediocrity. On the contrary – it is an opportunity to improve, based on two major features of agile:

  1. Scrum does not introduce problems. It exposed them. In this example, this is an opportunity to deal with such a scenario now rather than later. In a traditional project, such a failure can also occur. An iterative-incremental process helps here on two ends:
    – The feedback loop is much shorter
    – A sustainable solution, such as a framework to display messages, can be introduced in the next sprint, rather than the too-well-known “We will deal with it in the next version” (also known as “It will never happen”)
  2. When the team encounters similar tasks, they should identify that they fall into the DRY – Don’t Repeat Yourself, category. When you find you are doing something repetitively, such as forming a message box time and again, this is a good time to make it happen in one place. It may cost an extra hour in the current iteration, but it will save dozens of them in maintaining those messages, should you make general changes to them.

If you are one of the agile-skeptics, I strongly recommend you take a course to learn what it really is about. Especially if you are working in an organization that practices agile – you might be doing damage not only to the organization, but also to yourself. So next time you encounter such an agile-makes-things-worse moment, think maybe it is not agile who is not up to scratch, but your knowledge of it

Post Navigation