> Does Agile really not work with large enterprises?
It works well when you can control or bound the expectations of your users. Delivering a gradually-expanding customer self-service portal, for example, is a perfect candidate for agile processes.
However, it doesn't work when the requirements are legal or financial compliance. There is seldom an opportunity to iterate and improve, it needs to be done once and fully by the go-live date. You can't release a small part of a compliance project ahead of schedule because, well, it wouldn't be compliant... Date-bounding makes-up a large proportion of enterprise business logic for this reason.
Counter-intuitively a large enterprise actually needs to be more flexible in its project management and methodology than a small, "agile" start-up. Deploy whichever technique is appropriate for the task, which means you have to have adaptable staff.
Source: having worked for a Fortune 100 that was agile-ising.
That makes sense, I think. Though in the spirit of the original authors, it sounds like it's more about collaborating and getting things working bit-by-bit rather than releasing publicly.
In the legal/financial compliance zone, it's probably about "here are the things we need to get done for this aspect of compliance," and then just doing them.
Fake agile does not work. Large enterprises come with all their problems in processes, tools, skills, etc. They hear this new buzz word and latch on to it. They take this new thing to their teams and ask them to implement it. And all this while, the upper management just knows how to pronounce the word "Agile"; they have no clue what it means or the work needed to "implement Agile". So upper management is never in a position to help the teams. Most times, management does not want to change the existing tools, processes or grow people's skills. And so agile fails - because people want the benefits of agile without doing the work.
I've got a coworker (absolutely brilliant fellow) who bristles whenever he hears buzzword-compliant terms like ITIL and Agile brought up anywhere near management.
Not because those terms mean anything even remotely bad (in fact, he agrees with a lot of the philosophies), but because those terms come pre-loaded with a lot of baggage and preconceived notions by management, and saying that we have an agile-like process is just begging for some C-level with not enough work to do, to get involved and begin dictating requirements they don't understand.
I doubted this until I saw it happen personally a couple of times.
The process is completely, totally meaningless (and in many cases actively harmful), unless you also get the culture change to go with it.
Agile isn't binary in the sense that it either "works" or "doesn't work". Do enterprises adopt agile? Yes. Is it not "true" agile? Most likely yes. Can anyone equivocally determine what true agile is? No.
Agile is what you make of it. The biggest thing holding back a "by the book" agile scrum implementation at enterprises is budgetary process. Business people, who own budgets, have an extremely hard time understanding why they can't build X for $Y, because there are few agile processes that help them clarify that.
People buy cheap outsourced development written to spec. People say they want all the benefits of agile but that means embracing risk in order to access the potential of their coders in a real agile management environment. In fact they are happier missing out on a great implementation if it is cheap and timely.
So there is a lot of agile bullshit out there, looking agile-ish but really being paranoid micromanagement by cheapskate philistines making crap software, managed on kanban boards by people with certifications.
Real agile is hard. Maybe impossible for most projects. But being fake agile avoids grappling with the hard problem of how to get the most out of your software development with the resources you have.
The biggest problem with agile is it seems to eliminate software planning. It's a stark contrast to waterfall where execs and product managers spent months designing things leaving no time to actually implement them. Agile swings wildly the other way, some product manager writes a few user stories on what he expects the software to do and off you go writing code.
I've never been an an AGILE project where architects and managers followed through with designs or documentations. The halfway through the sprint you'll get clarifications of specs if you're luckly. Something needs to be redesigned? too late, you're doing another sprint next week.
dingaling|9 years ago
It works well when you can control or bound the expectations of your users. Delivering a gradually-expanding customer self-service portal, for example, is a perfect candidate for agile processes.
However, it doesn't work when the requirements are legal or financial compliance. There is seldom an opportunity to iterate and improve, it needs to be done once and fully by the go-live date. You can't release a small part of a compliance project ahead of schedule because, well, it wouldn't be compliant... Date-bounding makes-up a large proportion of enterprise business logic for this reason.
Counter-intuitively a large enterprise actually needs to be more flexible in its project management and methodology than a small, "agile" start-up. Deploy whichever technique is appropriate for the task, which means you have to have adaptable staff.
Source: having worked for a Fortune 100 that was agile-ising.
shockzzz|9 years ago
In the legal/financial compliance zone, it's probably about "here are the things we need to get done for this aspect of compliance," and then just doing them.
We're saying the same things, yeah?
ssi1111|9 years ago
Karunamon|9 years ago
Not because those terms mean anything even remotely bad (in fact, he agrees with a lot of the philosophies), but because those terms come pre-loaded with a lot of baggage and preconceived notions by management, and saying that we have an agile-like process is just begging for some C-level with not enough work to do, to get involved and begin dictating requirements they don't understand.
I doubted this until I saw it happen personally a couple of times.
The process is completely, totally meaningless (and in many cases actively harmful), unless you also get the culture change to go with it.
mbesto|9 years ago
Agile is what you make of it. The biggest thing holding back a "by the book" agile scrum implementation at enterprises is budgetary process. Business people, who own budgets, have an extremely hard time understanding why they can't build X for $Y, because there are few agile processes that help them clarify that.
Raphmedia|9 years ago
Zigurd|9 years ago
People buy cheap outsourced development written to spec. People say they want all the benefits of agile but that means embracing risk in order to access the potential of their coders in a real agile management environment. In fact they are happier missing out on a great implementation if it is cheap and timely.
So there is a lot of agile bullshit out there, looking agile-ish but really being paranoid micromanagement by cheapskate philistines making crap software, managed on kanban boards by people with certifications.
Real agile is hard. Maybe impossible for most projects. But being fake agile avoids grappling with the hard problem of how to get the most out of your software development with the resources you have.
sickbeard|9 years ago
I've never been an an AGILE project where architects and managers followed through with designs or documentations. The halfway through the sprint you'll get clarifications of specs if you're luckly. Something needs to be redesigned? too late, you're doing another sprint next week.