Slashdot Mirror
Ask Slashdot: Development Requirements Change But Deadlines Do Not?
cyclomedia writes "Over a number of years my company has managed to slowly shift from a free-for-all (pick a developer at random and get them to do what you want) to something resembling Agile development with weekly builds. But we still have to deal with constant incoming feature changes and requests that are expected to be included in this week's package. The upshot is that builds are usually late, not properly tested and developers get the flak when things go wrong. I suspect the answer is political, but how do we make things better? One idea I had was that every time a new request comes in — no matter how small — the build gets pushed back by 24 or even 48 hours. I'd love to hear your ideas or success stories. (Unfortunately, quitting is not an option)"
But we still have to deal with constant incoming feature changes and requests that are expected to be included in this week's package.
The feature requests can come in at any time, but tell "them" that they will get prioritised and planned once per week and the important ones will get done in that time box. You will not change course between planning sessions.
After three or four weeks "they" will see that progress is quicker over all and the code is more stable.
Push back on your management. As a professional, it's your responsibility to do what you can to ensure the quality and timeliness of the end product. This is part of that responsibility.
Stick Men
Pretty much this. Don't change the deadline of the weekly build, set different dates for when the feature appears. One thing our team did was state up front that no new feature would appear for two weeks. Not today, not yesterday, not at the end of the week. Our policy became "all new stuff takes two weeks". This let us spend time fixing things and gave us a buffer to introduce and test stuff before it got rolled out. It ticked off some managers at first because they were used to stuff getting set up or committed right away, but we stuck to it and they eventually learned they had to plan ahead. Well, most of them learned.
...his new features need to be done "yesterday"
If you explained the flow of time to him, you would be accused of not being a team player.
"Any additions must arrive 3 days before weekly build otherwise they come out the following week. That is a perfectly reasonable approach to keep things moving on time."
I disagree. ANY additions that come in during the week are scheduled for the release after the current one. If they are really, really, desperately urgent then they replace the current release, with the current release delayed by a week.
This makes it painfully obvious to management that unscheduled changes come at a cost. They have to pay that cost, sooner or later and one way or another. Period. Best if those costs are shown up-front and in their face, rather than hidden at the expense of team morale and product quality.
If a restaurant customer changes their mind while the chef is cooking their choice of meal, or maybe forget to request "no mushrooms" until 20 minutes after ordering, they may get the new dish, but they won't get it on time, and reasonable people understand that. Of course there are always unreasonable customers. Management reserves the right to not serve them.