Becoming agile

Agile, through the storms

Archive for the tag “Quality”

05 Apr 2012
1 Comment

On the merits of rituals

One moment before Passover start. This photo is probably meaningful to most of my readers. Come Passover, all food that contains, or is suspected to contain, flour and yeast is to be removed. At the workplace in many occasions it is simply covered up to avoid accidental use of such food products. At home, the religious practitioner will meticulously clean the house until all crumbs are properly removed from the house.


There are disputes as to the essence of this activity. Many seculars see this as a futile exercise. Atheists may see this as nonsense. But for the religious individual and family, this is part of the essence of being Jewish. Make no mistake, for the Jewish religious practitioner, Done is Not Done if a minute piece of Khametz, bread, cake, or even plain flour, is not taken out of the house well ahead of Passover.

As for these vending machines: Someone has to remember to take care of all the Khametz before Passover, and all the items that must be handled for this. The coffee jars, the cutlery, the bread baskets, the refrigerators, and even the vending machines.

It takes years of experience to remember to cover everything, and to develop the routine to recall and attent to everything.

And yet, when staff changes, nothing it left forgotten. Part of the routine is its craftsmanship to ensure that this is not dependent on one individual or another. Instead, it is the responsibility of the maintenance team to ensure that everything is taken care of, year after year.

Immediately after Passover, the regular coffee jars will be returned, the refrigerators will be filled with Khametz all over again, and the vending machines will also not be left unforgotten, and will be uncovered.

What are the rituals that you already do, and the ones that you wish you had, in delivering new software? What is not left forgotten even if you do it only once a year? What are the things that you tend to forget, but are important for you?

What will you do this year to get the rituals into the organizational rhythm, so you do not forget it next year?

Happy Passover, Happy Easter, Happy holiday season to all

Posted in Quality and tagged , , , , , ,
09 Dec 2011
5 Comments

Built for Endurance

You just need to take a look at a crocodile, to see that this species goes back to prehistoric times. Same goes for the Komodo Dragon.

Source: http://en.wikipedia.org/wiki/Komodo_dragon

How come these creatures have endured so many thousands of generations? This will be part of the talk I will lecture on at the Agile Practitioners 2012 conference. I believe that the reason for the success of these creatures is that they are built (so to speak) for endurance. The single value, if you can call it that, that unconsciously guides these lizards to propagate, is to create successive generations that will succeed to produce further successive generations. A pretty Darwinist view, no doubt.

What has this to do with software organizations and agile, you might ask?

Many organizations declare mission statements, and values, and vision. This may come as a paragraph of text, a few bullets, or words:

“Our goal is to dominate the <Paste-Your-Business-Here> market”

“Provide superb customer experience”

“Low prices always”

What would be an adequate value for a software organization? In my view, Built for Endurance” is a worthy goal. Something that can permeate throughout the company.

A few examples:

What would be the effect of adding a 4th question to the SCRUM daily standup: “Is this sprint Built for Endurance”? What would that do to the team’s quality targets? Will surrendering to external pressure to deliver bring the team closer or farther from this value?

What would requirements look like, if the Definition of Done will include the statement: “Built for Endurance”? Will this guide the Product Manager/Owner to require better tests in the criteria?

What would the sales organization sell to customers, if they sell solutions that are “Built for Endurance?”

How about Human Resources? What would attrition rate be, if HR is called to support a work force that is “Built for Endurance”?

In my view, quality is very much about endurance, and very little about testing. If your quality organization relies on testing, you are probably trying to prove where your product and process is not endurable. If, however, you wish your products to be endurable, try thinking about the earliest point in the process to take this into consideration.

Where would you start? I will share some more insight about my talk in the coming few weeks. I will also be happy to hear from you about your ideas.

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

Post Navigation