The Daily WTF: Curious Perversions in Information Technology

2014-09-10 Reply Admin

That is a great anecdote.
My experiences go something like this : The fact is that agile, iterative development doesn't reduce the cost of a project and doesn't make it any easier to manage. All you are doing is taking the initial cost of analysis and design and deferring it to extra iterations by the developers, testers (and hopefully analysts) further down the line. Good analysis in the beginning greatly reduces the amount of neccesary "discovery" iterations.

The problem is that the MBAs see that the costs are staying the same and if anything the quality of the software is going down because all they see in meetings is how the developers never seem to get things right the first time. So the pressure starts being applied on the developers to get it right the first bloody time around, which is downright ridiculous because we don't have accurate requirements to build on. By this time the culture of up front analysis and design is completely dead and the relationship between managers and developers starts deteriorating to the point where it becomes about them and us. Things just get ugly and you start seeing massive staff turnover and managers get more defensive and try to avoid even more accountability.

Chaos, anarchy, cats sleeping with dogs ensues.

I had similar experiences in my last job, which I put up with for 13 months.

Eventually, it got to the point that my team lead and I were at daggers. This guy was not a PM or a developer...just some military vet with the right connections and no education or training besides some on the job bash scripting, which he proudly referred to more than a few times.

It eventually got out that he didn't trust "the developers" to deliver what he wanted. He was also pulling requirements out of his ass; stuff that he wanted to see happen regardless of the clients' desires. To that guy, changing a link or button text was on the same level of complexity as reengineering half of the project, and so time estimates were obviously all over the place and pointless, but of course everything would be done within the x number of weeks that the sprint lasted.

2014-09-10 Reply Admin

Kyle:
That is a great anecdote.
My experiences go something like this : The fact is that agile, iterative development doesn't reduce the cost of a project and doesn't make it any easier to manage. All you are doing is taking the initial cost of analysis and design and deferring it to extra iterations by the developers, testers (and hopefully analysts) further down the line. Good analysis in the beginning greatly reduces the amount of neccesary "discovery" iterations.

The problem is that the MBAs see that the costs are staying the same and if anything the quality of the software is going down because all they see in meetings is how the developers never seem to get things right the first time. So the pressure starts being applied on the developers to get it right the first bloody time around, which is downright ridiculous because we don't have accurate requirements to build on. By this time the culture of up front analysis and design is completely dead and the relationship between managers and developers starts deteriorating to the point where it becomes about them and us. Things just get ugly and you start seeing massive staff turnover and managers get more defensive and try to avoid even more accountability.

Chaos, anarchy, cats sleeping with dogs ensues.

I had similar experiences in my last job, which I put up with for 13 months.

Eventually, it got to the point that my team lead and I were at daggers. This guy was not a PM or a developer...just some military vet with the right connections and no education or training besides some on the job bash scripting, which he proudly referred to more than a few times.

It eventually got out that he didn't trust "the developers" to deliver what he wanted. He was also pulling requirements out of his ass; stuff that he wanted to see happen regardless of the clients' desires. To that guy, changing a link or button text was on the same level of complexity as reengineering half of the project, and so time estimates were obviously all over the place and pointless, but of course everything would be done within the x number of weeks that the sprint lasted.

To the inner quote: You can see iterative development as amortizing the cost of design over the time it takes to develop the system. Of course, it won't save you if your initial vision is utterly wrong-headed, but waterfall won't save you from that, either (and it may be worse in waterfall, because it'll become apparent earlier in iterative processes that your initial vision is TRWTF).

To the outer quote: TRWTF is your team's lead.

CAPTCHA: pecus. Software does not run on hocus-pecus.

2014-09-11 Reply Admin

Thank you for so accurately describing the last company I worked for. One observation; you seem to be suggesting in (5) that team leads and product owners have requirements that do not change from minute to minute. The hybrid will not meet requirements because they have changed significantly since yesterday.

2014-09-11 Reply Admin

"Asking "the right question" just before the answer is needed is critical. Asking it any earlier is an unnecessary risk. "

But how do you know when the answer is needed? You might ask the question and find out something that you should have known long ago, because people do not always answer other questions completely.

Once the question has been asked and answered, it needs to go into the formal specification as part of the design, so that if the answer changes it is clear where responsibility lies.

70,000 Hours for Phase I

Leave a comment on “70,000 Hours for Phase I”