IBM CIO Thinks Agile Development Might Save Company 208
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.
leave open a Skype channel (Score:2)
Re:leave open a Skype channel (Score:4, Insightful)
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.
Re:leave open a Skype channel (Score:5, Interesting)
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.
Re: (Score:3)
Some IT departments automatically reboot WINDOWS PCs at a set time EVERY DAY
FIFY
Re: (Score:3)
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.
Re: (Score:2)
This won't help with your crappy host OS, but the beauty of running a VM is that it's trivial to save the state, then shut it down. You don't need to close any applications at all; they'll be right where you left them when you restore the state.
Re: (Score:3)
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 n
Re:leave open a Skype channel (Score:5, Funny)
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.
Comment removed (Score:3)
Re: (Score:2)
I could be wrong, but I think that high level management are more used to settings where face-to-face communication is the driving force, and that paperwork is something secretaries and lawyers do.
I don't think they really appreciate the need for precision, lack of ambiguity and a verifiable record that exists within engineering and development, and think that face time can replace precise types of communication.
I'm sure the phone companies are happy, though.
Re: (Score:2)
Skype help?
Perhaps Microsoft is paying them co-marketing dollars for doing positive PR for Skype? Maybe that's his great vision on saving the company.
Re: (Score:2)
And what would have been the upgrade from Sametime in 1998? Postcards? Voice mail?
Agile - like everything else it is good and bad (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
Except Agile would be even worse, as there's no way to keep the amount of communication lines an Agile project needs over the years. If you have a team of 100 programmers are you going to have the customer representatives needed at each engineering subteam meeting to make the proper choices? Not a chance in hell.
There's something in between the two that's better, but waterfall will do better in these cases than pure Agile.
Re: (Score:2)
Re: (Score:2, Interesting)
The way to scale Agile is by dividing enormous, monolithic teams into more smaller, streamlined teams. Methodology aside, the sub-division of laber alone would make each team member more functional.
Re: (Score:2, Redundant)
Ha. Haha. Hahahahahahahahaha.
Sorry (wipes eyes).
Re:Agile - like everything else it is good and bad (Score:5, Insightful)
Been there, done that. Did it twice. It didn't work. The communications problems are enormous. Agile relies on maximum face time. If cross cutting concerns are spread across several teams, and I have never seen a case where this has not happened, then the divisions create barriers which impede agile development paradigms. This is esp. true if the teams are scattered across sites and/or timezones. Conference calls, video meetings etc. can help but it still is not as good as having everyone in the same proximity. In fact the critical distance seems to be 50 meters!
Agile works best, in my opion, for small to mid-sized projects. Mega-corp would be better off trying something, anything, else.
Citation: http://en.wikipedia.org/wiki/A... [wikipedia.org]
Re:Agile - like everything else it is good and bad (Score:4, Insightful)
Agile == Shitpiles / Developer
Re: (Score:2)
Re: (Score:2)
Cheers!
Re: (Score:2)
In addition to not scaling well, it does not do well with distributed projects. If people are scattered across several time zones, forget about it. The lack of face-to-face that is key to agile breaks down. There is a natural distributed/agile impedance.
Re: (Score:2)
Well time zones, I would agree with. But I currently work on an Agile product with team members scattered around the US (Eastern Central and Mountain) and it is working pretty well (for an Agile product). Of course, that is not a huge time differential. I used to work on a huge project with team in the eastern US and Hawaii... not agile... and that just sucked.
Re: (Score:2)
WOrking on one now. Time zones: US Mountain, US Pacific, China, India Standard Time, Central European Time. Agile will never work when there are so many teams in so many locations with many interdependencies. How do you 'scrum' in this situation? Each site essentially becomes a silo which would be fine if there were no cross cutting concerns.
Re: (Score:2)
Look at the alternative- RUP is a way to stuff contracts with as much bs as possible. There is no way to remain competitive with what they are doing now.
Re: (Score:3)
Your old, vanilla-style Waterfall sets the whole project up to start with, with all the planning done, and then runs with it. It's a terrible way to manage the risks inherent in running a project: changes require re-work and re-planning, and propagate down through the project.
Agile project management breaks projects down into iterative and incremental phases. An agile project will use the same methodologies as a Waterfall project, but will break down major parts of single-projects and single-phases in
Re: (Score:3)
My question would be: Agile development of what? It's fine to improve your development method, but maybe you need to focus on products and services that your customers are willing to pay you for.
Re: (Score:3)
How ironic that the paper titled No Silver Bullet" [nott.ac.uk] was written by no other than Fred Brooks. Yes, the same guy who wrote the famed The Mythical Man Month, which was about his experience as a manager for software development at IBM.
Re:Agile - like everything else it is good and bad (Score:5, Interesting)
Re: (Score:2)
Bingo x 10. This is the problem in our industry, and it is woefully evident by simply polling the masses. Most people think that "Software Engineer" is a "snooty" way of saying "programmer." In other words, more than 80% of the peope "in the industry" are under-qualified or unqualified.
Re: (Score:3)
Re: (Score:2)
The Empire State Building was the first commercial construction project to employ the technique of fast-track construction, a commonplace approach today but very new in the early 20th Century. This technique consists of starting the construction process before the designs are fully completed in order to reduce delays and inflation costs. In this case, it was imperative to use the fast-track construction method to win the race for the tallest building. In order to make this work, the structural engineer makes a schematic design based upon the architect's sketches. The schematic design includes the materials to be used in construction (either reinforced concrete or steel), types of floors and column spacing.
About 80% of the design is known at the time they started building. The designed and built a framework upon which the remaining 20% should work just fine.
Re: (Score:2)
There is no such thing as "agile development". It is not a process or design pattern and it is not useful. It is a collection of marketing terms embraced by people who don't want to follow a design pattern. It is a formal excuse for poor design and an attempt to spin poor design practices into something which appears "modern" and "forward-thinking" on the surface.
If IBM really does this, it will LOOK like progress for a year or two, and afterwords everything will start to fall apart and it will be very expensive to fix, and require actual formal design. Happens pretty much every single time, unless they simply accept failure and move on.
So you bypass agile and go to design. If your customer wants you to design a thing to do stuff, how do you go about it assuming the next time you hear about it is in 6 months and you should have something by then. (And I really mean all you get is thing and stuff) -- The customer might be internal or external.
To me agile is a formalized communication frame, it's not really there to help the developer (except in the terms of knowing what you really are supposed to do), but the people (possibly idiots) on the
Re: (Score:3)
(except in the terms of knowing what you really are supposed to do)
Interestingly, in each of the places I've worked where Agile was used, there was more uncertainty about what you are really supposed to do than in places without it. In two of those places, we went from the standard development process to Agile, and we went from everyone knowing what had to be done and what they need to be doing individually to nobody really being sure of anything.
Re: (Score:3, Funny)
I'm a certified-scrum-mastering, extreme-programming, object-mocking, unit-testing, pair-programming, test-driven-programming, domain-driven-programming, behavior-driven-programming, continuously-integrating, no-designing ninja! How dare you claim that I'm just selling buzzwords!
- Agilista
Re: (Score:3)
I'm a certified-scrum-mastering, extreme-programming, object-mocking, unit-testing, pair-programming, test-driven-programming, domain-driven-programming, behavior-driven-programming, continuously-integrating, no-designing ninja! How dare you claim that I'm just selling buzzwords!
- Agilista
Sorry, we're looking for Rockstar developers.
I love cloudtobutt (Score:4, Funny)
"...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 has saved and will save many companies. (Score:5, Funny)
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".
Re: (Score:2)
LOL ... (Score:4, Informative)
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.
Re:LOL ... (Score:4, Interesting)
I actually experienced quite the opposite when the start-up I was working for got acquired by IBM in 2009. We were using Rational Unified Process prior to acquisition and ironically immediately transitioned to Agile afterwards. It wasn't a wish-wash of waterfall/RUP and Agile either.
They kept the entire core technical team of the start-up in tact and augmented it by maybe 10%-20% more developers including some specialists in our area to enhance some key capabilities. I left on good terms in 2011 when I received an excellent offer with some colleagues I had worked with during the dot com boom, although I would've been happy to stay.
Perhaps my experience is not representative of the norm but I found IBM's atmosphere pretty good for a large company. One factor could have been that the start-up was essentially one key product and IBM did not try to duct tape it to another product (yes, there was some integration, but most changes over the two years I was there would've been likely had the acquisition not occurred).
I've worked at or with companies closer to 1,000-10,000 employees that seemed much more archaic.
Re: (Score:2)
IBM ... agile??? That sounds like an oxymoron
Who said elephants can't dance?
Re: (Score:2)
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.
Bah.
I spent 14 years at IBM, and have been around plenty of other big corps as well. IBM, like all big organizations, isn't and cannot ever be monolithic. With so many people working on so many things in so many places, you're guaranteed to get a broad variety. There have been IBM teams successfully using Agile methods for years, and I'm sure there are lots of other projects who will benefit from it, just as there are many that won't, and whose technical leadership had better resist it, or it'll sink them
You want a startup? (Score:5, Interesting)
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.
Re: (Score:2)
Gotta keep growing the dividend. That's IBM management mentality. Even if they destroy a 100 year old company in the process because they destroy long term prospects they will keep doing whatever it takes to increase the short term dividend.
Welcome to the world where CEO's are paid in stock, they no have incentive to do whatever it takes to bump short term stock price at the expense of long term prospects because their own financial incentives differ from that of the company.
Re: (Score:3)
"Then fund a startup."
No buy a good start up and shut down under performing divisions. The oil and gas companies discovered this pattern over a hundred years ago.
1) Build up a war chest.
2) Find 1% of the wildcatters, or less, who are made good strikes and buy them and/or their wells out. The wildcatters won't mind as getting a percentage of the profit makes them rich anyway for far less effort.
3) Profit!
The wildcatters have agility, risk taking and innovation. The mega oil companies have pipelines, marketin
Re: (Score:2)
Re: (Score:2)
That's like saying "buggery (if done correctly)".
The ones who might take pleasure from it will rarely be on the receiving end.
Even the performers may feel dirty afterwards.
No one does Agile "correctly". The customer doesn't have the time to invest in micro-managing decisions.
The developer side does not have enough time left over to investigate the big picture and have detailed specs before producing code.
And management never gives the dev side enough time to revisit the code.
Re: (Score:2)
This has been Cisco's model in some cases. Funding a startup, letting them develop a product on their own, and then pulling them back in is how they got their server and unified fabric products off the ground.
If you have stock in IBM... (Score:4, Insightful)
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.
Someone's clearly never worked with Agile (Score:4, Funny)
Agile will save us. And if it doesn't, it's because you didn't do Agile correctly. Agile is always the answer!
Customers get tired of it after a few iterations (Score:2)
Re: (Score:2)
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 standa
Well... (Score:5, Interesting)
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.
Re: (Score:2)
"I haven't paid much attention lately to IBM"
You haven't missed much.
Re: (Score:2)
Once again IBM misses why things are going down (Score:2, Insightful)
Charge the customer to be our customer (Score:2)
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 c
IBM has other problems... (Score:2)
.
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.
Re: (Score:2)
Dean Martin diagnosed IBM in the 70s (Score:4, Insightful)
"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.
Re:Dean Martin diagnosed IBM in the 70s (Score:5, Funny)
"There's too many chiefs and not enough Indians around this place."
H-1B visas to the rescue!
Rooting against (Score:5, Insightful)
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.
Re:Rooting against (Score:5, Insightful)
Agile doesn't solve your problems mate, it just exposes them sooner. If everyone is working on the same thing today as yesterday, there's your problem right there in front of you.
Finally - Agile explained! (Score:4, Interesting)
Agile doesn't solve your problems mate, it just exposes them sooner.
That is the best explanation of Agile I've ever heard.
Re: (Score:2)
Re: (Score:2)
It means you aren't decomposing your tasks well enough.
Agile or not, I don't care (Score:2)
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's the Latest "Cloud" (Score:5, Funny)
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.
I feel for IBM engineers (Score:2)
Now IBM is going to have to put up with the pure awfulness that is Agile, too. I'm sorry, guys.
IBM deciding between TWO paths: (Score:2)
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.
IBMers aren't supposed to even have Skype. (Score:2)
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?
Here's an idea (Score:2)
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
Agile? Really? (Score:2)
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.
Crap (Score:2)
Relying on MS for core functions? (Score:2)
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.
"...accelerate IBM's internal development..." (Score:2)
"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
I am also a gray beard and I mildly disagree (Score:4, Insightful)
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.
Re: (Score:2)
But a team with good interpersonal dynamics (also known as a functional team) doesn't need anything that a formalized Agile process brings. They're already doing those few things in Agile that are actually a good idea.
Re:Not likely (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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.
Take great care in how you do this, though, and you'd better have a solidly-defined architecture before you do it. Conway's Law points out that however you set up your organizational structure, the architecture of the design will follow suit, so if you break the project up along the wrong lines you are dictating a dysfunctional system architecture.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Don't say "In your opinion" when it is a fact.
Re:Not likely (Score:5, Insightful)
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.
Re: (Score:2)
Nice Tautology. If it works, you followed it correctly, and if it didn't work, you didn't follow it "correctly" (as if there is such a thing as following it correctly.)
Bravo !
Re: (Score:2)
I would say that agile is what happens when a group of highly skilled developers self-organize around a changing requirements doc, as long as management doesn't try to force the paradigm of the week on them. It works because the team is dominated by higher skilled developers. OTOH, Agile (capitalized) is an attempt to proceduralize that (Taylorism) to get low or no-skilled people to have the same result.
Naturally, with a lower skilled team it fails. With a highly skilled team, it works to the degree that th
Re: (Score:3)
Re: (Score:2)
[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
Re: (Score:2)
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 m
Re: (Score:2)
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 d
Re: (Score:2)
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.
Re: (Score:2)
Agile doesn't
You could have stopped there, because that sums it up nicely.
Re: (Score:2)
They did, but they're not "agile" enough to have realized it yet!
Re: (Score:2)