IBM CIO Thinks Agile Development Might Save Company
Nerval's Lobster writes: A new Wall Street Journal article details how IBM CIO Jeff Smith is trying to make Big Blue, which is going through some turbulent times as it attempts to transition from a hardware-dependent business to one that more fully embraces the cloud and services, operate more like a startup instead of a century-old colossus. His solution centers on having developers work in smaller teams, each of which embraces Agile methodology, as opposed to working in huge divisions on multi-year projects. In order to unite employees who might be geographically dispersed, IBM also has its groups leave open a Skype channel throughout the workday. Smith hopes, of course, that his plan will accelerate IBM's internal development, and make it more competitive against not only its tech-giant competition, but also the host of startups working in common fields such as artificial intelligence.
The only thing they have to make sure to succeed is: "Sell/push/hawk/promote agile development tools".
But, when it comes to, the buyers and users of the Agile tools and methodology, the results are mixed.
Agile proponents have managed to sell the "no true scotsman" argument convincingly, probably because the management is willing let itself believe, "All we have to do is to give a few million dollars to this latest vendor selling the latest tools, all our problems will magically disappear".
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I haven't paid much attention lately to IBM.
That out of the way, this: historically IBM produced low-defect software. The UIs were often clunky or even bizarre, but the stuff was stable and did as advertised. Meanwhile most newcomers (MS, for example) produced horribly buggy stuff. Not saying revising how they do things wouldn't help, but adopting what everyone else is doing is going to result in... what everyone else is producing. Not a worthwhile goal.
When I read about Agile from well respected people, they explicitly stated that Agile does not replace design. 80/20 rule, you need about 80% of your design ready to go before you start doing Agile. Agile will help with those remaining 20% of cases that are hard to pin down until you get more feedback. The problem is when people skip design and jump strait into dev and assume a sky scrapper can be built with no real planning.
My senior managers recently discovered the agile process and have proceeded to school the development teams on it. They were so excited about how it will improve our company that I didn't have the heart to tell them that all the development groups have already been using it for years now.
Agile doesn't solve your problems mate, it just exposes them sooner. If everyone is working on the same thing today as yesterday, there's your problem right there in front of you.