Slashdot Mirror
Survey Finds 'Agile' Competency Is Rare In Organizations (sdtimes.com)
An anonymous reader writes:
The 12th annual "State of Agile" report has just been released by CollabNet VersionOne, which calls it "the largest and longest-running Agile survey in the world." After surveying more than 1,400 software professionals in various roles and industries over the last four months of 2017, "Only 12% percent responded that their organizations have a high level of competency with agile practices across the organization, and only 4% report that agile practices are enabling greater adaptability to market conditions... The three most significant challenges to agile adoption and scaling are reported as organizational culture at odds with agile values (53%), general organizational resistance to change (46%), and Inadequate management support and sponsorship (42%)...
"The encouraging news is that 59% recognize that they are still maturing, indicating that they do not intend to plateau where they are." And agile adoption does appear to be growing. "25% of the respondents say that all or almost all of their teams are agile, whereas only 8% reported that in 2016."
The researchers also note "the recognized necessity of accelerating the speed of delivery of high-quality software, and the emphasis on customer satisfaction," with 71% of the survey respondents reporting that a DevOps initiative is underway or planned for the next 12 months.
"The encouraging news is that 59% recognize that they are still maturing, indicating that they do not intend to plateau where they are." And agile adoption does appear to be growing. "25% of the respondents say that all or almost all of their teams are agile, whereas only 8% reported that in 2016."
The researchers also note "the recognized necessity of accelerating the speed of delivery of high-quality software, and the emphasis on customer satisfaction," with 71% of the survey respondents reporting that a DevOps initiative is underway or planned for the next 12 months.
Agile has always seem to take longer than it should, never works as promised. Simple staging plans and a short meeting to discuss issues seems to work well enough in my group
All sound great in theory, fall apart in practice, and there will always be someone who says, "You just didn't implement it the right way!"
Nothing turns me off an interviewee than these bullshit methodology buzzwords. Can you actually fucking code? That's what's important.
Look, spend the time (and if needed, money) to actually make a solid product from the get-go instead of relying upon adaptability. This is what will net you the best results, customer satisfaction, and fewest warranty/support issues (thus saving TONS OF MONEY.)
Around the 90s is when software development was truly in its prime, despite the shit languages and lacking hardware. It was that shit hardware that forced programmers to figure things out in effective and proper manners rather than relying upon huge amounts of error-correcting glut and hardware to cover up for their n00b-level mistakes that even a TI-BASIC programmer couldn't make.
Our current hardware is literally overpowered for every task we need it to do, if proper coding would be taught and implemented. How can I say this? We've been doing this exact same shit since the 90s. Online video? Yea, back then it was 320x240 if you were lucky, and a fake 640x480 (upscaled 512x384 IIRC) using RealPlayer's codec. Still, we had it, and when the P4 came around, 720p video was a breeze if you had something like a 64MB GPU.
But people tend to ignore history, so there's your historical quip for the night for good measure.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Management and leadership styles need to depend on your team, if you use agile/scrum/kanban/etc it means you are trying to make up for shitty management skills, and in turn are making everyone else waste 10-30% (50%-75% in extreme cases) of their time to make up for it. There is no one management or leadership style (two VERY different things, mind you) to bind them all.
Managers are glorified communal secretaries, they exist to arrange meetings, sit between upper management/clients and developers, and ensure the developers have the appropriate resources while having out extraordinarily high-level orders (e.g. "we have a new project, figure it out,") they don't make decisions but ask for input from all parties involved and arrange the information such that people who make decisions can make them quickly and accurately.
Leaders are just the most applicable guy for a given project the others will listen to, they're in the trenches do the work and can (often should) change from project to project both due to differing skillsets and to prevent burnout of the leader.
Nearly every shit place has the same problem, and it has nothing to do with Agile/Scrum/etc - the shit problem is when you have a person who thinks they are capable of both leading and managing at the same time - nobody is.
Considering that agile is a giant scam to sell consulting, training, books, etc.... low adoption only means more customers to fleece!
How many more meetings have people been subjected to because Agile got popular?
Agile and ITIL are a load of BS.
From what I have found nothing really changes in an organisation. They just decide that that buzzword is cool and they are going to "do it too".
But they don't actually ever change much or let the process work. It's still waterfall with managers already deciding which tech stack I as the "expert" will be using. As if my expert skills stop right at being able to decide what platform to use.
So they waterfall me into a given set of allowed technologies, waterfall me into requesting everything via some ticking system rather than handing me root on a personal server and giving me a laptop. Then waterfall me into the release process that I'm apparently too dumb to design myself as the "expert".
Despite my objections, I will be told to continue doing every little thing their way. This will then be called an "Agile shop". This is pretty much what I find at all "Agile shops". A bunch of wannabees who aren't actually doing anything other than re-branded waterfall development.
When half my day is restyling code, monitoring tickets in 2 or 3 different ticketing systems, arguing with infrastructure people about getting ports opened and accounts created, and fighting the others to actually approve/review code when just testing something...... perhaps it's time to let me design the whole process instead of putting me in the "expert" chair as a glorified puppet from the Manager.
The other big one is letting people tinker and play. Every company acts like the only worthwhile work is code that gets into the product. No, I may want to demonstrate some skills I have by backing up my complaints with actual fixes.... Like "I can make this 26 hour database job run in 15 minutes if I could rewrite it's logic in C++ with lock-free worker pools". I had a company that let me spend 2 weeks trying to back up that claim and I *DID*. Got me all sorts of praise and helped me to get a promotion. I go to other companies and I am "not allowed" to do such tinkering. So they miss out by wasting my talent and locking it up behind "rules".
Some days I just want to design and hash out big architecture plans.... Other days I want to micromanage some performance-related issue and make the code a lot faster without removing features. Some days I want to just bang out an already-decided thing and be mindless (but output 1000 or more lines in one sitting). The key is letting me do what I freaking want. My hunches and decisions are what makes me the expert you so badly needed. Why constrain me so much?
The key point is worrying about anything only one guy can do. "What if you get hit by a bus or win the lottery". Well perhaps that means I really am that valuable. Is it better to have a little bit of awesomeness even if that awesomeness gets hit by a bus? Is that better than no awesomeness at all?
The real innovators that changed the world were likely people who uniquely had those traits and if they were hit by a bus, the world just would stop changing. This isn't reason to stop the game-changer or not hire them in the first place! Why not take what you can get until the next prodigy comes around eh?
I basically sat around on my skills for the longest time until Wall Street came a knocking. They care about actual talent and those irreplaceable people are who they want. Wall street still has enough elitism to realize the value of those people even if the things they design require multiple heads to support later after they leave.
Agile can't be Agile because all these companies want average skills only and demand exactly how those people will spend their time.
Agile is amazing. All of our competitors should adopt it.
"People over processes". That is not anything a large organization can do at the level the actual work is done, with very rare exceptions. I am grateful for this "agile" nonsense though, because it lets me run a development project as an one-person show (plus one very good manager to keep track of things and sell this to upper management) by claiming this is "agile". This way I do not have to do waterfall stuff in a project that actually redefines itself all the time. Fortunately, I do the redefining, so this actually works. No team decisions, as there is no team.
And, while somewhat surprising to me, I find Brooks is still right: You need a strong chief engineer to run things on the tech side for maximum efficiency. Too many engineer are wimps that cannot tell management how things really are. And too many managers are too. That is how projects get screwed up.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I was watching a video where one of the guys who came up with it mention the alternative name that one of the other guys really liked. He wanted to call it conversational development. That is so much better of a name for what you're trying to do. Everything is supposed to be a conversation. A conversation is a 2 way street which is the entire fucking point. There isn't supposed to be a deal where say a project manager dictates what he wants and the devs have no say, just do it bitches. You're not supposed to have dev dump a release to QA, deal with it bitches. Hell, you're supposed to have conversation between junior and senior developers to turn the juniors into seniors. I get they called it agile to sell it to corporate but the problem is that by doing it they convinced corporate agile is just "Go fast be stupid"
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Agile fails when people do the same shit they have always done but just put Agile labels on it.
A friend of mine just finished up a project where he had 100+ people working for him in three countries. He had Agile forced on him, but he credits Agile with keeping the whole thing together. OK, the project was a year late but what project isn't.
Agile and scrum are about generating metrics for management so they can have some feeling of control over the development process -- answers to things like "how far along are we?" and "when will it be done?" The real, truthful answers of, "this far" and "when it's done" make their butts twitch. I imagine many think they can give good estimates of progress and for completion, but that doesn't make it so -- shit happens and good project coding is, in many ways, more art than science.
Just my $0.02 after 30+ years.
It must have been something you assimilated. . . .
I have been in the tech field for almost 40 years, and I have witnessed a lot of so-called 'methodologies'
Agile and Scrum are two of them
They come, they boom, they wither, and then, vanish
No matter what they are, the bottom line stays the same --- software are still buggy, projects are still over budget, and delays are routine
And the basic fact still remain --- the output of a top grade super coder is better than 30 garden variety (American) code monkeys, and if we include the outsourced labor, a top grade super coder produces more and better output than 50 Indian H1-B slimeballs
sense
somebody's agenda at play.
The reality is that 'Agile' is the latest fad viewed by bad organizations as the silver bullet to fix all their bad behavior. As such it is a very profitable consulting gig, taking money from companies desparate for self-improvement. It's ultimately hollow, the bad orgs are going to be bad orgs, and waving *any* 'methodology' at the same team will deliver pretty much the same bad experience. It's not that 'Agile' is bad, just that there isn't *any* such thing as generic process guidance that can fix a truly dysfunctional team.
Meanwhile, the consultants can keep things going through true Scotsmen fallacy. A team carefully planned every minutia of a two year effort in advance and not deviate contrary to the ostensible tenants of Agile, and they succeed, they truly get Agile even though you might not see it at first. If another company does avoid overthinking too much in advance, think they are adapting to situations as they evolve, but fail, well, they didn't *really* get 'Agile' somehow or another.
XML is like violence. If it doesn't solve the problem, use more.
If you are a manager who cannot program, and has never developed something big yourself, then of course you're going to look for a crutch to lean on. You're out of your depth, you have no idea what or how to tackle it.
The methodology companies know this, they just try to make the most convincing crutch for gullible managers to lean on.
Here having a survey that assumes "Agile Competency" is an actual useful thing, really just marketing for their crutch. Agile has nothing to do with software developement.
Scrum represents the majority of scrotum. That is all you need to know.
In my experience, those who act in accordance to how Agile describes itself, generally do not call themselves Agile, they just aren't interested in the formal labels. They also don't need anyone to tell them common sense about how to be effective, it comes naturally.
Agile in practice is institutionalized self-delusion for managers in dysfunctional organizations to fool themselves into thinking they can be a good organization by waving a magic wand and getting some certification from a consultant.
XML is like violence. If it doesn't solve the problem, use more.
It seems to be another hollow buzzword without any real meeting.
I too am an amazingly talented individual who is not just brilliant, handsome and productive beyond measure, with wonderful diplomatic and personal skills, but somehow unappreciated by the dumb masses of smelly dullards who try to hold back the incandescent light of my genius.
The only reason i stay in this thankless, underappreciated and underpaid job is... Uh... So i can post on Slashdot during work hours while those lazy bums hold me back?
Protip: If you are smarter than everyone else go ahead and hire them instead of working for them.
I've only been in one shop that has had successful software development outcomes while doing agile, but I'm inclined to think that had more to do with the project manager being more of an ideologue about his job title than anything else. He was a real hardass about making sure developers kept their calendars clear to work (to the point of frustrating business owners who were used to roping developers into 2 hour product planning sessions) and keeping standups short and on topic. You don't need agile to keep your developers from getting randomized, you just need discipline and a willingness to tell people to fuck off.
Everywhere else I've been has wanted to pick and choose which parts of agile they've wanted to use, and all that ever did was result in time lost to bloated standups and burndown charts that don't make sense because nobody bothered to plan the sprint before jumping in and doing shit. Either use it and be an ideologue about it, or don't use it at all. It's like having sex with a gorilla, you don't only sort of have sex with a gorilla, and when you do, you aren't stopping until the gorilla's done.
... the better the Company
I have gone to China and Korea and Taiwan, and tech firms there don't give a flying fuck about 'Agile' or whatever bullshit-of-the-day the Western SJWs are wasting so much effort on
Their projects are not over budget as ours, and do not suffer as much delays
Pro 1. Agile means ability to refocus attention from one problem to another at any moment without loss of work in progress.
That means that development team must be as close to product management as possible, so everything developer does should be product driven, so when work is complete we have real product feature complete.
Cons 1. In reality agile is severe coding micro management having nothing to do with actual product. Majority of user stories are written by developers and product managers have no idea what they are about and have really distant understanding why coders are implementing them. But such agile gives great control for team leads and architects to abuse their power and micromanage everybody in the office.
Pro 2. Agile means die fast. It means that bad product idea should see the world as soon as possible, so product team may actually see earlier that their idea is DoA and it has no traction on the market, so any further development is needless. Development time contributes to product cost. The developers assumption that code they write is actual product is absolutely wrong. The software became a product only at the moment when it is being sold to customer. So any time developer spent on coding is just direct contribution to expense and cost of the product and nothing else. It is impossible to improve product value via improving code base.
Cons 2. Abusive push towards fast product implementation results in endless prototype quality software development and as a result very fast degradation of code base and general development velocity which results in significant frustration of developers and their exodus to any other company where they are more respected and listened.
Then we come to the problem of balancing of these problems between developers and product team and managers.
Abusive behavior of any of them drives to degradation of general abilities of software development company to execute.
If software engineers speak about releasing of their code into open source that means your developers and architects abuse your company and spent to much time on polishing of their code base. If your product is so technically complex that your engineers managed to get so much freedom and power to start talking about open source you need to hire technical product manager who was software engineer before, so he(she) will align your engineers back to reality of your product. Releasing anything to open source means productization of your code as a stand alone product, if you don;t need it it definite abuse from developers side.
If your people manager hired legion of QA and your issue tracking system is as clean as your financial accounting books that is a pure sign of development management abuse. The company is supposed to write code and make new features in the product. Nobody sells issue tracking records, they cost nothing. If developers are afraid to make changes in the code base you are getting lava code style development. Coding is complex engineering work and as bigger system is as more issues and complexity we have in it. So abusive development managers bring more mass into the product via accumulating endless technical dept issues. Process should facilitate software development not to halt it.
If you see that your product team is nicely demoing your product but system is not feature consistent and many features don't work together, that means your company lives in the really happy world of abusive product management. You should observe total happiness in your company. Developers write really fast, you get more and more new customers in side markets not related to your business, but your old clients start to complain about unfixed for many months core features of your product.
So generally if we drive to the edge any role in software development workshop we get problems, so agile is not about micromanagement, but about constant re-balancing of priorities between roles. We have to give every role on the team time to rule the world. But it should depend on
Seriously, itâ(TM)s a bunch of snake oil. Get over it and learn to shop a product.
You typed "It's weird, the Communists are all about equality... so they set up dictatorships." but there's nothing weird about it really. It's perfectly predicatble and, in fact, made necessary by the basic design of Marxism.
Read F.A. Hayek's "Road to Sefdom" for a very lucid explanation.
The basic idea, though Hayek takes it on more thoroughly, is that Marxism requires an unjust act - taking stuff from people who earned it and giving it to people who did not. It turns out that decent civilized people do not like to do the dirty work required to make this happen, so any society that embraces Marxism must select and empower immoral thugs to do the actual redistribution and enforcement. The problem with this is that such thugs never want to do other people's dirty work and then go away leaving behind some sort of utopia - they use the power they are granted [to do a little evil in the name of Marxism] into a play for maximum power [to do all the evil they personally want to do] and they never let go of that power [duh! they were chosen for their evil properties]. It never works any other way because of human nature, and that is why apologists for Marxism are always having to claim "the wrong people tried it" or "they did it the wrong way" or "actual Marxism was never really tried" when confronted by the many examples of Marxist failure and the hundreds of millions of dead bodies left behind by all the attempts at Marxist utopia.
Nothing good ever comes out of a manifesto.
Those who do not learn from commit history are doomed to regress it.
this being Slashdot where SciFi is appreciated, I'll illustrate with a link to a little bit of SG-1
There's nothing new here, the same thing keeps happening over and over again - so many times most of us have lost count and most are unable to bring forward anything they learned in one time loop into the next time loop. (it maps almost PERFECTLY to that hillarious SG-1 episode)
Here's the problem:
There is a completely non-productive slice of society that becomes middle managers and consultants who derive exhorbitant incomes pushing crap and Buzzwords
As a result, every few years there is a new wave of books seminars and videos claiming some new buzzword methodology will solve all software development problems. Investors and management types lap it all up as a quick way to get more productivity out of the same or fewer employees, and by the time many companies have fallen for the con and spent lots of time and money adopting the new methodology the so-called experts move on. Then comes the next breakthrough and the next tidal wave of gullible bosses looking for a way to speed development while saving money.
None of these schemes ever solves the following problem (which they all always promise to solve)
Good
Fast
Cheap
Pick any two
It's amazing how you spin your history of failure as a point in your favor! I have a bridge to Utopia to sell you! All attempts to cross it have led to untold human misery, death and corruption, but Utopia itself is such a good thing that we need to keep sacrificing more people until we make it!
You try to detach the politics of Communism from the economics of it, as if they weren't linked by the concept of the Communist Revolution. Hey, wait, didn't the founder of it write some books on that? You act as if this economic system was supposed to appear magically out of thin air, perhaps via everyone voluntarily giving up their ownership of the means of production. Are you hoping we'll believe that the Communist leaders didn't advocate for political revolutions to steal the means of production from the bourgeois and implement the economic system? If you want to talk about ignorance, go read the Gulag Archipelago by Solzhenitsyn sometime to see how the Glorious Revolutions turn out in actual practice and why we can never trust a Communist candidate with political power again.
The closest we've gotten to something decent didn't happen via any sort of Communist Revolution. Rather, a few countries that have abundant natural resources, nationalize them, and let the people benefit from the proceeds. This is, of course, still vulnerable to corruption and incompetence--see Venezuela, but the Nordic countries that actually sensibly realized that the price of oil is unstable and took steps to invest the money and deal with that are quite stable and reasonable and have made good progress by investing in higher education.
Funny how that runs contrary to your statement on natural resources. This is the closest we've seen to the True Communism (TM) and unlike most things, reasonable people could actually support it because it doesn't work by robbing people. Heck, Alaska does that and it's a pretty strongly libertarian state. But no, instead we have the nuts on LateStageCapitalism telling us that Revolution will happen any day now while they work at Starbucks and buy new Che shirts from the Chinese proletariat.
"Only 12% percent responded that their organizations have a high level of competency with agile practices across the organization, and only 4% report that agile practices are enabling greater adaptability to market conditions.."
Look hi. I'm not going to comment about whether the Latest Greatest Fully-Buzzword-Compliant Management Trend is actually backed by reproduceable research or anything. I'm just going to comment about maths. If 12% of your respondents report a high level of competency in a system, and 4% report that that system is actually doing any good whatsoever... If we assume roughly equal levels of response to both questions then we have a system that, when implemented at "a high level of competency" self-reports that system as having a positive effect roughly 1 time in 3. Random chance should have a positive effect 1 time in 2. And self-reported success rates run notoriously high...
At most places Agile is just 'we don't want to do design, we don't want to do documentation, and we don't want schedules.' This has been true since Exxxxtr3m3 Programming in 1996. Back in the day someone on Slashdot wrote a savage and (at the time) highly controversial takedown of the Extreme Programming manifesto that turned out to be completely true.
Management wants to be hip and cool for hiring, so they want to say they're doing Agile, and they say you guys can have scrum meetings. But then they push back on the no design, no documentation, and no schedules, because that's just crazypants.
This results in a big disconnect between the developers and management, who each insist they're doing 'Agile' but mean something different.
It's too bad, because the most fundamental bit of Agile is absolutely the right way to go: you do semi-rapid iterations and see what works and what doesn't, and change it as needed - rather than working for months on some giant blob that'll suck. That's just good practice and probably how you just naturally work without realizing how controversial that was 30 years ago. That's really the only 'Agile' that matters, and whatever you're doing right now is probably Agile. But XP and other methodologies have completely poisoned the term.
It's not the same, though. It's not even in the same ballpark if you've read Solzhenitsyn.
Capitalism has many failures. Some Nordic countries have managed to make improvements by owning and investing the state's natural resources and using those to benefit the people. I'm not convinced that's globally sustainable, but it's at least noteworthy progress and if they can prove me wrong about them being globally sustainable, so much the better.
Communism, though, has seen nothing but failure as far as I can see, even when executed by people with the best of intentions. It's an empty promise that too often leads to a death march to Utopia. Forget Marx, you can see this as far back as the Bible. The Apostles held all things in common and shared with each other in Acts 4 and Joses, who was called Barnabus, is a hero for supporting the saints by selling his possessions. In chapter 5, Ananias and Sapphira end up dead for lying to the church to cheat the system.
The "tried it seriously, and it seriously didn't work" option. Seems to be the case at the places I have worked. Lots of money spent on agile training and scrum courses followed by missed deadlines and cancelled projects.
I've seen it too many times.
We are going to be agile.
But we will have a fixed feature, fixed deadline, we will hold up builds for an important feature instead of producing a build on the scheduled date, we won't cut features.
Agile is a good idea. But business managers and sales people abuse it. Their bonus structures are anti-agile.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Would be interested to know if a majority of companies could actually give an accurate definition of Agile. Have heard from too many managers that a project will be 'Agile-like'. Generally meaning 'half-assed'.
Zerohedge.
REALLY great source you have, there. This TOTALLY isn't sarcasm. Totally.
maybe the best question to have answered in the summary would be...
WHAT THE HECK IS "AGILE COMPETENCE" with the quotes!!!
and how can I make money off of it without lifting my ass of this comfy chair.
"accelerating the speed of delivery of high-quality software" aha. Typically, speed and quality are somewhat mutually exclusive.
Some of the mechanisms that I would assume Agile would work with: CI/CD, unit testing, e2e testing- good luck getting time to implement them.
The customers/PMS- they want features, *now*.
And the devs that come after you, they don't want to write unit tests, they don't want to figure out how you've built e2e after the fact.
Strong software development practices are, just that, strong practices. They exist outside of the methodology you've chose.
stop talking about agile. it's disastrous and produces bad software. it's dead. it's over. stop it.
"and only 4% report that agile practices are enabling greater adaptability to market conditions..."
"The three most significant challenges to agile adoption and scaling are reported as organizational culture at odds with agile values (53%) ..."
"The researchers also note "the recognized necessity of accelerating the speed of delivery of high-quality software ..."
If it's anything like my company, it's because schedules are sacrosanct. Anything will be sacrificed to hit schedule. It sucks.
Thanks comrade. Surprised you didn't include a link to Russia Today as well.
Agile software development is a team effort with a constant feedback loop. Waterfall is top-down authority and no feedback loop. The agile process is ever changing in scope and delivery depending on the situation on the ground. Waterfall software development is a fantasy that management gets to pretend is real and berate their employees when that fantasy fails. I believe it is the fantasy and power allure of waterfall development that is the crux of the matter as to why after all these years agile has such low adoption rates and not anything related to Agile. Corporations today are the equivalent of monarchies before democracy where the people at the top make the decisions, it is all about ego. Top down authority has run its course as to capability to deliver. Agile is an attempt to compensate but until the power management structure changes Agile will always be at the mercy of authoritarian, unilateral decisions of ego. Feedback is critical for success and top-down management has no feedback. This is one of the fundamental inefficiencies in any bureaucracy and why, still, to this day 9/10 software projects fail. I don't like to fail.
Dave Thomas gives his reasoning:
https://www.youtube.com/watch?...
putting the 'B' in LGBTQ+
I've worked in multiple shops that claimed to practice Agile. Half of them actually were doing Agile. They actually got good results. The other half wouldn't know Agile if it bit them in the ass. They didn't get results. They blamed Agile for their failures, rather than acknowledging that "saying we're doing Agile is not the same as actually doing Agile".
After surveying more than 1,400 software professionals in various roles and industries over the last four months of 2017, "Only 12% percent could actually explain what Agile is."
FTFY.
Have gnu, will travel.
The only reason to care if some organisations are good at chopping up interesting tasks into boring itty bitty tasks is so you can avoid working for them.
Disclaimer: Scrum Master speaking.
"Agile" is nothing but a fad and a cargo cult. Large corporations think they can buy amount x of "Agile", bring in some consultants with certifications that are beyond pointless and suddenly 8 weeks later their company is agile. This, of course, is bullshit.
Agility, on the other hand, is a requirement in certain types of settings (media production, performing arts, generic construction work, web software development, farming, etc.) The web software camp has discovered methods for agility -the most prominent being scrum - as means to cope with finik customers who don't know what they want but know exactly what it may cost and when it needs to be finished.
Outside of these special scenarios agility often isn't needed and most of the time even counter-productive. ... But try an tell that to an industry gone crazy, filled with idiots. *sigh*
Two cents from a scrum master and consultant.
And no, I'm not certified. Screw that bullshit.
We suffer more in our imagination than in reality. - Seneca
There are two reasons for this.
One is that Agile (tm) is largely BS. It's more well marketed than it is a true programming discipline. There's only a relatively limited segment where Agile (tm) is relevant. It's only recently that Agile (tm) has become popular and it's definitely not replacing what it claims to be replacing. 9 times out of 10 it's actually replacing processes that were often more agile and flexible than Agile (tm). Don't get me started on things like the useless and vague role of scrum master where you pass the qualification simply if you attend.
Agile (tm) does sometimes replace processes that are too chaotic. More often or not unfortunately people are adopting it more out of bandwagonning. The number of times I've seen managers shoehorn in Agile (tm), then you ask why and they say "it's better than waterfall" which is something astonishing to hear from managers when your company has never done waterfall. I have never seen waterfall used in my entire career. Every company I've seen in my career has tried to adopt Agile. Every company I have see do so has stated that it's because it's better than waterfall. I hope this makes it abundantly clear what's really going on with Agile and it's spread. Most of the time it's replacing the fact that managers have no idea how their development processes work. Most of the time they will not even visit the developer floor to bother to talk to anyone to ask. If you do tell them they disregard it anyway. If you do switch to Agile you end up violating strict rules put in place because of business needs and end up working agile just as before, or the business crashes.
Another problem compounding this is that competence in the technology industry at large is lacking. It's a growth industry with a massive supply deficit which means onboarding the best you can get even if they're barely adequate.
A company philosophy won't work if people are idiots and use it to serve their own agenda. News at 11.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
I've been at several places that claimed they were Agile. A few even had a designated scrum master who'd been to training.
Not one really followed through: I've sat through hour long "standup" meetings, had a sprint's worth tasks assigned by managers and shifted around day by day, had constant interference ("Why aren't we under that line on the burndown chart?")
This plays right into the hands of the Agile inventors, who can point to any misstep and say we aren't doing Agile right, if/when it fails. Agile, like many other buzzwords, was at least partly invented to sell books, get tenure, and make gurus immune to outsourcing.
It actually can work, encapsulated at team level, with a lead who coordinates with other leads and excludes higher management as much as possible. The key is for velocity, etc., to never leave the team, only finished work.
So basically we have a community complaining that not enough others have discovered their obvious superiority and what to do about it? Agile has its place, but I think this attitude of 'agile is the way' is one of the reasons a lot of developers avoid it.
According to Scrum.org, a big part of Agile competence is understanding what the entire point of Agile is, and it's NOT supposed to make development faster or cheaper.
The point of Agile and Scrum, according to an article on Scrum.org, is to provide a way to deal with situations where you can't go sit with users to understand what the actual requirements are, and you can't look at some legacy system you're replacing, so you have no way of defining the requirements except "try something and ask users if it's getting closer to what they want." Scrum is a system to quick iterate through different things, presenting each possible deliverable until you get close to what users need.
If you CAN go sit with users and take notes as you watch them work, if you CAN look carefully at the system you're replacing, if you have any way of defining requirements before you start coding, Agile iterations will take LONGER than just defining the requirements and then building something that meets the requirements (while being conscious of boxing yourself in, because next year requirements may change a bit).
Because, 90% of the time, Agile is nothing but a fucking band-aid over bad planning and a buzz-term thrown around to attract inexperienced or unwitting fucks into working somewhere. A 15 minute meeting to talk to each other everyday is an excuse not to talk to each other the rest of the day, to half address things because of time and move on, isn't going to do shit. It discourages communication and actually getting shit done. Sprints too are bad for company and employee, for high performers they limit the amount of work they can do in a period of time because the success is binary, you did exactly what you planned or you didn't. It hurts the company because employees are less productive than they could be "gaming" (consciously or not) the success metric.
If you facilitate open communication, give people problems to solve not solutions to implement, and plan properly the reasons for Agile are gone.
Only 12% percent responded that their organizations have a high level of competency with agile practices across the organization, and only 4% report that agile practices are enabling greater adaptability to market conditions...
So if we look only at the organizations that have a level of competency with agile practices, 2/3 of them report those practices do not enable greater adaptability to market conditions. That should give second thoughts to anyone thinking of following their lead.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Every magic bullet with any claim to success devolves onto the same success factor: hiring better people, under progressive management.
This why many magic bullets enjoy their 15-minutes of fame, but few magic bullets scale broadly beyond those happy beginnings.
The underlying scarcity is probably incentive alignment: it usually takes a rare syzygy to gather together the best groups.
A Solvay Conference is not in the pyramids any old century.
Even then, there's always some slack-assed Jules-Emile Verschaffelt in the room, to screw things up.
There is much discussion on why scrum sucks at:
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
Did you not read where I said eventually I landed in Wall Street? Happily enjoying developing trading systems through my business. Sorry my blunt style offended you.
PS I'm not handsome, or diplomatic. May be the years in Detroit first showing a bit.
To be fair, diff dev personalities work better under diff environments. Some have good analysis skills but are sloppy or slow coders, some great coders have crappy team skills, and so on. Some prefer being micromanaged, some hate it. Hiring and/or filtering for like-minded can work, but be honest as an org about such a goal to avoid debilitating friction with non-matches.
The process is flawed when "Done" has multiple definitions.
There is more than just agile. These statistics aren't shocking at all.
I do not think it means what you think it means.
If you really understand the heart of agile, truly get what the manifesto means, you would find phrases like 'agile practices' or 'agile processes' oxymoronic.
But, at least now I understand why all the Indian body shops have been hunting for 'agile coaches' in the last few months.
Talking with users was not valued in the waterfall process because of the reasons you laid out. Hence, shit software. I think the main point of Agile was fooling people into talking to users without saying it directly.
I object to power without constructive purpose. --Spock