Agile - Ant and Lion fable

Ant and Lion story:

I am not the creator of this story. I got this as an e-mail forward. There are many things I can relate to with respect to process inclusion in organizations. Before I blabber a lot let me write the story. There is a link to the story in slide share. Ant and Lion fable

Lion was the king of jungle. There was an ant in the jungle which arrives to the work early everyday. It will start the work immediately. Ant will do the work without any supervision. Ant was also happy with the end results of her work. Lion observed this and started wondering if the ant can do so much work without supervision how much it will be able to accomplish with a supervisor?
Lion hired a cockroach who claimed to be a good supervisor. Also cockroach was very good in preparing reports. Cockroach was working in a big organization. It decided to implement a attendance system with time. Cockroach also wanted a secretary to type his reports. He hired a spider to archive the documents and attend all the calls.
Lion asked the cockroach to produce graphs and trends. Lion wants these to present in board meetings and use it for increasing the sales. Cockroach bought a computer system and other supporting devices for this. Then cockroach hired a fly to manage IT department.
Now with so much of paperwork and meetings ant was not doing her work. Her time was spent in paperwork and meetings. Lion felt there was a need for department head where ant is working. Lion appointed a gross hopper as dept head. Grasshopper bought an ergonomic chair for himself. He also got a computer and an assistant to help with budget and optimization plans.
With all these going on Lion saw a report which saw decline in productivity in the department where ant is working. So he asked an owl who is a very reputed consultant to carry out an audit. Owl did an enormous study and gave a huge report. Its conclusion was department was overstaffed.
Now the lion fired the ant. Reason being there was lack of motivation and negative approach towards organization processes.
This is what happens in some IT organizations also. In startup mode people are happy to work and without monitoring deliver. Then there will be some missed deliveries and bad quality projects. Management brings in quality experts and process experts. This is where things start to go bad. Instead of building quality in the product it becomes another department. Responsibility for quality is with another department. It becomes a fight between departments. You need more reports and more time in preparing those. It always results in quality going down. There is a say if you cannot measure it then you cannot manage it. I agree with this. But most of the time measurements asked by the departments does not help to improve the quality. They only result in spending more time with applications for logging defects and marking them as fixed and reviewed.
All developers want their work to be used well. It applies to everything I do. I do not want to spend few hours on something which is going to garbage or will be in cold storage. Any measurement to be useful should consider this fact. If the measurement will help the end result of the product then development team will not hate spending some time logging the data required for it. If it is for some report for some guy in top management I am not ready to spend my time for it.
This is where I am going to tell agile is the holy grail :-). Agile lets teams decide what process is required. This helps them decide what measurements will be good for them. Since they commit to these they do not feel burdened by these.
What will be the measurements which will help team and organization?
Burndown (team velocity)
Backlog
Fail ratio of automated tests.
Success/Failed builds
Test coverage.
Customer satisfaction with sprint release.
There are many more. But if you look closely team does not spend lot of time in these reports. It is part of the routine work. Burndown is measured during daily standup meeting. This is not an extra effort. It is required for successful sprint. All other are automated. They give a very good measure of how things are going.
Quality is responsibility of the development team. Delivering good software is wish of all team members. Just let the team do their work. Do not distract them. It is a win – win.