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!
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 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
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.
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.
Seriously, itâ(TM)s a bunch of snake oil. Get over it and learn to shop a product.
The most productive development shops I've ever worked at had managers who couldn't read a line of code and didn't attempt anything remotely agile-like, or care about the certifications.
Nothing good ever comes out of a manifesto.
Those who do not learn from commit history are doomed to regress it.
"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.
I made a post, so I can't mod, but I just wanted to say I really appreciated your long writeup and agree with the general observations and that the balance usually collapses.
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 same goes for developers who have never managed anything, believe me.
This is a thing a lot of people miss, a leader who believes they're a manger is every bit as shit as a manager who believes they're a leader. In the case of a manager attempting to lead it might even be easier to stop them from damaging things because nobody takes them seriously, while in the case of a leader attempting to manage they will be able to actually sway people and completely miss every target be it abstract or refined. The two types of thinking simply don't cohabitate in the same mind at the same time (though the illusion that they do/can is often there for the person attempting it.)
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'.
"accelerating the speed of delivery of high-quality software" aha. Typically, speed and quality are somewhat mutually exclusive.
There's one problem with Hayek's analysis: Many democratic states in western Europe nationalized various industries at various times - exactly the thing which Hayek said would send them down the inevitable path to economic serfdom - and then a couple of decades later they voted to privatize. His prediction about the inevitability of political arrangements arising from economic arrangements was as wrong as Marx's was.
And there's one problem with your analysis: The majority of us people who earn things prefer to live in a society where those who need it are taken care of. We're willing to pay taxes toward that, and we're willing to support the minimal coercion that's needed to make sure all earners pay their share. We disagree about how much we should pay, and that's why we have multiple political parties; when the majority wants to pay a bit more, we elect one party, and when the majority wants to pay a bit less, we elect another party. But the vast majority of people - including the vast majority of "earners" - vote for one party or another that supports some level of redistribution.
"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.
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.
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
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.
We're willing to pay taxes toward that, and we're willing to support the minimal coercion that's needed to make sure all earners pay their share.
It's the second part of that which is the problem. It's "I want to be generous with other people's money".
You want to pay? Go right ahead. But what gives you the right to decide that others need to pay also?
Your rationale is no different than the ones given by the USSR. From each according to his abilities to each according to his needs. So let's work the productive members of our society to death, and give the fruits of their labours to those who do nothing.
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).
I'd agree that there's an overlap in intent (and justification for violence!) between democratic socialism and Bolshevik socialism. But if you look at which regimes (actually, literally) worked people to death, you'll notice that it was those which had extreme ideas about property rights - libertarian 19th-century Great Britain, and dictatorial Soviet and Chinese regimes. I'm comfortable partway between the two, with a lean toward the Brits. (They did work people to death, but a lot less than the Soviets.) In practical terms, democratic socialism has resulted in the smallest number of people being worked to death, and that seems like a pretty good metric to me.
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.
"It's going to take a month to do what i can literally do in 2-3 days."
Welcome to the institutionalized grind we call corporate America. I have to assume upper management knows this but chooses to just look at the income statement and balance sheet and figure out how to spin it at the board meeting...much easier.
I object to power without constructive purpose. --Spock
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