Many of the projects in IT on Wall Street don't seem like they're developed 'agile-ly'. PMs, BAs and developers still have waterfall ideas in mind.
This goes against all common sense: (1) It is well documented that the waterfall system is an extremely poor approach to developing useful systems to stakeholders, and (2) in an arena like Investment Banking, where Time to Market is usually "need to have it yesterday", waterfall is completely the wrong way to go.
There's something about the human psyche that gravitates towards using a waterfall approach: possibly the desire to have things wrapped in packages with a bowtie so that it can be deemed complete. I'll complete the requirements, hand it over to the architect who will then complete the design and then hand it over to the developers who will then hand it over to QA. [QA of course gets short-shrift in all this].
Blame Henry Ford and his assembly-line :) Of course there's a huge difference between assembling a car (or any manufactured product) off the assembly line and developing software. By the time the car or toy or whatever product it is hits the assembly line, prototypes have been constructed already, focus groups have been interviewed, potential users have been approached, etc. Do we do this with software? I've seen it happen on projects where prototypes are not even created and shopped around to end users for their feedback.
The assembly line is just not the best analogy for building software...
No comments:
Post a Comment