After 20 Years, Have We Achieved the Vision of the Agile Manifesto? (zdnet.com) 205
"We are uncovering better ways of developing software by doing it and helping others do it," declared the Agile Manifesto, nearly 20 years ago. "Through this work we have come to value..."
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
Today a new ZDNet article asks how far the tech industry has come in achieving the vision of its 12 principles — and why Agile is often "still just a buzzword." The challenge arises "because many come to agile as a solution or prescription, rather than starting with the philosophy that the Agile Manifesto focused on," says Bob Ritchie, VP of Software at SAIC. "Many best practices such as automated test-driven development, automated builds, deployments, and rapid feedback loops are prevalent in the industry. However, they are frequently still unmoored from the business and mission objectives due to that failure to start with why."
Still, others feel we're still nowhere near achieving the vision of the original Agile Manifesto. "Absolutely not at a large scale across enterprises," , says Brian Dawson, DevOps evangelist with CloudBees. "We are closer and more aware, but we are turning a tanker and it is slow and incremental. In start-ups, we are seeing much more of this; that is promising because they are the enterprises of the future." Agile initiatives "all too often are rolled out from, and limited to, project planning or the project management office. To support agile and DevOps transformation, agile needs to be implemented with all stakeholders."
Some organizations turn to agile "as a panacea to increase margins by cutting cost with a better, shinier development process," Ritchie cautions. "Others go even further by weaponizing popular metrics associated with agile capacity planning such as velocity and misclassifying it as a performance metric for an individual or team. In these circumstances, the promises of the manifesto are almost certainly missed as opportunities to engage and collaborate give way to finger pointing, blame, and burnout." What's missing from many agile initiatives is "ways to manage what you do based on value and outcomes, rather than on measuring effort and tasks," says Morris. "We've seen the rise of formulaic 'enterprise agile' frameworks that try to help you to manage teams in a top-down way, in ways that are based on everything on the right of the values of the Agile Manifesto. The manifesto says we value 'responding to change over following a plan,' but these frameworks give you a formula for managing plans that don't really encourage you to respond to change once you get going."
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
Today a new ZDNet article asks how far the tech industry has come in achieving the vision of its 12 principles — and why Agile is often "still just a buzzword." The challenge arises "because many come to agile as a solution or prescription, rather than starting with the philosophy that the Agile Manifesto focused on," says Bob Ritchie, VP of Software at SAIC. "Many best practices such as automated test-driven development, automated builds, deployments, and rapid feedback loops are prevalent in the industry. However, they are frequently still unmoored from the business and mission objectives due to that failure to start with why."
Still, others feel we're still nowhere near achieving the vision of the original Agile Manifesto. "Absolutely not at a large scale across enterprises," , says Brian Dawson, DevOps evangelist with CloudBees. "We are closer and more aware, but we are turning a tanker and it is slow and incremental. In start-ups, we are seeing much more of this; that is promising because they are the enterprises of the future." Agile initiatives "all too often are rolled out from, and limited to, project planning or the project management office. To support agile and DevOps transformation, agile needs to be implemented with all stakeholders."
Some organizations turn to agile "as a panacea to increase margins by cutting cost with a better, shinier development process," Ritchie cautions. "Others go even further by weaponizing popular metrics associated with agile capacity planning such as velocity and misclassifying it as a performance metric for an individual or team. In these circumstances, the promises of the manifesto are almost certainly missed as opportunities to engage and collaborate give way to finger pointing, blame, and burnout." What's missing from many agile initiatives is "ways to manage what you do based on value and outcomes, rather than on measuring effort and tasks," says Morris. "We've seen the rise of formulaic 'enterprise agile' frameworks that try to help you to manage teams in a top-down way, in ways that are based on everything on the right of the values of the Agile Manifesto. The manifesto says we value 'responding to change over following a plan,' but these frameworks give you a formula for managing plans that don't really encourage you to respond to change once you get going."
success (Score:5, Insightful)
Well, they have succeeded in eliminating documentation, such as it were.
Re:success (Score:5, Insightful)
And don't forget, also eliminating QA. After all, to be truly Agile one must have the unwashed masses be your first line of testers, rather than wasting money on anyone in-house. (W10 much?).
I've worked at "truly Agile" places since last century, long before anyone except the people who coined the term had heard of it. My last job though was at a company that was trying to adopt it after decades of VERY-waterfall (no surprise, since it was a manufacturing business at heart), where they hired a couple of "Scrum Masters" a few months after I joined. I asked them what their job had been before that, and the answer was "Project Manager". And boy, did that ever become obvious VERY quickly. The contrast between what they had learnt at some 3-day course, and what I'd learnt over decades of actual *successful* experience with the concept was night and day.
So, IME, "not even close". I wouldn't QUITE go so far as to say that any company that even HAS a "Scrum Master" is by definition not Agile, but it's probably a good rule of thumb. The more you formalise the system, the more you take the authority and ability to actually deliver away from the dev team.
"Modern" Agile isn't about delivering good software in a timely manner, it's about cutting costs and delivering any old trash quickly. That's not the same thing.
Re:success (Score:5, Insightful)
Re: (Score:3)
Re: (Score:3)
Re:success (Score:5, Interesting)
You're comparing real world Agile to a strawman. Full on Waterfall never actually existed, except on paper. So complaining about how it does a poor job is pretty pointless.
And of course most of your points are wrong.
Documentation outdated? Maybe. But I'll take outdated but mostly right documentation over no documentation, or bare bones documentation any day of the week.
"A Waterfall architecture will tell you how a feature should work. An Agile storyboard will tell you WHY the feature is needed. That latter is more useful at delivering what the customer wants."
These two aren't equivalent. User stories are for PMs to figure out what we want to build. Architecture documents are for engineers, especially lower level engineers, to know what they have to do. You still have engineers translating user stories into actually actionable work.
Of course, this is all going to fly past you because you won't want to actually have a discussion on how horribly agile fails- you just want to set up strawmen and knock them down so you feel better about your failed methodology.
Re:success (Score:4)
> Full on Waterfall never actually existed, except on paper. So complaining about how it does a poor job is pretty pointless.
Not only did it exist, it was the defacto software development process for decades. Some of us were around to see it in practice, so I'm not sure where you get this fanciful idea from.
Re:success (Score:5, Informative)
I was also around. It did not exist. Processes that did much more design up front- sure, those existed. In fact they still exist and tend to seriously outperform Agile. But the idea of every detail being determined up front before coding with no feedback loops? Nope, never existed to any reasonable degree. Maybe someplace somewhere once tried it, but it was never widespread. It exists only as a strawman Agile evangelists use.
Re: (Score:2)
> the idea of every detail being determined up front before coding with no feedback loops?
Methods are not perfect in implementation and moving the goalpost is not compelling.
You're just scrambling now as you double down on something you are wrong about, or happens to contradict your internal narrative. Makes no difference.
> Maybe someplace somewhere once tried it, but it was never widespread.
There were mentions of "agile" before the manifesto, but before 2001 you literally would be in an interview wh
Re:success (Score:4, Insightful)
you literally would be in an interview where you could ask the methodology and the response was "waterfall" or (sometimes) "our own methodology" (eg Yahoo, MSFT, etc).
That's not an argument. Merely claiming to be waterfall doesn't make something waterfall. Companies back then would claim they're waterfall, just as companies today would claim they're agile. Claims don't mean jack shit.
The first conference on Software Engineering (back in the 60s) specifically laid out all the arguments and experience against any process that doesn't take into account changing requirements.
Re: (Score:2)
To add to my other comment, for posterity, waterfall was also called "SDLC". You can still find this practiced at Lucent and other companies from that period.
Cisco specifically said they practiced waterfall until the last decade in various releases.
https://gblogs.cisco.com/uki/w... [cisco.com]
Re: (Score:3)
Re: (Score:2, Interesting)
> Again, what people say and what people do are separate things.
By this measure nothing is real and nothing is a valid retelling of history.
Quit trolling about how everyone else is wrong and you're right for your own edification.
The facts stand.
Re: (Score:3)
By this measure nothing is real and nothing is a valid retelling of history.
Things are real, and are what they are regardless of what you name them. We should describe things as they are, not what want them to be.
By YOUR measure nothing is real and are only what people call things.
You have no facts.
Re: success (Score:2)
> An imperfect product is better than a product that is perfectly documented and architected but not written yet.
That depends on likelihood and impact of failure. Security and safety are pretty important.
Re: (Score:2)
Re: (Score:2)
I can very much agree here - the agile isn't very agile at all. You can be quite flexible even in a waterfall environment, but with the agile process you no longer have any checkpoint to fall back to if something goes wrong - and you don't know what it was that you delivered for a certain version of the product.
It also pushes one of the greatest lies ever "the code is the documentation".
So when the fad of agile has passed then you'll see a number of companies belly up due to not being able to get their shit
Re: (Score:3)
Sing it.
I've had people remove documentation I wrote into source files and then later come back to ask for help figuring it out.
My response 100% of the time has been to chuckle and say "It's in the documentation."
Re: (Score:2)
"but with the agile process..."
"People over processes". It's the first fine point!
With such an understandment about what "Agile" is or isn't, no wonder there're problems to success with it.
Re: success (Score:5, Insightful)
A good programming language *should* be its own documentation though.
Absolutely not. No. Never. It is impossible for the code to convey all the permutations of what it's doing, no matter how good someone thinks they've coded the software. Documentation exists (or should exist) for a reason: it describes in finer detail what is going on.
It's not the best example, but using your logic, there isn't a need for liner notes or now sites spelling out the true words to a song. Remember how many people mis-sang Hendix's song, or the multitude of other songs people sang incorrectly because they couldn't hear the words properly? Yeah, it's like that.
Re: success (Score:5, Insightful)
Code will never answer following questions:
Code can document what or how something is done, and not even that always (if it's for example using external service, you will never know what is being done really without documentation)
Re: (Score:2)
DING DING DING! You win the discussion.
I can’t count the number of times I’ve looked at some departed admin’s code and wondered why the heck they did that. Not just why they “did it that way”... why they did it AT ALL.
Re: (Score:2)
Q: "Why only show a snowflake warning in the vehicle between -4 and +4 degrees C?"
A: "Because ice is most slippery in that interval".
I had this exchange at my previous place of work.
Re: (Score:2)
Actually, it's the rubber on the tires that gets most slippery.
https://www.toyotires.ca/blog/... [toyotires.ca]
Why 7 degrees Celsius?
Below 7 degrees Celsius, the rubber on all-season tires progressively hardens making them less effective as temperatures drop.
On the flip side, this temperature is also when winter tires start doing their best work. If you regularly encounter ice, unplowed snow or slush, then you're going to need winter tires.
Winter tires will give you the extra traction, braking and handling you'll need to confidently drive in all cold weather conditions.
They have specialized rubber compounds and tread designs to handle the cold temperatures. The tread remains flexible to prevent snow buildup and help with traction on ice.
If you choose to install winter tires, be sure to switch all four tires, not just two.
Using only two winter tires can cause a car to spin unexpectedly because of greater traction on only two of the wheels.
It's best to play it safe and have winter tires installed not just early but on time.
If you wait for the first sign of snowflakes to have your tires changed over, it could be days before you get in and youâ(TM)ll be compromising your safety in the meantime.
At the end of the winter season, remember to remove your winter tires once the temperatures are consistently higher than 7 degrees Celsius.
This will ensure your winter tires do not wear prematurely in warmer weather.
I.e. Snowflake symbol is a reminder to change tires to winter ones come cold and then to forget about it until the symbol shows up again - at which point you should plan switching back to summer tires.
If anything, the symbol isn't properly explained to the customer - the code running it is just fine. Which seems to me like a job for - PROPER DOCUMENTATION!
I.e. Once again agile sucks a big fat one.
Which is why if
Re: (Score:2)
The logic of changing tires when the snow flake comes on or goes out doesn't work in reality. You may have +10 degrees in the day and then during evening it drops to -2 and you'll get ice.
For truck drivers that drives long distances then it can be -20 when you start to drive and the friction is OK but after some 50 miles you'll suddenly approach 0 degrees C and then things are getting very slippery. So therefore the warning makes sense to not be active at -20 but come on when you go over -4.
For that matter
Re: (Score:2)
It is impossible for the code to convey all the permutations of what it's doing
Documentation exists (or should exist) for a reason: it describes in finer detail what is going on.
Neither can documentation convey all the permutations of what it's doing.
If it were possible to convey permutations, those conveyable permutations should be made into regression tests - code. The rest of those permutations (known or unknown), I'd seriously look into refactoring them to make them also conveyable.
I don't know about you, but I've written many lines of code that were undocumentable - namely because they were proof-of-concepts or prototypes full of al dente spaghetti. I then refactor them
Re: (Score:2)
The more you formalise the system, the more you take the authority and ability to actually deliver away from the dev team.
Yes, the "people over process" part is the very first thing they dropped, because (project) managers fall back on process whenever they have to deal with random crap like "people" (it's no surprise they refer to people as "resources", easily quantified, classified and replaced). They now have formalized the system to the point where there is such a thing as an "Agile Practitioner certification", and employers require these or at least "must have x years experience in working in Agile teams".
Re: (Score:2)
"the "people over process" part is the very first thing they dropped"
Who's "they"?
Someone already said something to mean more or less "Agile is a bottom-up effort on orgs that don't really want to change a iota"... or better said, not "orgs", since they don't have free will but some very real people within the organizations, usually at the top.
But then, there *is* a criticism that can be done to very foundations of the Agile Manifesto: it was written by high level professionals that, be it unconsciously or
Re:success (Score:5, Insightful)
Seems like, yeah. (Most) professional practice involves adopting processes to maintain quality and consistency. Modern software projects seem more like an episode of reality TV.
Well, there's lots of software and not much documentation getting produced anyway. Regarding "working", your mileage may vary.
Three martini lunches?
I don't know if responding to change has improved, but following a plan definitely decreases when you don't have one.
Re:success (Score:5, Insightful)
I came here to make a similar comment. You beat me to it, but I'm going to have my say anyway.
I worked for Digital Equipment Corporation (DEC) from the mid-1970s to the early 1990s, and we always used waterfall.
* Individuals and interactions over processes and tools
If you don't value processes and tools enough to seek them out, or make them if necessary, you are constantly re-inventing the wheel. That is not very productive.
* Working software over comprehensive documentation
If you don't document the software, both for future maintainers and current users, you don't have a maintainable, usable product. In other words, you have nothing.
* Customer collaboration over contract negotiation
Without a contract there is no way to determine that the product is done, and you are to be paid. That's not a very good way to run a business.
* Responding to change over following a plan
Not having a plan means you cannot tell the customer when the product will be ready. You do need to respond to change, but the proper response is to update the plan and get the customer to sign off on the added costs of the new feature he wants. Doing this is likely to piss off the customer, but that is better than not beiing paid.
Re: (Score:2)
No disagreements here. I see far more con jobs and featherbedding to do with Agile than any actual productivity.
I remember when "compiled languages" were going to save the world by replacing plugboards.
I remember when "structured programming" was going to save the world by eliminating spaghetti code.
I remember when "object oriented" everything was going to save the world by enabling code reuse.
(ad infinitum...)
Now I just like to sit back, pop a cold one, and watch what' s going to "save the world" next. It'
Re: (Score:2)
There are always slackers who make a career out of always looking busy. Maybe they're not intentionally slacking, but they may lack the actual ability to do a lot of useful stuff but they have learned how to hide this. Ie, rewriting frameworks that don't need rewriting. Or using code generation tools to get their lines of code per day higher. Changing an API so that they can spend the next few weeks mindlessly changing all the old code that used it.
Sometimes managers don't even see this. They'll praise
Re: (Score:2)
Too many people confuse their pet peeves and their problems with the initial learning curve as a problem with the "paradigm". They don't account for the need to gain experience to understand what it is they actually don't like.
Compile errors seem to get in the way, until you get over the noob mindset of hiding er
Re: (Score:2)
When you drive a car over a bridge you don't worry about how good the engineers and contractors who designed and built the bridge were, nor the ones who designed and built the car. When you get in a plane you don't worry about whether you've got a good pilot or a bad one. Commercial pilots in particular are generally required by law to follow standard procedures until they've exhausted them.
An example of an exception to this pattern is medicine, where a good physician versus a bad one can make a tremendous
Re:success (Score:4, Insightful)
Medicine is moving in the direction of more procedures. One of the big changes of the last decades is surgical checklists, to make sure everything is finished up properly at the end of surgeries and you don't make minor mistakes like leaving surgical equipment inside the patient you didn't mean to leave.
Re: (Score:3)
It's moving that way, very slowly. Checklists, an absolute fundamental in other areas, are still quite rare, despite a pile of evidence that they improve outcomes, save lives, and save money. Not just to prevent leaving things in patients, and not just for surgery.
Re: (Score:3)
With continuous integration and continuous rollout, you have situations where every time you use an application you need to find out what they changed in the UI again today. Ie, Microsoft Teams :-) If this was civil engineering, you'd have to worry about whether or not there might be a left turn in the middle of the bridge.
Re: (Score:2)
>Not having a plan means you cannot tell the customer when the product will be ready. You do need to respond to change, but the proper response is to update the plan and get the customer to sign off on the added costs of the new feature he wants. Doing this is likely to piss off the customer, but that is better than not beiing paid.
Part of the problem I think are Agile purists. They may feel that all plans and waterfalls and whatnot should be thrown away. But when Agile works on something complex, it is because it works in collaboration with the plan and the waterfall and all the other departments not following Agile.
Ie, for a new board, you have to deal with supply chain issues. Long lead times, shipping times, etc. So part of the plan is figuring out what is needed and also when it will be available. If a feature is needed in Ja
Re: (Score:2)
...So part of the plan is figuring out what is needed and also when it will be available. If a feature is needed in January (board bring up) then do that before the tasks that aren't needed until June. But don't keep useful tasks in the backlog forever if there's a deadline for them coming up. Managers will have to step in if a dev is not choosing the tasks to work on that are holding up other teams or departments.
I don't think it should be up to the developer to choose tasks. A proper plan has tasks that must be completed in time for external events that depend on them. It also has milestones, where the team gets together to update the plan based on experience since the last milestone.
When I was a project leader, at each milestone meeting, after the plan had been updated, I would ask each developer which tasks he wanted to work on. I respected those choices as best I could when handing out assignments. By the e
Re: (Score:2)
"Part of the problem I think are Agile purists. They may feel that all plans and waterfalls and whatnot should be thrown away."
Those *can't* be "Agile purists". And, no, this is not a matter of "no true scotsman". All Manifesto's points are layed out the same way: "this over that". See? It nowhere says "this INSTEAD of that" and it doesn't say that because they never meant to say that.
"People OVER processes" is not "People INSTEAD OF processes".
"Working software OVER comprehensive documentation" is not "
Re: (Score:2)
I hope the manifesto is never completely implemented, because it is indeed broken. Ie, it assumes that the rank and file coders should be the ones in charge. I understand the frustration of being entry or mid level, but you can't have everyone be their own boss and still get stuff done efficiently.
So - Processes as vital. Don't get rid of them or you get chaos. Agile is a set of different processes, except that those foster chaos rather than order. Not everyone is working on a web site where continuous
Re: (Score:2)
Well, they have succeeded in eliminating documentation, such as it were.
This is a significant pain point in the company I work for.
We design chips and there are 'tool' groups that write CAD software and software to bind oft-the-shelf tools into tool flows you can use to turn code into chips.
They took on the agile mantra and now there's now no documentation for anything. There's a wiki, which is to say the least, not documentation.
Re:success (Score:5, Informative)
True agile doesn't eliminate documentation. It simply values working software more. If somebody comes in and "implements agile" by eliminating documentation, they aren't really doing agile.
Agile is often "still just a buzzword." (Score:3, Interesting)
Because every time anyone talks about it, like this summary the ratio of buzzwords to meaningful content is high.
Agile is less of a buzzword and more of a force that attracts buzzwords to it, like gravity but for buzzwords.
mod parent up (Score:2)
Although use of Agile really reflects a mentality/culture of buzzwords; a symptom rather than a cause but in it being fundamental it can look like the source of the problem. Starting out big on it is just a sign you have a problem from the beginning.
Reality is, just like government org design -- it's like Franklin said, any system well managed is just fine. (but then went on to say that the problem really is maintaining a well managed system over the long term. A concept he brought up more than once, sin
Re: (Score:2)
Of the recruiters (for specific positions, not just to get on an agencies books) that have asked me if I have worked in an "agile" environment before, they always flop around like a fish out of water when I respond "how do you define agile? Is this position following the Agile Manifesto or something else?" etc etc.
Its a buzz word that has little to no meaning in the actual industry these days - its a tick box for an employer to say "yes, we do that" and they never define what 'that' actually is.
No (Score:5, Insightful)
"People over processes." The article is talking entirely about processes, as if the people they interviewed (mostly consultants) haven't figured out how to value individuals.
Ultimately if you have good managers and people on your team, any process can work, but if you have bad people then all software methodologies will fail. A bad manager can especially ruin a team quickly.
Re: (Score:2)
Interviewing consultants. I see the problem right there.
Re: (Score:2)
Ultimately if you have good managers and people on your team, any process can work, but if you have bad people then all software methodologies will fail.
You can swap quite a few concepts for "process" and "software methodologies" in this insightful statement. Easy example: "programming languages" and "projects." How many flamewars have we seen here because X language doesn't support "preferred feature du jour," and it therefore guaranteed project failure, company collapse, end of the world, etc? Nobody can use Perl - ever! - because it doesn't support what-have-you. :eyeroll: And, yet, good programmers can make useful, maintainable things out of it.
Re: (Score:2)
So true.
Betteridge (Score:4, Informative)
That's all you need to say.
Re: (Score:2)
Betteridge
Just like Communism (Score:4, Insightful)
If your Agile is failing, it's because you have failed the glorious doctrine of Agile, not because Agile as a process to apply might have some improvements to make.
Re: (Score:2)
Also capitalism or waterfall development. Any "ism" or methodology fails most of the time because most things fail.
Re: (Score:3)
I remember running into this problem on some forums in the past where technical ideologues feel compelled to scold you. I see this on Stackoverflow a lot still. As in "I have to fix some code in C++, so how do I do XYZ?" and 9 of 10 regular forum posters immediately say "that's not how you're supposed to do it!" Then you reply "but I need to fix a bug here, I can't rewrite the whole code base", only to be told in a chant "rewrite, rewrite, rewrite..." Then you say "I fixed the problem with a type cast,
Re: (Score:2)
Do you spend a lot of time on Stack Overflow? Is it overrun by posters like that, and if so, does it solve a lot of your problems?
Re: (Score:2)
Whether that's Go or Rust or whatever, I've seen "write idiomatic code" seep into any discussion.
Re: (Score:2)
If the garlic chest poultice is not curing your broken leg, please apply more of it.
Re: Just like Communism (Score:2)
How many "agile" shops have you seen that actually put people first? Yeah probably not many. Start there, and then talk about mythical religious principles.
Re: (Score:2)
I have never in half a century heard anyone, left, right, up, down, religious or atheist, say those words.
It would be interesting to see if you could find a quote.
Re: (Score:2)
Agile is a fantasy (Score:5, Insightful)
A bunch of dudes who were used to really shitty ways of working assumed that all they had to do was throw some nice sounding principles on a wall and that would somehow change things. But they didn't actually provide solutions to the problems. All they did was state some general things about how they like to work. They didn't explain how it was possible to achieve those things.
So an army of consultants was born to tell managers how to achieve them. But the things that needed to change simply couldn't be. The culture, hierarchy, organization, funding, and cooperation of the company never changed at all. So people and projects continue to be mis-managed by executives who lead with their wallet rather than their brains or hearts.
It's great that some people want to make customers happy. But they won't be able to as long as the business as a whole doesn't care about them. The business will continue to push for arbitrary deadlines, and robotically churn out shit not led by the customer, but by some executive's whims.
Agile's principles do nothing to address the mismanagement, poor leadership, faulty priorities, and terrible communication/organization of companies. So, no, Agile will never achieve its vision.
Re: (Score:3)
A bunch of dudes who were used to really shitty ways of working assumed that all they had to do was throw some nice sounding principles on a wall and that would somehow change things...So an army of consultants was born to tell managers how to achieve them.
You forgot that some of those dudes were also consultants.
Re: (Score:2)
Paid consultants. But I repeat myself.
Re: (Score:2)
The business will continue to push for arbitrary deadlines,
Like most who bitch about headlines you fail to realize that software projects don't exist in a vacuum. Quite often there are whole other departments and expenditures that rely on the output of a software project. Budgets, sometimes in the millions of dollars, have often been allocated to coincide with the software product release. Sometimes there are regulatory requirements that need to be met. One of the most significant of these that I know of involved AT&T. The original AT&T ultimately met its
Re: (Score:2)
I am not familiar with your AT&T example, but sometimes the "impossible deadline" problem is due to procrastination on the part of management. Everyone has known for years that a job needed to be done, but no budget was allocated for it until too late to get it done on time.
Re: (Score:2)
Re: (Score:2)
Thank you for the Forbes story about AT&T Wireless. The following paragraph jumped off the page at me:
In late 2003, the company tried to install new software for signing up and coordinating customers using its new network. According to many employee accounts, that software was so complex to implement that it took months. Those employees said the implementation should never have been commenced so close to the Federal Communications Commission's November deadline for implementing local-number portability.
Re: (Score:2)
AT&T crapped out because of sclerotic management. Missing a deadline is merely an effect, not a cause.
Re: (Score:2)
The deadlines are arbitrary in the sense of making a good product that solves a customer's needs and makes them happy. If the product's not ready, it's not ready. Compromising the product and overworking staff just to hit a deadline doesn't make for a better customer outcome, and the business (and govt) needs to realize that. Just because "my boss said so", or "someone's gonna get fired", or "the government is a bunch of dickless morons", is not a justification for pushing to meet unreasonable deadlines.
Wha
Re: (Score:2)
But the things that needed to change simply couldn't be. The culture, hierarchy, organization, funding, and cooperation of the company never changed at all. So people and projects continue to be mis-managed by executives who lead with their wallet rather than their brains or hearts.
I would say I am still an enthusiast for Agile, but I concede there is more than a big fat kernel of truth in what you wrote there.
As I see it, Agile has a lot of potential to help discussion around ambiguous requirements and uncertainty around the scope of requirements. But if the stakeholders are disinterested in being involved in these discussion, Agile can be a superficial exercise.
I would also say that some projects do not have any significant uncertainty around their requirements. The requirements a
What do you have ? (Score:2)
What do you have after ~10 years when more or less all developers decide to leave at the same time ?
You have a joke, a bad one without documentation.... My reality more or less...
Re: (Score:3)
Not yet (Score:5, Funny)
The Agile Manifesto is a work in progress.
No. Universal answer to all headline questions (Score:5, Insightful)
Thats because Agile Manifesto is based on a well known logical construct called "No True Scotsman ". Every thing is as bad or worse compared to status quo ante, but now you can say, "It did not work because it was not truly agile, it was AINO, Agile in name only".
RallyDev or some company sold a bill of goods to our management and convinced them "It would be easy peasy to ship our software every three months, four releases per yer, no big deal at all". Mind you our software is certified for use for nuclear reactor design and aircraft structural design. We need to file Class 3 defect reports to all sorts of alphabet soup of government agencies across the globe.
That software will let me resolve a defect, or a use story. Then 15 minutes later revert all my changes and send me a mail saying, "you did not fill in the resolved iteration field or story points field or the test case was not signed off etc". I asked for an immediate validation, before I close the dialog tell me the simple missing fields to avoid such silly mistakes. The agile evangelist company came back with a plan to provide that in 9 months time, in their next release.
Now people will come out of the wood work saying they were AINO. True Agile would have delivered that feature in one sprint of 4 working days.
Re: (Score:2)
See, they were valuing customer collaboration (unpaid beta testing) over contract negotiation (listing what they will deliver). They were responding to change (people asking them to provide what they promised) over following a plan (which might require them to complete features). They were Super Agile!
Re: (Score:2)
Re: (Score:2)
"... is not a one size fits all model ..." - I think this is very true. In my case, we had an existing product line that our team developed and revised for a long period of years, in use at thousands of locations. We used an iterative process that made frequent releases, etc. But it wasn't "Agile!". So new manglement comes in and decreed "Agile!". However, a lot of our work was fixing bugs, mixed in with occasional new features. We did complex things in our software, and bugs sometimes took a while to f
Process (Score:5, Insightful)
Agile is a way of working & delivering - it was meant to solve a glaring issue: Date-based projects typically got bogged down in furious races that killed quality and burned out the team. Agile was meant to allow development to be a career - one that placed the inevitable "fires" into the same arc as a "normal day". I've worked in multiple roles in multiple project mgmt philosophies; they all can get things done, but agile just feels nicer - like you could get married and have kids and still work your job. Like a production bug isn't a dreaded event, just a triage and investigation event.
Teams still miss the point. Agile isn't a scrum board, or ceremonies or roles. If a project wants to be agile, make the major aspects of it as fast and painless as possible: Task tracking that seems clear "enough" & predictable "enough", change mgmt that ensures reviews, automated quality checks, re/deployment that doesn't suck, and monitoring that says meaningful things. People that are humble.
And the realization that it's a marathon of effort - not a class and a workbook. One should really see people stand up and state they need help, someone admit they could have done better in a sprint retro, and a business admit they want a better way to incentivize a career besides whipping horses.
It failed because it was an ideology. (Score:2)
I mean it started with a *maifesto*.
Not a body of research.
It was never open to reason, modifications, analysis and improvements.
Sure, some people tried.
But in practice it was a mostly blindly, rigidly followed process. Like a cargo cult. Diversions were rejected or ignored. Yet it was half-assed too.
Because fully understanding it meant thinking, realizing that it wasn't really that deep or great, and inevitably, attempts to improve or replace it. Resulting by definition in said exclusion from what was defi
Just quit a job because of Agile (Score:2)
It was as architect and it was Agile in the "SAFe" variant. Completely the wrong method. Also completely unsuitable for part-time (50%) jobs. And the jokers that did the consulting only ever had examples from coding. In the end, it ended up killing my productivity so much that I saw no other option than to leave. They will have a hard time replacing me and they know it.
People want safe investments. (Score:3)
When I use to work consulting. I would prefer to charge by the the Hour, the customer would prefer a flat fee. (Actually they wanted Hourly until we hit a flat fee maximum. Actually Actually they wanted us to work for free)
The hourly fee is best for the me as the consultant as I would be able to charge for the hours I worked, and there would be less risk of me doing free work (If the project went over budget or over spec in a fixed cost job, then I would have to eat the labor to finish the job, if I got it done early, than the customer would feel like I scammed them out of a lot of money and may not get return business), the Agile methodology would be a great benefit to me, as I can get my job done, and if they wanted more they will pay more.
The customer wanted fixed cost jobs, that way they will get what they wanted at a price they know they can pay, any overruns isn't their problem. So for those cases Agile just isn't going to happen. The product will need to be fully fleshed out before giving them the fix price for the job. Any thing beyond the scope, will need to be be added into the budget.
Parties want the safest investment with the lowest amount of risk even if it going to cost them more over all.
Re: (Score:2)
Agile wouldn't actually fix anything. If you were hourly, it would be no change. If you were on a fixed price contract, you'd be arguing over the definition of "finished" as they tried to get out of paying you. If anything Agile makes it worse as there won't be sufficient documentation on what's expected and you can expect a nasty court battle.
The only way Agile might be of use for you there is if you aren't actually consulting- if you're basically an hourly employee who doesn't technically work for the
The biggest problem with Agile... (Score:4, Informative)
Re: (Score:2)
The biggest problem I have with Agile is when people try to use it for things outside of software development.
I feel your pain. Imagine trying to have a fire station or a hospital go "Agile".
A convenient excuse (Score:2)
My experience with Agile is that is used as an excuse by the management. Whenever someone tried to talk to the managers about improving the process (for example, moving away from the one-version-of-the-sotware-per-customer model) the response was very quick: "We have an Agile process in place!", therefore nothing had to change.
Great for management ego, not much else (Score:2)
There is a reason why some of the best code out there was done by waterfall based methodology. Agile is a great feel-good thing for management because they can say that each customer has their own version... but it adds a lot of weight and stress on developers, and stifles actual work.
For example, standup meetings (which are often Scrum, but have been merged into "generic" Agile places). In my experience, this 4-6 hour meeting is a great eco thing for the Scrum master who points at each dev, goes line by
Well, DUH. (Score:2)
Agile is obvious, completely obvious.
At the core is a simple concept - communication.
This has been blown out into a manifesto and an entire pointless career path, imho.
In most workplaces, Agile now gets in the way of teams, because they are tracked by a series of tickbox activities that end up with a feeling of anxiety about the progress of a project.
We've all seen it happen. A tight knit team of competent developers, working well together, communicating well, delivering the goods.
Suddenly, they are faced w
Sucks (Score:2)
It's an irritating phenomenon (Score:2)
The 'manifesto' is merely stating what should be obvious.
By using the word 'agile' to title it, they hit marketing gold.
Now everything is 'Agile', people make entire careers in consultancy on it. Anyone and anything doing it however they want can be blessed as 'Agile' if they just paid money to the right consultants.
There's no wrong way to be 'Agile' so long as you succeed. If you failed, well then you weren't really doing Agile. Whatever the case 'Agile' is to be credited with any and all successes, and t
Too all-or-nothing (Score:2)
Agile appears to only be a net benefit if all cylinders are firing correctly. If not, then it's worse than no agile. How about a methodology that is not all-or-nothing so that bad apples don't sink it? How about a real asynchronous communication tool that reduces the need for face-to-face meetings, which usually ends up a time-wasting forum for blowhards to hear themselves talk. Save meetings for the tricky stuff, not routine stuff.
Make such a tool easy to cross-reference messages/elements using global mess
perhaps it's just bull crap (Score:2)
I've never worked with Agile, don't do software, but the first time I came across the manifesto, I thought it was an ironic joke. Quite a good one, really.
Then it was explained to me, and I realised it's not in jest. So I guess those who came up with it must have had a very different point of view and experience. Granted, my point of view was largely based on u
Re:Agile is hard, but it does work (Score:5, Insightful)
Also, good luck satisfying regulatory requirements or industry standards based on documented analyses, requirements traceability, and similar with a strict adherence to "working software over documentation" and "people over processes."
There's a reason that safety and security standards are so heavy on documentation, not just on cranking out code. Writing the code is, in fact, the easy part of software development. The hard part is defining what "working" means in the first place, then demonstrating you do in fact have working code.
Re: Agile is hard, but it does work (Score:2)
It's easy for me to nod along with that manifesto until that part. It's written in a way that's almost impossible to disagree with. Does "working" imply that problems are solved with the most intuitive option available, adding the least amount of technical debt, because that's what eliminates comprehensive documentation. I suspect it does, because anyone can write four simple steps to do anything great if we presume the practitioners have the highest levels of wisdom and discipline to begin with.
I keep r
Re: (Score:3)
Re: (Score:3)
Also, good luck satisfying regulatory requirements or industry standards based on documented analyses, requirements traceability, and similar with a strict adherence to "working software over documentation" and "people over processes."
There's a reason that safety and security standards are so heavy on documentation, not just on cranking out code. Writing the code is, in fact, the easy part of software development.
Well, you've not been paying attention then. Agile codes to a requirement, a set of deliverables. If you don't have acceptance criteria then you're obviously not doing it right.
"Working software" is right there in the manifesto: you have to have a definition of "working" and you have to meet it.
Re: (Score:3)
I don't see a conflict between agile and regulatory compliance. I work in the mortgage industry, which is heavily regulated. There are many agencies requiring reams of documentation on every loan. Agile make it possible to meet these requirements because, among other things, it looks for ways to incrementally tackle the regulatory burden.
Re: (Score:3)
Any discrepancies between my code and expected results are entirely the fault of the customer for wanting the wrong thing.
The best experience I had with Agile was customers admitting that they had asked for the wrong thing early enough to do something about it.
Re: (Score:3)
I agree with you that agile processes can work in regulated environments.
I just wanted to note, out of interest, that the original agile manifesto isn't very explicit about the continual improvement you mentioned. To be fair, the manifesto is very short (it's done and valuable, albeit not perfect). The closest part is this:
We are uncovering better ways of developing
software by doing it and helping others do it.
That's at the beginning of the document but it doesn't make explicit the fact that the uncovering better ways of developing
software by doing it is one of the core tenets.
Re: Agile is hard, but it does work (Score:2)
Well, that already makes is failed by definition to me.
Because a good metbod should not work against you. It should come naturally. It should be a flow, not a treacherous mountain climb. It should get you in a mindse that makes you instinctively do the right thing.
People don't realize that discipline is not the highest virtue. Not even needing it, is. I'd even argue that discipline is the act of a failed actor. When you aren't able to do it elegantly, but want to force it anyway. Even if the camel threading