Quote:
Originally Posted by Jon Stratis
So you've never found a bug in your production code? Never had a customer ask for a change to a feature you just released? Never asked any of your employees to work late or spend a little time on the weekend to get something out the door on the scheduled date? Honestly, that sounds like fantasy to me. There are always bugs. There's always stuff your customers are going to want done differently. And there's always stuff that won't go quite as planned, requiring either extra time or dropped features to hit your deadline (which, sometimes, is imposed on you by forces outside your control).
|
In about the last 10 months I've worked about 1,000 hours of time over a 8 hour work day specifically because someone scoped a project with too little time to make the core delivery. Bugs or not.
That's not a little over time. That's basically 70 hours a week. All because someone didn't actually think about the scope, or did not understand the scope, of the core deliverable.
There's a great big difference between mostly there and off by a mile. In some cases you build a massive piece of computing infrastructure at break neck and break your necks doing it. In others you build a robot that has to accomplish 2 tasks: compete and educate. A lot of people compete but we should be honest: how many can claim that with a little more time they wouldn't have been able to educate better?
Quote:
Originally Posted by Jon Stratis
Comparing the build season to agile development is a seriously flawed comparison. Stop build day is not the last day of a single sprint - it's the last day of the entire release, which was composed of many sprints (for my team 6, one sprint per week, which is a little shorter than most agile shops).
|
Correct it's a hard stop that, because of the way it's done, is not a real hard stop.
You can literally buy yourself more time by buying parts for more robots.
My point was it should be a soft stop: we should checkpoint at the 6 week mark such that we close the loophole.