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.
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.
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!
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.
It's been my experience that, like so many other methodologies, there is a disconnect between the methodology and what companies actually do from day-to-day. And while I don't have 30+ years under my belt, I have 20+ years and I've seen quite a bit over the years. Companies can change and improve for the better but a lot of old farts who refuse to keep up with modern advances in the way to accomplish things is one of the biggest impediments in my (not so) humble opinion.
Done correctly for the right kinds of projects, Agile is a good way to do things. Unfortunately, a lot of companies get Agile wrong or they try to apply it to a type of project that is really not suited to it. Too many companies follow the "throw whatever s#!t compiles over the wall every Friday" process and try to pass it off as "Agile". Clearly, they are not really following the Agile methodology and you end up with a big steaming pile since they're often breaking things faster than they're fixing them. And then there are the managers who only focus on half the methodology and you get a disjointed mess that goes off the rails. If you want to succeed, you can't just pick and choose the parts you like and discard the rest. It's a complete system and you need to do it completely.
Then there's the groups that try to apply Agile to the wrong kinds of projects. The larger the project, the less suited it is to being Agile. Of course, that's a good argument for breaking large projects into smaller ones that interact with each other, allowing them to be more suited to Agile. But beyond project size, the more safety-critical the project, the less suited it is to the Agile methodology. I'm pretty sure I don't want Boeing writing their flight control software using the Agile methodology. I'd want the heavy certification process they go through to be much more thorough when validating their systems to ensure that no little bugs slipped through. I mean, it's one thing to have a glitch in your word processor. You might lose a couple hours of work. But a "little glitch" in flight controls can lead to that plane "making premature contact with the ground" which is "bad".
Can IBM improve things with a move to Agile? Maybe. If they do it right. Will they do it right? Hard to say. Changing culture at a big corporation like that is kind of like steering an aircraft carrier. It's going to take some time and it's going to require a lot of effort. My best guess is that the move will be a partial success and the success will vary from department to department.
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.
When starting a coding session, it takes about an hour to check out your source, load all your editors/profilers/test-probes, get everything back into your memory, and get into the zone where you can produce good code. It also takes about 30 minutes at the end to wrap things up, check everything in, make notes about what you need to do tomorrow, and update your status report. So a good estimate of programmer productivity is to take each block of uninterrupted time, subtract this 90 minutes of startup/shutdown time, and sum the remainder. An always-on Skype session sitting on your screen would pretty much ensure that this is zero.
"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
No, no it doesn't. First off- why are you closing your IDEs, profilers, etc? Just leave them up. CHek out your source? Why would yours not be checked out already? Grabbing the latest updates takes about 2 minutes and can be done while doing other things. Getting mentally prepared for work may take a bit longer, but that should still be minutes, not 30.
At the end of the day? 0. There's nothing to do. You walk away and pick it up in the morning. And if you have a daily status email you have to write- tell your boss to fuck off.
I still have more fans than freaks. WTF is wrong with you people?
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.
It's not a fact.
You're underestimating how much crap has come out over the decades. Not following Agile correctly is responsible for only a very small portion of that crap because it hasn't been around long enough to measure up to the tried and true ways of producing crap. It's making a go of it but it started out way behind and hasn't even begun to catch up.
Some IT departments automatically reboot WINDOWS PCs at a set time EVERY DAY
FIFY
Done correctly for the right kinds of projects, Agile is a good way to do things.
I've heard this claim many times, and maybe it's even true. I've just never seen it happen that way. In every project I've seen that follows a variant of Agile, the result has been that it takes longer to produce lower quality code compared to if you're using more established methodologies.
My habit to leave work PC running during the night disappeared as soon as Windows update rebooted my PC, together with a Linux VM running on it. So my habit now is to pedantly close all my applications, VMs and to shut down the PC when I leave the office.
No sig today.
There's a difference between "good lord, you're screwing up this implementation" and "good lord, I'm not going to take the time to learn a new way of doing things".
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.
Agile doesn't solve your problems mate, it just exposes them sooner.
That is the best explanation of Agile I've ever heard.
Do quit. Other more accommodating individuals will take your place.
Here, on /. , we find people who think you can leave your Windows machine running 24x7 with not a care in the world. As if it would never abend, never update and reboot, nor would any badly behaved app or driver decide to crash and take the kernel with it.
These same people extol the virtues of any Linux distro able to avoid these unpleasant circumstances with aplomb.
So which is it? Is Windows a time bomb waiting to take your data day or night, or is it stable enough to to leave unattended, or does it really matter?
I thought so.
deleting the extra space after periods so i can stay relevant, yeah.
Here, on /. , we find people who think you can leave your Windows machine running 24x7 with not a care in the world. As if it would never abend, never update and reboot, nor would any badly behaved app or driver decide to crash and take the kernel with it.
Just use Windows XP. I hear it no longer updates and reboots on you.
Agile doesn't
You could have stopped there, because that sums it up nicely.
The cesspool just got a check and balance.