Slashdot Mirror
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.
Slack ftw
When I worked at IBM, there was Sametime, any and all employee worldwide could be reached 24/7 already. How would Skype help?
Hmm. Wonder if the 'whatis' robot is still there..
To Terminate, or not to Terminate, that's the question - SCSIROB
There is no silver bullet with Agile. Plus, the fact that Agile doesn't scale well at all would make it unsuitable for many IBM projects I should suspect.
That said, many Agile-like practices could really help in some situations.
I am very small, utmostly microscopic.
"...as it attempts to transition from a hardware-dependent business to one that more fully embraces my butt..."
Well, that about sums it up, IBM-wise.
Agile? Give me a break! That is the most over-hyped bit of sh!t that someone wrote a book about in order to make million$. More crap software has been the result of it (in my opinion as a 30+ year software engineering professional) than just about anything else. Good processes will resemble to some extent agile, but companies who take it literally have not done well. Have a weekly staff meeting to go over progress, issues, roadblocks, etc. Daily? Please! Do NOT waste my time! Professional engineers have better ways to do that!
It is hopeless. Too many managers, too much corporate overhead, too much process, an obnoxious Dogbert HR department, too many accountants, too many managers with good hair....all the corporate crap that makes the big dinosaurs like IBM hopeless.
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
IBM ... agile??? That sounds like an oxymoron.
I always worry when the "century old colossus" is trying to act like a startup. Because it usually ends badly, because management and the bean counters have their own inertia, and are sure as heck not going to give up their control over stuff, or stop going by the 5,000 page manual of procedures.
I've known people who used to work at IBM ... and most of them still owned the starched white shirts.
They have anything resembling "agile" surgically removed when they're hired.
Lost at C:>. Found at C.
Then fund a startup. Seriously, their problem is them trying to turn an existing IBM group or team into a "startup". That isn't going to happen. You need to hire a new staff, new management, and simply hand them the money, and let them work outside the box, including not having to use IBM products by default, even deeply discounted IBM products. Perhaps *especially not* discounted IBM products.
Yes, Agile (if done correctly) is one methodology that may help them with certain problems, but you need full buy-in from the executives and product owners. If IBM management still expects the same sort of planning and budgeting and milestones they got with waterfall, then Agile is never going to deliver on what it does best. Then it will be a bunch of people working out their waterfall plan in a "standup" where everyone sits around a table. There are certain things an Agile development cycle isn't going to give a executive, and if they can't handle that, then it's going to fail.
A lot of the people who work for an IBM or a big company like that are institutionalized, much like prison inmates become. They speak a certain language, they think a certain way. That doesn't preclude individuals from breaking that conditioning, but if they are surrounded by people who think the same way, then the group will return to old ways of thinking, perhaps with a new buzzword.
IBM needs to step back and actually change their culture. They have a lot to offer simply by insisting on profitability and having decent accounting structure that many startups dearly need. But they can't just turn their existing development teams into Agile teams by fiat. I think the best way to assure that is perhaps for IBM to almost become a venture fund or an overall holding organization for these teams where they provide adult supervision, but they don't tell you how to build your sand castles.
I think for smaller projects, on a team with good interpersonal dynamics... Agile can really deliver a decent product fast, in the absence of any real requirements.
But those are the keywords: no requirements, fast, small. I have seem agile projects go right down the toilet also. YMMV.
I am very small, utmostly microscopic.
If you have stock in IBM, sell it now. This is going to go down as well as the Hindenburg.
Doing Agile just for the sake of doing it sounds like a recipe for disaster. Are they trying to solve a problem or install a cargo cult-like approach? Is the goal to reduce annoying overhead, or burden the engineers with procedures and rain dances that appease the gods of SDLC?
A company will be successful if it employs motivated people that naturally want to work in small and productive teams. In those cases an informal "agile" process develops naturally. Forcing it from the top down is more likely to cause problems instead.
That was my first thought as well. IBM Global Services was formed in 1992.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Agile will save us. And if it doesn't, it's because you didn't do Agile correctly. Agile is always the answer!
as the old American football coach said: i like my players to be mobile, agile, and hostile.
[IBM] attempts to transition from a hardware-dependent business to one that more fully embraces the cloud and services
I though that IBM was already mainly a services business...
Which makes sense enough. If you are a services company, getting complex enterprise solution projects up and running is what you get paid for. Agile can help there, even if it is not a magic bullet that will save you from an architecture that looked good on the power point slide but fails at scale, for example.
It is a dirty little secret that complex enterprise solution projects fail more than half the time, often to the tune of 8 figures. Companies do not issue press releases about the money they threw down the toilet on IT, so getting statistics on this kind of thing is difficult unless you delve into the fine details of the quarterly reports.
In our experience, customers are leery of it at first. Then they get excited as they see the project progress. After a few iterations, they get bored and want to return to the old method. It gets hard to get everyone necessary to attend sessions. It soon collapses back to a more waterfall like state, or the project gets cancelled.
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.
Now on the Agile side of things, I have no doubt it will go like the LEAN and Six Sigma culture reorg's went. Anything that costs money to do will be ignored from the Agile methodology, anything that saves money will be implemented. With LEAN and Six Sigma this mean that team were re-organized into blues and rhythms and staff was reduced before the effects were understood. Sure the re-org was supposed to make things more efficient but the staff savings were supposed to have gone into documentation and a backup pool in case the re-org didn't work. Instead people were let go through resource actions before the impact of LEAN and Six Sigma could be judged. That meant many teams were seriously understaffed.
Agile/waterfall/Forkitarian
It doesn't matter what methodology you use or what you call it if your business model is based on exploiting your disappearing market position.
IBM's horrible business model is "Of course they have to buy IBM and once they do we will punish them for buying IBM by making them pay for IBM over and over again on the "integration services" and "custom maintenance" consulting racket.
That worked great back before every company was a software company, but in the modern era, every company with enough money to look fat and juicy to IBM can and must simply hire their own coders.
Basically the more coders there are in the world, the worse IBM will do. Or rather, the more people understand technology enough to realize IBM is a scam, the worse IBM will do.
They want their headline back.
.
This results in people who had already been working 12 to 14 hour days now having to work extra hours on top of that to cover all the projects.
It's making IBM look like a grossly mismanaged company, grinding its employees down to a bloody nub.
But don't be concerned, there's a Skype channel open on everyone's desktop.
IBM isnt your fathers supercomputing company anymore, and cutthroat capitalism has led it to where it stands today to a large extent. 3 very public layoffs, a newfound reliance on 3-6 month contract jobs, and no tangible innovation for major consumer markets. Marketing that pushes AI supercomputing during the superbowl is great, but at the end of the day the PHB that watched that commercial is going to weigh her next desktop or server purchase in terms of Dell and Silicon Mechanics. That is to say she will certainly place a premium on the visible discounts shes already seeing in the market, instead of relying on IBM's brand name to justify the cost.
Power doesnt run things like it used to, and while IBM is pushing it for virtualization you can do the same thing big iron touts with more hardware and lower cost. Where IBM isnt challenged is in SAP and JDEdwards, markets where its written itself in as defacto hardware provider. IBM supports linux, true, and fought valiantly in its name, but what IBM represents is a client server sales model that doesnt scale to a world where even the toaster is expected to run an apache or memcache instance.
Good people go to bed earlier.
Maybe the transition is taking longer than they thought?
"There's too many chiefs and not enough Indians around this place." switch gears, fire 2/3 of the manglement, and get some programmers and hardware engineers actually programming and prototyping, instead of screwing around on pet projects that do absolutely freakin' nothing off their floor in the building.
if this is supposed to be a new economy, how come they still want my old fashioned money?
I hope IBM bets big on Agile, and it's a complete disaster, and then no one ever has to hear about Agile ever again. Oh, and I won't have to stand around like an asshole every morning while everyone explains they worked on the same thing they worked on yesterday.
Democracy Now! - your daily, uncensored, corporate-free
IBM needs to make a product that I want to buy. I do not care if they use agile, waterfall, spiral, or whatever other model is the flavor of the week.
It is a dirty little secret that complex enterprise solution projects fail more than half the time, often to the tune of 8 figures.
Agile won't save you from failure in these cases. Complex enterprise solutions by their nature require significant effort to get even the basic scaffolding up, and by the time they get to a scale where certain classes of problems become evident, you've already sunk quite a bit into the project. This isn't moving GUI widget from the left corner to the middle and something Agile is good at, but changing a data structure that is layered throughout 6 sets of services, for instance, one or two that the modeler may not even be aware of. This is where enterprise and data architects live and earn their pay, or fail and go to management to repeat their failures.
The cesspool just got a check and balance.
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.
Jumping onto bandwagons is never a good idea. *Acting like a start-up* is the last thing I want to see. Or maybe it means they're looking for a buyer.
“He’s not deformed, he’s just drunk!”
Now IBM is going to have to put up with the pure awfulness that is Agile, too. I'm sorry, guys.
1) Use agile NodeJS in the cloud with Hadoop. It will allow them to synergistically provide access to economically sound catalysts for change to allow them to conveniently monetize high standards in holistically motivated mindshare opportunities.
2) Don't be a dick.
Table-ized A.I.
They did, but they're not "agile" enough to have realized it yet!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
They did, but they're not "agile" enough to have realized it yet!
Hey... show some respect boy: Founded: June 16, 1911; 103 years ago
Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
At the current time, techies are in enough of demand that the outsourcing and visa-sourcing will not tick off enough techies to create a movement. But for the rest of the population, things may be different during the next slump.
Most the benefits of "internationalization" and automation are going to the 1%, and the 99% are starting to really notice. A tipping point may come. True, consumer products may be cheaper, but most males value jobs over stuff because it's what they are judged on.
(I had been replaced by a visa worker during the post-dot-com IT slump, so I hear you on that. I'm partly okay with the visa program during the up-times, but they don't draw them down during slumps.)
Table-ized A.I.
Getting stakeholders and users to put in the time necessary to think things out is always going to be tricky. Timely feedback is a scarce resource no matter what methodology you use. For this reason, the practical thing is to assume you'll get crappy feedback and have to redo a lot because of lack of feedback. Thus, it's probably better to optimize the rework process rather than obsess on preventing it.
Standardizing GUI and CRUD interface standards is one area that may help. The web browser stack in current use is a fricken mess. I'd like to be able to focus on business rules rather than details of scrolling or drag-and-drop bugs.
Table-ized A.I.
At least back a while ago, Skype was forbidden from IBM systems as IBM doesn't trust the closed code system. Has that changed? Can anyone confirm that they are actually using Skype and not Sametime or something similar?
Good technology requires planning for about 5 to 7 years out. If you burn the future to get profits NOW, then you'll eventually burn your reputation also. I don't exactly know the best corporate management strategies to optimize solutions for 5 to 7 years out, but IBM's "profits now!" program clearly failed.
Focus far more on customer satisfaction and loyalty. If you don't give them IT headaches, they'll pay a premium and/or more projects. And listening to your engineers helps also. They want to feel like they are working on something useful instead of being pawns in marketing or financial gimmicks.
You can screw some of your customers all of the time and screw all of your customers some of the time, but you cannot screw all your customers all of the time. (My apologies to Mr. Lincoln.)
Table-ized A.I.
Agile doesn't solve your problems mate, it just exposes them sooner.
That is the best explanation of Agile I've ever heard.
How about making the company someplace where people would actually want to work? If you keep treating your people like "human resources" to be mined out and cast aside then fuck you you get exactly what you deserve, a bunch of devs just trying to do enough time in the salt mines to get themselves a job for a good company. I know the company were pioneers in the field of efficiently working people to death but they may want to finally change their Auschwitz approach.
Agile is a tool, it's good for things it's good for and bad for things it's not good for. How about letting the team select the methodology they think is appropriate to the task rather than letting a bunch of empty suits make the decision for the whole company?
Here's a only partly contrived example based on something I witnessed once in an order management system: Consider a search service, a datawarehouse server, an LDAP system, and a messaging system that all depend on aspects of a user definition. However, LDAP doesn't give a hoot about any of the others, and the SSO team does their thing in a relative vacuum. They work on LDAP, and have what they think is their own personal attribute in LDAP, let's call it a companyUserId. They've used this ID as a username for a while, and the datawarehouse folks, seeing it, used it in reports 6 months ago. The messaging system, after it was created, in a 100% Agile way, decided to use these usernames as an abstraction for the user. The SSO folks decided that the ID was badly designed, doesn't meet their need for rapid indexing, and convert them all to numbers. Or, the messaging folks decide to allow users to set those usernames to whatever they want, and don't do a uniqueness test. There's so many ways that things can be tested as components and work perfectly well but go to shit in a complex system if there's not a cohesive design in place and it's managed by someone. And before you go "SCRUM will solve all this" no it won't. There were 100s involved in this development effort.
The cesspool just got a check and balance.
I was under the impression that much of what IBM does involves very large projects and often with packaged software such as SAP or even some of their own software.
Typically in packaged software like SAP or Oracle they deliver functionality that you can build upon to suit the customers requirements. But it has to be built upon using frameworks that they provide and - more importantly - it has to be done in a way that doesn't break what is delivered. These systems contain literally millions of lines of code. Any time you try to bolt something on to it you run the risk of breaking something. Often in very unpredictable ways.
As a result these projects need to be managed in a very formal fashion. Agile just doesn't lend itself well to this sort of thing in my experience. Maybe some sort of hybrid model but certainly not Agile as I know it.
Just on the face of it "IBM" and "Agile" could not be further apart.
Yep, agile strikes me as shoot from the hip design philosophy. Have something complicated to produce? Produce a small bit of it, then add to that, then add to that, then refactor (if possible), then add to that, etc...until you have reached Massive Dirty Snowball. Now stop screwing around (for the "stakeholders"), throw it out, and design something quickly...but continue to have sprints, daily meetings, reflection meetings, meetings with managers, etc...until you are getting nothing done. Now stop, take a deep breath. Shoot the "stakeholders", and get proper teams set up, get a proper design, get proper coordination, and tell the scrum leader to shove it.
Find a word that fills that blank and really focus IBM on being that company. The agile process won't fix bad leadership at the top. The agile process never fixes bad leadership at the top.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Agile doesn't make up for poor coordination above the product level. It can help in the sense that you have business involvement, but if the product owners don't talk to each other, then you have a bunch of completely uncoordinated products all being developed under Agile, and very efficiently tripping all over one another.
Is it really so smart to rely on Skype, a Microsoft holding, for internal operations? I would assume they have the capability to listen in to whatever they like, and would certainly not want to use Skype to transact business that is in direct competition to another one of their divisions. This is above and beyond the fact that the Feds will be able to listen in, since there is only so much they can do to avoid that anyhow.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
"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."
Well, that's not going to happen.
I was at IBM lin the very early 2000's. They were already using agile development methodology, and using Skype as an incontrollable interrupt source, rather than Lotus Notes is unlikely to do much beyond making executives feel better that you are always reachable so as to be a le to conveniently move the goal posts out from under you.
Also IBM's internal development model is to polish customer facing systems, which tend to be human-centric, while internal systems tend to be held together with spit and bailing wire, while doing the absolute minimum to get them to work, and they tend to be very labor intensive for the humans who have to end up using them. I really don't see this ending up where he wants things to end up.
Example: there were twenty three separate systems that someone had to drive the process through to get an IBM Web Connections account up and running, and a lot of that work had to do with copy/paste between browser Windows, TN3270 terminal Windows, sending email requests via Lotus Notes, and so on. Once these systems were up and running, I did an analysis of all the interactions and steps required, with an aim to reducing the overall complexity and change of error. Management was not interested: once something is barely working well enough to get the job done, there's zero interest in the process of working on the process; among other things, it means less job security.
I don't see this changing wildly, given the reward systems in place for employees have not changed significantly, according to people I know who still work there. The entire business model for IBM Global Services is based on giving people what they ask for, as opposed to what they actually want/need, and then iterating the process in an "Agile" fashion to suck as much money out of the customer as possible. This was true of internal IT systems as much as it was for customer facing contracts.
Once again: I really don't see this ending up where he wants things to end up.
Agile doesn't
You could have stopped there, because that sums it up nicely.
The cesspool just got a check and balance.
1) How does a CIO NOT know that IBM has been using Agile for years, and
2) Why does he think that it's suddenly going to make a difference NOW?
IBM has (supposedly) been using Agile for at least 7 years - I spent a couple of decades inside an IBM software lab until I was purged in the infamous "Project Waltz" in 2011. Agile was management "golden-bullet-of-the-month" for at least the last 3 years of that - and just as ineffective as all the others that I'd seen come and go. My perception was that it was largely inappropriate to the scale of code (millions of lines) that we were producing and managing. Much of what was good about it was the stuff paid lip-service to but otherwise ignored; most of what was bad about it was almost anything that management could see and enforce (scrums in particular were mostly a pointless and expensive waste of time - a day or more of cumulative development effort spent daily so that everyone could report on stuff that affected no-one else, and management could put a tick in the box). Frankly, it was a mechanism by which development was obliged to churn out code with less thought in design and less opportunity for customer-scale testing, on a release schedule that no customer would want to follow, in a way that middle management could spin to the higher echelons as positive accomplishment. I'd really love to see the APAR (customer problem report) rates now that that code's had time to get out there and fester; I strongly suspect that they're - to choose a word at random - "interesting". But, naturally, I'm long in the tooth and jaundiced about new-fangled stuff (mostly because I've seen all the hype 20+ times before, and seen the vast difference between that and reality - but experience and cynicism doesn't count when management is clutching at straws).
...what they want.
If you're a company producing "division" size software and you don't know what you want - Agile isn't going to save you - it's going to obscure your problems.
IBM - stop hiring PROJECT managers as PRODUCT managers and get some domain experts for the software you wish to build and have them be your product managers. You might, just might, get a clue as to what your software should be doing.
Loading...
Having been through the basic Agile training (and exposure to other processes like Lean/Six Sigma and the entire PMI catalog), the only thing I can think of when I see stuff like this is: oh, good, another largely misapplied methodology to getting things done that's a sub for really good management.
I know that a lot of these processes CAN be effective, but they ONLY work if everyone is willing to buy in and play along and if everyone is competent and motivated enough to meet deadlines (in both cases, it means that virtually nobody's dead weight).
After 15 years of working for organizations big and small, the only conclusion I can make about these "standard processes" is there isn't a single one that is asshole-proof. The only thing that ever, EVER solves that particular problem is a dynamite manager that adapts rather than conforms - and isn't afraid to fire people when necessary. But because the paradigm (shudder) states "tailorability, but stick to the process", what you end up with is a bunch of officious morons who emphasize process over ingenuity.
I'm not saying that there should be complete chaos at all times (a good manager lays out the ground rules and provides a structure for activity) or even that these processes hold no merit, but when you have a turn-the-crank process created by someone who seems to have forgotten (or never knew in the first place) what it's like to be boots-on-the-ground, you're going to get resistance by people who just want to get stuff done and not be hampered by the snooty administrators with two-year-degrees who routinely it over the PhDs because they know "the process" and the guys who know how to get shit done don't.
Some people don't believe in fairies. I don't believe in The Patriarchy.
Yes, this is one of THE MOST annoying thing about Agile proponents: it seems that every time they are told that Agile sucks, their reply is that it wasn't being done correctly. Which may be true! However, if that's the case, it means that Agile is so difficult to do correctly that it is a questionable thing to do.
I am a firm believer than 80% of programmers should not be programmers. Why is it so difficult? Programming is hard. It's even harder when you're stupid.
This is the answer to why Agile is so hard.
IBM started agile development ten years ago. I was there. I convinced the initial teams that they needed to provide SOME training/documentation to the target users, otherwise you would have a spiffy new feature/function, but no one would know how to use it. Also, IBM started moving away from hardware decades ago: the; got out of the sold disk drive business; sold of their PC business to Lenovo in 2004(?)...some friends lost their jobs in that one; and tried to sell of their server business. For over ten years, more than half the company revenue comes from Global Services (consulting).