Yesterday, the roving internal camera crew here at the IBM SWG summit asked me what I’d seen in the first day: if it’d met my expectations, and what were those. I can’t quote myself directly from memory – tragic! – but it was something like:
Well, there’s been quite a lot of talk along the lines of, “hey, we’ve bought all these companies, we’ve got all these technologies, and we’re a global business, and we’ve figured out how to run that.” And then, of course, there was a not on still having lots of revenue. The Lotus break-out session was nice because it was technology heavy.
Yeah. I can really sling the golden yarn on the spot.
Here, let’s drill down on that pulling together of all the muck into one unified bucket of muck.
The Agile Catalyst
It might be because I started reading the Carl Kessler and John Sweitzer book Outside-in Software Development on the flight up here, but much of the talk about internal development has the sounds of what I’d call “enterprise agile.” Kristof Kloeckner’s presentation hit the Agile note several times, even by name occasionally!
Agile at IBM
Now, it’s all too common to grab for the brass-ring of buzz-wordery, but after having talked with Carl several times on the topic, and Lotus’ Kevin Cavanaugh yesterday, my sense is that there’s something genuine in there running around in IBM when it comes to applying Agile practices in the large.
Sure, no doubt there’s still plenty of things that suck and make developers, product managers, and customers blow their stack on a daily basis – “work” always sucks. (The difference between a young and old programmer often boils down to acceptance that it’s always gonna suck, but those checks keep cashing, so why not make it suck a little less?) But, pulling back to the grand scheme, I hear IBM’s experiencing the benefits of Agile development, e.g.:
- Shorter delivery cycles allowing for more timely delivery of features (see “customer value” and “solutions”)
- More realistic road-mappery (e.g., “we can’t really give the sales-force an 18 month road-map”)
- Integrating a bunch of acquired teams and technologies together
There’s been a similar experience in the group I used to work in at BMC: software development Nirvana it ain’t, by far. But, it seems a lot better than the Waterfall days.
Cashing in Twice
Now, if IBM has figured something out, I’d wager there’s a chance for IBM to profit off helping others achieve the above.
“Consolidation” is widespread in the enterprise space now-a-days, and technology comes fast-and-furious enough that every development team could do with some Agile help. While there’s plenty of Agile consultants running around, it’d be interesting to see what IBM could pull off in if they productized “Blue Agile Consulting.”
I know, I know, you’re all like, “are you crazy? Having IBM tell us how to be Agile? Isn’t that like the devil Rationalizing your prayer book?”
Maybe it’d end up that way, who knows? But, with all the Eclipse Way and other Agile thoughts and thought-leadership running around in the IBM universe, why the hell not try it out and move from books to consulting gigs? More often than not, each software discussion I have with (developer-type) software people at IBM gets to a discussion of Agile and how great it’s been for them. Spreading that benefit to other large enterprises is, I’m sure, something that customers would pay for, and probably pay well.
Disclaimer: IBM is a client and has paid my way up here to Stamford for the event. BMC is a client as well – Eclipse too – and Carl gave me a free copy of the book.
Technorati Tags: books, ibm, ibmanalystconf07
Recent Comments