IBM Is Going Agile(blogs.wsj.com)
blogs.wsj.com
IBM Is Going Agile
http://blogs.wsj.com/cio/2015/04/27/ibm-cio-designs-new-it-workflow-for-struggling-tech-giant/
14 comments
Scrum/Agile-English Dictionary http://reddragdiva.dreamwidth.org/594955.html
So, just to be clear, the fact that it's being used by a big company, and/or referred to in the WSJ means it's useless?
I didn't say the process is useless. That remains to be seen. My point was that the events described in the article have stretched the meaning of Agile so far that it can now be used to describe any software development process at all, regardless of whether it actually conforms to the principles that originally inspired Agile.
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...
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...
Add a few diagrams and you can brand your meta-process linguistic lifecycle :)
Inside their comment, I think there is a point that's pretty interesting: New buzzwords will be formed because there are a lot of shops that simply won't do something the way that IBM or (Microsoft for that matter) does. In other words, there are a lot of shops where if the conversation contains "...the way Microsoft organizes" or "...the way IBM plans their projects" it will immediately be a no-go, but if you call the same process "underscore projecting" and say a lot of startups use it, it will be considered.
Agile the concept has worth. I've been successful with it.
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.
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.
There's no good idea that can't be turned into a bad idea if you just do it hard enough.
Agile in a big company:
http://dilbert.com/strip/2005-11-16
http://dilbert.com/strip/2007-11-26
http://dilbert.com/strip/2005-11-16
http://dilbert.com/strip/2007-11-26
Some years ago I came to realize that someone I was working for was using "Agile" in the sense of the first strip.
We weren't at a big company...
We weren't at a big company...
I worked at IBM for 5 years, and some of the teams I was on used "agile" development methods. In that they used the names, but our "scrums" were an hour long, in a meeting room, with everyone bringing their laptop. Management more than 1 level up expected waterfall-like development, so it all just meshed badly.
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 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 spent a long time at a boutique consultancy that specialized in rescuing at-risk software projects for fortune 100 firms. Mainly, that meant we got very, very good at building up waterfall adapters for our internal processes.
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
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
I second that simply based what I've seen on InterConnect and my experience with IBM devs or Watson so far. What they do might be agile, but then, what everyone else does isn't.
That sounds exactly like the DOD's idea of "agile". It's a nightmare, and made me consider agile a swear word by the time I left.
I was a contractor for them in 2007-8 and the project was using the "agile" label back then. It was anything but agile, but I can see why so many people hate agile if their experiences were like that.
My manager almost set up a regular "scrum" meeting a month ago. The lead programmer and I spoke up, disputed it, and got it changed.
I work at a Telco - you just described my daily activities perfectly.
Ouch. My heart goes out to all those men and women at IBM who are about to get "Agiled".
I always look at these announcements in the same way as gazing in on the office of some mid level executive where the bookshelf has a book for every business process type and programming language.
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
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
I'm surprised that there is no mention of Rational Team Concert:
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.
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.
Took a look at the white papers and this actually looks interesting. Why would I use this over something like Jira with Greenhopper? I'm trying to keep my mind open about tools like this.
I'd rather unclog blocked toilets with my bare hands than touch anything with "Rational" on its name
As someone who regularly uses Git (and prefers it), RTC really isn't all that bad. I'd even go so far as to recommend it for some teams/companies.
As someone who wasted time and sanity with that ginourmous piece of crap called Clearcase, I'd rather flush money down the toilet than ever give money to IBM/Rational again
"The mission is to have innovation and the speed of small companies..."
If they keep laying off people, eventually they will be a small company. Problem solved!
If they keep laying off people, eventually they will be a small company. Problem solved!
> If they keep laying off people, eventually they will be a small company.
They'll be a small company, but they'll have the innovation and speed of a large company :)
They'll be a small company, but they'll have the innovation and speed of a large company :)
I'd trust this all more if it was coming from the teams back up, rather than edict going down.
Also keep in mind this article is in the Wall Street Journal... take it with a grain of stock price PR salt... sadly developers and engineers at IBM are going to get the sh* end of that stick.
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.
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.
Agreed. I hope that this involves empowering team leads to find best practices that work for their engineers.
Enterprise companies are all going agile this year, I bet someone from Gartner is suggesting this shift... and the result is clearly not that effective.
Seriously, who instigates these fads? It's like every year there's some new business model that everyone follows like a bunch of lemmings. Last year (or the year before?) it was everyone working in the office (as opposed to at home) because someone at Yahoo! decreed that was the way to go.
If it isn't obvious, announcements like these are purely PR. Once the general public starts reading the stories like "Facebook is agile and uses open offices", they begin to associate the experience of their Facebook iPhone app with the result using agile and open offices. They then ask their boss why their CRUD accounting/finance/analytics app can't look and feel like FB and then those bosses (the CRUD vendor clients) put pressure on their vendors (such as IBM) to change or they're going elsewhere.
You can just take it this way: if a company follow such stupid trends is a company worth leaving.
(standard disclaimer - I do not speak for IBM. I'm not even a current employee)
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....
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....
#1) Nothing says Agile like top down process design!
#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...
#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...
That seems unlikely. Big companies like big ships have a lot of inertia. They may adapt "Agile", but almost certainly in name only.
This was the case in my few months there. We had "sprints" and "stories" but 75% of all the stories in every sprint would just get pushed to the next sprint with no thought behind it. Part of that was because our stories themselves were so broad and were worked in a long term waterfall manner. Our standups were just everyone falling asleep while each person took their turn saying what they did the previous day. If someone did actually have impediments or useful information to convey, most did not pay attention enough to notice. And finally, we didn't have retrospectives, which are a great time to be able to reflect on how to improve as a team and prevent issues in the future.
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.
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.
Sounds like pro-forma agile - phagile - if you will.
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.
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.
When enough companies start coming to you and saying they want "agile" development, you give it to them. Even if the companies don't know what agile means. "No, I don't want to prioritize, I want everything in this requirements document we are handing over."
>> Big companies like big ships have a lot of inertia.
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!
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!
If IBM didn't use Agile, what did they use?
The non-greedy benefit of Agile is that work and how work happens becomes more understandable in a consistent and reasonably-well studied manner.
The non-greedy benefit of Agile is that work and how work happens becomes more understandable in a consistent and reasonably-well studied manner.
"Waterfall" with detailed project schedules in tools like MS-Project (which BTW, is still useful for all-process oriented projects). I'm a little confused by the article since the parts of IBM I've seen have been using Agile for years (scrums, iterations, epics/themes/stories).
I'm part of a team within IBM that's been using Agile (Scrum) for the last 6 years.
Originally it was just quite close to Waterfall dressed up as Agile but "they" (senior management) are finally getting their heads around it.
Originally it was just quite close to Waterfall dressed up as Agile but "they" (senior management) are finally getting their heads around it.
The article isn't talking about the teams that develop software that is sold to customers but about the internal Ops team that comes under the CIO's office.
if IBM says its "going agile" then its time to start funeral arrangements for agile.
like putting lipstick on a pig...
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.