Alternate alternate headline: "Final Nail in Agile Development Coffin is Big and Blue."
Agile is dead. Long live the new development process buzzwords.
It is now time again to rename everything, come up with new jargon and trademarks to describe the patterns and anti-patterns of the development processes that actually work for us, and set those words free. Then they can be co-opted and peddled by consultants. Afterward, they are embraced, extended, and extinguished by management. And then the new words change meaning to describe all the old things, and the circle of business buzzwords turns anew.
Agile can now mean anything. Therefore it means nothing.
The new IBM process won't be entirely useless. It will likely be very expensive for IBM consulting customers and slightly damaging to the souls of the software professionals required to use it. It will be the IBM development process, with a new set of names and jargon terms.
Imagine, for example, that the new development process is called Celeriflex. All the SV startups jump on Celeriflex like fleamen on a Belmont. They crank out awesome software and make huge exits. Some of those startup veterans use their payout to create consultancies to teach Celeriflex to other software businesses. They make money hand over fist. Then businesses whose primary product is not software notice. Their management hears good things about Celeriflex and orders the CTO/CIO to implement it. Eventually, the largest companies for whom software is a significant source of revenue keep doing what they have been doing for decades and use words culled from Celeriflex consultant documentation to describe it. At that point, Celeriflex is dead. The SV startups are using Speedcode now...
But the term and phraseology have been co-opted by the PMI wonks to mean waterfall 2.0 -- The writing was on the wall as soon as "Certified Scrummaster" became a job requirement.
We weren't at a big company...
I really don't hold out much hope that this is going to work out that well without a whole bunch of training and people actually wanting it.
I won't say we were following agile, exactly, but the concept remains approximately the same. Big company management thrives on the mistaken notion that they can plan out the world years in advance. The key insights that made our adapters work were 1) no one has enough of a memory to hold anyone to those plans even six months down the line and 2) no one expects anything to work anyway, since they're all used to their plans falling over.
Which isn't to say this is going to work. I suspect that, like all things recent IBM, any success they find will be more attributable to inertia than execution excellence.
edit: clarification
It is the old, "we do that" done for appearance sake, execution and actual knowledge rarely come in to play. If anything it is a club to wield to drive out those who management does not like; usually those who do get something done regardless of the the rules to prevent that
http://www-03.ibm.com/software/products/en/rtc
Used in a big way to implement Agile within IBM and provides a nice coherent system for task management.
If they keep laying off people, eventually they will be a small company. Problem solved!
They'll be a small company, but they'll have the innovation and speed of a large company :)
Anecdotally... we have a lot of IBM stuff here and had a consultant here last week teaching a class... he was an old guard IBMer, about to retire... every day he was here I was treated to at least 1 story about how great it used to be to work at IBM, and how those days are over.
We were doing this at big blue seven years ago IIRC, and while it's a large company to transition like this, I don't think it's exactly new.
It's not quite agile as the writers of the agile manifesto would have it, but then most 'agile' seems beset by consultants and process, and IBM probably do it better than a bunch of other places I've worked.
RTC is a bit of a heavyweight and quite unwieldy though. Give me git and a text editor any day of the week....
#2) I didn't quite believe Michael O Church's anti-Agile essay [1], but nothing justifies it more than this quote:
> The system is designed to foster accountability. And with that, finally, comes speed.
[1] https://michaelochurch.wordpress.com/2014/06/20/on-programme...
A lot of this came down to the people, but it didn't help that there was no leadership to help steer it in a good direction or notice the underlying issues. Story points were fabricated to help give good spreadsheets and charts to upper management, which led to us working insane overtime before our release due to how behind we were.
This is just one anecdote though, and I know there were other departments much better off than mine was. It was enough for me to want to get out though after I realized how difficult it was to get any change in place.
I was taught agile by a certified scrum master, but the dude was completely serious about 'this just lets you fail faster, and you will fail, and often, as this process starts' which really helped.
He was right. It took a while to learn how to keep people honest and create succinct stories with a real scope. Particularly the guys who want to be architects or engineers perceive their jobs to start with the abstract and work down to specificity.
They can struggle with "What should this screen to today. Right now, today?" and want to talk about database design, message passing, data structures or anything else that doesn't answer the question.
At least for me and my planning it was far easier to make stories as small as possible and let the complexity build into a release which was roughly plotted out after velocity stabilized (even if into an upward slope).
I was probably doing it all wrong, but the hardest part was always keeping anyone from saying "well 6 more 2 weeks sprints means your release date is x, right?". Everyone wanted to just take the backlog depth, divide by velocity and project a date.
Given I was a part of IBM's drive to go agile in (I'm pretty sure) '08, and this announcement is taking place in 2015... you're probably right!
The non-greedy benefit of Agile is that work and how work happens becomes more understandable in a consistent and reasonably-well studied manner.
Originally it was just quite close to Waterfall dressed up as Agile but "they" (senior management) are finally getting their heads around it.
