> 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.
Yes. Compliance things can be broken down into smaller deliverables just like anything else. You just have to make sure what the feature being delivered is compliant if it is being released to production. Just because something is being "delivered" doesn't mean it's going directly into the hands of clients.
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.
Employee here - A proper analysis from Kyle is certainly on our radar, although we'll likely wait until post-beta since its such a hefty project. We're just as eager to see how CockroachDB stacks up.
This is a community standard for how image artifacts should look. Right now, everyone is building systems against the Docker image specification which is problematic because Docker can and should be able to modify and extend it however they please. By agreeing on a common image spec, support for features can be more consistently available as they appear while Docker and others can extend and innovate for customers that want those specific features.
As an comparative example, we have common CSS specs which provide consistent support for most features as they are included, but Chrome, Mozilla, and WebKit are still able to experiment with new features.
Could you expand on that more? From my perspective, there are a lot of ethical concerns with silencing opposing viewpoints. In fact, one of the execs was publicly admonished and fired because he tried to do so:
>We call these extensions "high availability" because this approach means that re-indexing a production system can happen much faster, reducing downtime for our users.
Agree with their use of the term or not, they give you their reasoning at the end of the article.
