Becoming agile

Agile, through the storms

Archive for the tag “DRY”

06 Dec 2012
8 Comments

A piece of cake. A huge piece of NIH cake

This is so tempting to start something afresh, something that only we will use, so it fits our needs like a glove.

It is so tempting because it seems so easy to develop exactly what we need – it must be a piece of cake to custom build it for us.

And of course what exists out there does not serve the purpose well enough, simply because it was NIH – Not Invented Here.

Image by http://www.flickr.com/photos/rabanito/

So here are ten reasons NOT to develop internally what exists off the shelf:

1. It is already tested by more customers

2. You enjoy from features you didn’t think of; you will enjoy future features you cannot imagine today

3. You are good at what you do business wise. So why try to become proficient in something other organizations are already experts in?

4. Conversely, by investing in existing tools you produce less of what you are uniquely good at

5. Once you deploy your tool you will need to maintain it, making even less of what you are good at

6. When you or the market evolve you will need to expand also the tool – what tool providers do anyway for their own survival

7. Changing the tool becomes much harder. For starters, the tool will be someone’s “baby”. You might also find that you need to lay off really good people to replace it, turning decision making harder still.

8. People always blame tools. Always. It is easier to defend a Rolls Royce or a Chevy than it is to defend a home made cart

9. Some tools (not yours!) are crap for real. It is easier for someone to admit that they’ve bought a piece of crap than to admit that they are making crap.

10. Think twice and thrice before you reinvent the wheel. If you are already making the Rolls Royce of your business, why service it with second grade tools?

What is your view? Are you developing tools that are commercially available?

Posted in Agile, Quality and tagged , , , ,
21 Aug 2012
4 Comments

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

Posted in Agile, Quality and tagged , , , , , , ,

Post Navigation