Pseudo Scientific Management Kills Innovation And Creativity
Numbers in the form of metrics are dangerous. They can become a two-sided sword and despite their usefulness collecting them can backfire on those who collect and publish them. Agile teams frequently show big visible charts on the walls of their team space. The intention is to be transparent and let everybody know what gets achieved and where the problems are.
One of the XP values is Communication. There are many ways of communicating within the team, and with people outside the team. We generally prefer conversation for most purposes, but when it comes to trends, history, or sensitive subjects, a good approach can be what we in XP call a Big Visible Chart, or what Alistair Cockburn (Agile Software Development) calls an Information Radiator. A simple chart on the wall can bring important information to the attention of the team, the customer, and everyone else who passes through the area. The chart can provide important information, even politically sensitive information, without getting personalities involved or hurting feelings.
As long as everybody understands that this data is to be used to improve and is not a means to re-introduce scientific management all is fine.
I myself participate in this shift as I include lean flow management, queueing theory, Yesterday’s Weather and the like in my lectures and classes .. and worry the entire time as I do so. I add chapters on craft, creativity and personalities, not as compensation, just as part of the mix. I don’t see others putting those into the mix.
I have knowledge of a large development organization where this very transformation back from open and honest agile practices towards scientific management has already started.
Initially this organization used the common practice of relative sizing of user stories. Story sizes were expressed in points using a fibonacci scale (1, 2, 3, 5, 8, 13). They use a sophisticated issue tracking tool that is available for every team member. All user stories, epics and features are tracked in this tool to make sure that there is good traceability so that it is possible to see how requirements were developed.
After a while management discovered that it is difficult or impossible to compare the performance of teams with each other. First they were trying to encourage teams to estimate the “same things” in the “same way” hoping that by soft pressure the numbers would become comparable. They instructed lower ranking managers assigned to each team to help with that.
A while later a big change was made and now relative sizing has been abandoned. One point now is seen as equal to one day per programmer pair which equals to 6 hours per person. They still use the fibonacci scale and explain that by using fibonacci they take into account that for larger estimates (which are now in time) the lower accuracy of the estimate has been factored in.
At the same time the organization wants to define a standard set of tools that should be used by every programmer and tester. They actively discourage or even prohibit the use of non-approved tools thereby killing exploration and personal growth of their employees towards becoming good craftsman.
In my opinion this leads to a culture of fear and in the long-term will kill innovation. How can innovation happen, if all the paths of exploration have been closed except a pre-defined one?
Plus the organization risks that their employees will perceive the message this sends as being “just do what you’ve been asked to do”. Many software developers derive a big portion of their motivation from personal satisfaction and pride of workmanship. This kind of scientific management does not leave room for that as the core principle is that everything is made comparable by simple numbers.
| Previous | 20 May 2011 | Next |
This article has been posted to social media sites. There might be comments. Just follow the links:
