Over the past 50 years, quality and optimization have bloomed into a mature set of practices that are now leveraged in almost every industrial and manufacturing environment. Six Sigma and TQM are just two good examples for such practices. In manufacturing, unlike software development, the relationships between project schedule, component quality, and order of assembly are clearly defined and optimized (i.e. unnecessary motion is reduced.).
For team working on an automotive assembly line, the practice of stretching deliverables to the extent possible (so long as the assembly line continues to move) is legitimate. Unfortunately, this is not the case in software development.
As product development evolved from mechanical devices to complex software packages, some previously benign scheduling habits have become vices. One such transgression is the practices of the “Schedule Chicken”. And no, this does not refer to the cafeteria’s daily practice of serving charred poultry. The origin of the term comes from 1950’s and has been documented in the movie Rebel Without a Cause. In it, two drivers are racing their hot-rods and are supposed to jump out just before their cars go over the cliff.
The first one to jump out of the car is labeled a “chicken” while the one closest to the cliff’s edge wins bragging rights. From the psychological point of view, it is interesting to note, that the rational for the “Schedule Chicken” behavior is related to the Hawk-Dove method of conflict used by players in game theory. The software development equivalent of this occurs when two or more areas of a product team claim they can deliver their features at an unrealistically early date because each assumes the other team is stretching the predictions even more then they are.
This pretense continually moves forward past one project checkpoint to the next until just before the functionality is actually due. The more mature “Schedule Chicken” practitioner will often delay addressing the obvious for as long as possible, hoping that someone else will hit the breaks and stop their car first. The ceremony in which the team lead finally admits that he can’t deliver the features on time climaxes in a primeval ritual that is reminiscent of ancient Aztec human sacrifices, albeit it’s somewhat more painful.
In the end, it is very difficult for the failed team to recover from being behind schedule, because once the truth is out, all other teams will blame them for the delay. Even if they actually do end up beating the deadline (which is highly unlikely), it will be forever impossible for them to remove the associated stigma of having been “chickens”
So how do you combat the chicken? Here are my top indications that your project has possibly been infected with an avian flu:
- 1. While discussing the production schedule people use terms like guesstimating and SWAG
- The proposed schedule is not based on a documented matrix of previously developed products
- In private conversations, cross team members challenge the validity of their own schedules
- The team hopes to make up for lost time by adopting silver bullet tools or technologies
- The amount of code necessary and it’s complexity do not match available development resources
- Failed smoke tests, quality of builds, and bug bounces do not match the published status reports
- The team is opting to build low level functionality rather than buying it and is insisting that this will actually help accelerate their delivery
- Development teams are regularly burning the midnight oil, are putting an exceptional amount of overtime and appear to be worn-out
- Project stake holders are starting to use e-mail for the creation of a “legal trail”
- Team leads are showing compartmentalized understanding of the project and are unable to walk through all of its dependencies (for example, they may be insisting that it’s not necessary for them to thoroughly understand other team’s implementation details or how the entire solution is going to work)
- Project leadership continues to commit itself to unrealistic deliverables like “zero critical bugs” or significant performance improvements, despite having priority bugs and stability issues.
The practice of Schedule Chicken may seem harmless and in some cases may even be encouraged because it promotes survivalist behavior, but in fact, if left unchecked it can have long term devastating psychological effects on the entire team and its ability to develop efficiently.
From my experience, the best mechanisms for combating the chicken are to demand open and honest communications, insisting on peer reviews, and maintaining deep visibility into all project activities.
This is not a simple task as it may goes against the grain of the entire organization but in the end, it beats the alternatives of failure and the blame game.
© Copyright 2010 Yaacov Apelbaum All Rights Reserved.