Through out my software development career I have been trying to understand how things work, actively pursuing the thought processes that people use to make their decisions. I spend time asking questions about the hows and the whys of what I am asked to do and produce. This action, over time, has produced a decent picture in my head of how software development should work and in many ways how it should never ever work. I have been able to understand the whys of certain actions and requests but the one 'action' for which I have yet to totally understand is the idea of software development "Date Chicken".
Date Chicken as I would describe it is the propensity of an organization to want to assign a date to a project without understanding or going through an understanding of the complexities around what has been requested to be developed. Date chicken comes about due to not having enough of the discovery executed such that any date that can be provided has to be provided with a long list of provisos and comments/risks about what in the world at large has to line up "Perfectly" in order to meet the date that is being published. So software development teams are asked to produce these "Plans" that indicate that we can meet the date IFF (If and only if) everything else in the world happens perfectly. What happens next, every other team produces the same sort of statement about their ability to meet the date and the fun begins. Management from each team begins to execute on the "PLAN" that has been produced, they organize teams, and instruct people on what needs to be done and they wait patiently for the first 'date' on the plan to come up.
Here the Chicken part of date chicken takes over. Basically the teams continue to plod along towards the date until that first date arises and a team has not produced the things that they 'said' they would produce and everyone else involved in the project gets to point out that 'their' dates will have to slip day for day with every day missed in the development team at the front of the train. Hence the 'Chicken' in date chicken.
Why is this so hard for me to understand you might ask - every software company of any size seems to do this...
Its difficult for me for the following reasons:
1) The date is a lie, perpetrated by someone else and then taken as gospel, which leaves me feeling like my management doesn't want me to tell the truth, ever. Ok - the date is not entirely a lie - because there is an OFF chance that the needed software shows up on "time" with high quality, but so far I have yet to see that happen when this game of date chicken takes hold.
2) Because the date is a lie everyone 'RUSHES' to turn out the thing that they were on the hook for before their date arrives. In turn this produces software of lessor quality, with production issues, that turns out to be hard to manage and maintain.
3) #2 causes our customer experience to essentially suck, driving the customers to complain or look for service else where, making my company look like the best of the worst.
I do understand that sometimes the date is important, there might be legal reasons or contractual reasons that a specific software development item must be completed by a specific date. However - when there is no specific pressure in this way, I would much rather have my management say "I want to give you the time to make the software 'RIGHT', and I am willing to wait to make that happen."
I don't think it appropriate for the waiting to be forever, but do think that a management statement that says something like "I would like to see something demonstrable in one quarters worth of time." or even, "I am ok to wait to get this right, but I would like it to launch this year" to be fine statements that reinforce the please build this right rather than fast. As we get closer to actually delivering the software requested it is possible to provide a VERY high confidence number on 'when' we are going to be complete. The further away from done however the less confidence in the 'plan' being the right 'plan' and the date, so much more a lie.
In the end - none of this is in my control, but I sincerely hope that it will be at some point if I either end up in a position to make changes, or have my own company making software. Date chicken reinforces all sorts of really terrible habits and I would rather not participate.
Subscribe to:
Post Comments (Atom)
3 comments:
Joe:
I have no answers, but I have one thought: I may be able to (partially) explain the position of management.
Some managers may have tried the approach of telling the team: "Do a good job... I don't care how long it takes." For the most part they gotten the result you would expect: the project team works for a long time with no results. Afterward it is discovered that they had decided to re-write the compiler before beginning any of the actual work.
So the strict dates are a result of the managers swinging the pendulum too far in the opposite direction: "if no time pressure is a bad thing then excessive time pressure must be good!" And it is extremely difficult to exert "just the right amount" of time pressure, because it is difficult for management to understand the level of pressure. At the early "estimation" stage of the project, all they got were early estimates (notoriously unreliable); later on the game of "Date Chicken" (by the way, I LOVE that term) prevented anyone from telling them the truth.
This is one reason why I really like a Scrum methodology (and other agile approaches). There are two things it does to address these problems. One is to use burndowns and velocity estimates based on recent velocity. Using these techniques your forecast for the "completion date" of a project will tend to jump around a lot: one week you estimate you'll be done in June, the next week you're predicting completion in April. But this ACCURATELY depicts the real uncertainty in the delivery date: management may not LIKE the existence of uncertainty, but at least they're not being mislead.
The second thing I like is that with agile approaches and incremental delivery, you may be able to avoid even TRYING to estimate the end date. Instead of providing long-range time estimates and keeping people focused on delivery by holding them to a schedule, provide short-range estimates (one sprint at a time) and keep people focused on delivery by expecting them to demo their results at the end of each sprint. If the team says they need to "rewrite the framework" or something similar with no user-visible results, then give them some time to do that, but if it goes too long without results ("rewriting the compiler") then management can see that and reign them in again.
-- Michael Chermside
Mike I tend to agree - often this feels like a reaction too far in one direction. Possibly the reason is as a result of management being hood winked in the past while the team still doesn't produce anything viable/visible.
The thing that feels wrong in this instance is basically pitting sections of the organization against one another to 'NOT BE THE ONE' who misses their published date. Date Chicken seems to me to ask an organization to essentially not be 'one org' getting the job done, but a finger pointing organization where 'I can't start yet because they aren't done yet'. Just flat out makes my skin crawl.
While I don't disagree that the scenario you laid out happens, my definition of date chicken is slightly different. It may be a consequence of the Planning Fairy Tale, but it's not the fairy tale itself. Rather, it's the situation where everybody knows that he's going to be late, but is waiting for someone else to admit it first. Hence the "chicken": it's the waiting to the last minute to jump. It's not so much about the *dependency* on the other teams, it's the admission that you are the long pole. So if the project is scheduled to ship on March 15, and you know that you can't be ready until March 30, you might wait for someone else to say that they won't be ready until April 15 -- and then you never have to admit that you weren't going to be ready on March 15.
Post a Comment