The situation
“Your organisation is using Scrum for software development, right? You must have heard of Scrum ceremonies like the daily scrum or the daily stand-up. Now, the Scrum Guide recommends three questions – what did you accomplish, what will you accomplish and any impediments – to which each person must give their status. However, as long as you are sure you can get the answers to these questions in spirit, you don’t have to insist that each person answers these exact questions! The idea is to know where you are and to set the context for that day’s work. Any method of achieving these outcomes in the daily scrum will do.”
He continued, “Now, if this process of holding the daily scrum with these exact questions becomes more important than the outcomes, then you see a manifestation that flashes amber.”
The challenge: What is the amber signal (or issue that can become a major problem later on) that you see here?
Clue: Tying a cat to a pole during anniversary ceremonies.
Suggested Solution
The amber signal we see in the situation is that ritual has become more important than the reason behind it.
One of the main issues we normally see in development teams see is a lack of knowledge of the product. It is important that all organisational staff, engineers especially, have a good knowledge of the product, its vision, its architecture, etc., in addition to the nitty gritty software aspects of it.
A lack of knowledge of the product and market – is where a problem lacuna obtains in the organisation’s customer outcome focus strategies. If you really are not sure of what the market wants, how will we provide the right experience?
Before engineering teams do something, develop a piece of code, or implement a new feature, it is important for them to know why they are doing it, and why and how it affects the customer and the end user. The way they code it will affect subtle nuances of the user’s experience. And if they know what experience the customer is expecting, they can code it accordingly, rather than ritualistically code something that works, but does not have the ‘feel’ in it.
Unfortunately, many a time, ritualistic coding is exactly what happens. Some of the engineering teams routinely add some pieces of code or a feature because it has always been done that way, or because it has been done for a particular customer. The customer for whom this is being done may not even need this feature or code.
This whole process could have been handled much better if some of these teams had a good understanding of customer outcomes – expected output and right experience.
This is the key to the success of Agile teams.
Illustrative Fable
There was once a priest who lived with his sons in his native village. Every year, he used to conduct a sacrifice to propitiate the goddess of learning. This was a pretty long observance and took most of the morning. The priest had a cat that used to come and disturb him during this observance. He was angry and so tied the cat up in the pillar near where he was sitting in front of the sacrificial fire. To keep the cat from whining, he gave it some milk to drink. After the sacrifice, he untied the cat and let it go.
When his sons grew up, they saw their father tying up the cat, feeding it milk and letting it go after the ceremony. The sons decided that this cat-tying-feeding-releasing was part of the ritual of the sacrifice. It did not occur to the sons to ask their father why he was doing this.
So, this cat ritual became part of this sacrifice ceremony and was handed down through the generations.
