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:
- 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”) - 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
Becoming agile 
Although I have my own personal opinion about Agile – I don’t think the methodology should be blamed in this. I think the problem really lies in the fact that there is no iterative and continuous quality control on the code. If there is, then these messages will be unified.
However, if Agile does not allow for a time to build the infrastructure necessary to standardize the system messages, then I think, at this point, the problem really likes with Agile. Any methodology should take into account code reuse – at least in the same project!
I agree. Agile is not an excuse for not doing things right.
When practiced correctly, such incidents are expected to emerge earlier compared to traditional software development – as was the case in this example.
Early, frequent reviews with the product manager helped uncover this fault early in the development of this project.
There is no place in the manifesto or the scrum guide says that you should not build any infrastructure. All it says is that don’t over do it since you need the infra structure after come period.
It clearly says, you need to do whatever it takes to complete the task. If you require to build the infrastructure, start with the dot. then expand it iteratively.
We are on the same page!
I like the dot analogy, thanks 🙂