Survey Finds 'Agile' Competency Is Rare In Organizations (sdtimes.com) 270
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 takes a rare group (Score:2, Insightful)
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
Re:Agile takes a rare group (Score:5, Insightful)
Agile, or more specifically Scrum is pointless. When you have a daily stand-up meeting that can take six hours while the Scrum master chastises, badgers, yells, and excoriates people, one by one, for not making deliverables. During this everyone else is pointing at someone else and saying, "I'm blocked... he did it!". This isn't productivity; it is a game of kangaroo court.
Then the Scrum master tosses more crap on people's swim lanes at random (because marketing wants them done, and because they make the sales, they get what they want, without challenge), without really knowing or caring how difficult the task is. Finally the Scrum master closes the meeting with how everyone has been in a sprint for the past year, and says the sprint will continue until marketing is happy.
I do not see Agile adding any productivity whatsoever. It turns a dev team against everyone else, which may be great for management, but it creates a workplace that is at best hostile, and at worst toxic, because every day you have to go in and defend yourself against everyone in a multi-hour blamestorm. Eventually the good people leave for greener pastures.
Re:Agile takes a rare group (Score:5, Interesting)
Agile, or more specifically Scrum is pointless. When you have a daily stand-up meeting that can take six hours ...
Well... Daily scrum meetings are *suppose* to only be 15 minutes, but either (a) they aren't and are a waste of time (as you described) or (b) actually are and are a bigger waste of time. What it does ensure is that everyone is micro-managed into being at (or dialed into) that meeting every day at, like, 9:30am -- even though many (most?) companies have "flextime" -- 'cause management loves managing people.
Look. I *imagine* these meetings could be useful if you have a team of inexperienced people that need constant "guidance", but otherwise, working with experienced, responsible people, I've never run across anything that couldn't be more simply handled with emails to the appropriate people *if* something *isn't* on track.
Re:Agile takes a rare group (Score:5, Interesting)
In the Agile/Scrum environments I worked at, it wasn't handled by E-mail. Calendar appointments would magically appear, because the Scrum master, PM, manager, team lead, and backup team lead all had delegation authority to add meetings without approval, and these were "The Apprentice" like boardroom confrontations that lasted for hours.
I'm glad I'm away from that. My current place uses a modified waterfall model, and it works quite well, with projects getting done on time.
Re:Agile takes a rare group (Score:4, Interesting)
Welcome to the 88% that don't do agile correctly.
I've worked in a shop which did, and it was honestly amazing. The company embraced it, institutionalized it, and ensured that they had the expertise to do it right.
Daily standup was great. No more than the team and 1-3 product owners or managers in the room, 10 people, 1 minute each. What did you accomplish yesterday, what are you working on today, and any issues you're having or expecting. That was it. And the scrum master kept people from going on and on - two guys would regularly get "your minute is up" warnings, and everyone learned to make them as uncomfortable as possible or just start their 1 minute talk over top of them because standup was serious business.
What happened in there was that everyone on the team knew who was going to be touching what, and that lead to either avoiding code that was going to be touched or collaboration when two members were working on related stuff. The team leads and more experienced members could pinpoint where the newer members were getting stuck and help them over humps, or steer them away from bad coding decisions. (Outside of standup, of course.) The product owners got a thermometer on what was getting done, so they could update their roadmaps and tell the bosses, marketing, and other people what was going on. That meant the developers didn't have to waste time dealing with those people.
It also meant that sprint planning meetings were done with a broader institutional understanding of the current state of development, which tended to lead to more reasonable sprints.
Overall, it was a well-oiled machine, and it was very productive. In great part it was because the head of IT effectively used the agile framework to shield developers from institutional stupidity. When 10-15 minutes of your morning is all that management gets to waste of your time, you can get a lot done. It meant they all felt included in the development process, and had a structured way to interact with the devs rather than just calling random meetings and dragging everyone away from their work. And by having product owners closer to the work, they could answer the questions that management wanted, rather than the developers doing it.
I'd happily work in an environment like that again. What people normally describe agile to be like, however, seems to be a nightmare.
Re:Agile takes a rare group (Score:4, Insightful)
Daily standup was great. No more than the team and 1-3 product owners or managers in the room, 10 people, 1 minute each. What did you accomplish yesterday, what are you working on today, and any issues you're having or expecting. That was it. ...
What happened in there was that everyone on the team knew ...
While presumably a nice idea, it's still a waste of time. Everyone on the team doesn't *need* to know what everyone else is doing - and certainly not every freaking day. It's simply a way to ensure everyone is working like the busy little bees management wants. Team members don't -- and shouldn't -- interact with everyone else on the team; that's inefficient. Perhaps getting everyone together is appropriate for milestone events, but there are better, more flexible and productive, ways for people to interact as needed in normal situations. This becomes more true as people become more experienced -- said with 30+ years experience.
Re: (Score:2)
Re: Agile takes a rare group (Score:2)
Agile is not scrum. What you describe is neither.
Re: (Score:2)
Ever notice how all that stuff focuses on management techniques and none of them focus your engineering talent or processes? You know, the stuff where the actual work is getting done? If your engineering teams are
Re: (Score:3)
When I was involved in Agile, it was indeed pointless. It was in a major bank, and basically descended into institutionalised micromanagement.
It was pretty horrible, and I hated it.
There was no opportunity to spend time to actually think about things, it was all rush, rush, rush.
The is a saying "More haste, less speed", and I think it applies here.
Re: (Score:2)
Agreed. I would actually like to see something other than a permanent sprint, as that is supposed to be a tool for a definite goal, but it seems all the Agile places I was at always are in a sprint state.
Re: Agile takes a rare group (Score:2)
Well that's dehumanizing.
Re: (Score:2)
The problem with "Agile" is that it's not.
I'm working in an organization that now tries to go the "Agile" way - by doing a lot of things backwards and throwing away process parts that do work at the same time. And the organization starts to work with "Sprints" so nothing gets done until it's put into a "Sprint" instead of starting to work on issues one piece at a time. Every "Sprint" is started with a gigantic meeting with no concern for being optimal wasting man-hours on talk that only concerns 10% of the
Re: (Score:2, Interesting)
Very few of the proponents of "Agile" seem to have actually read and understood the Agile Manifesto.
Where I work, the introduced Scrum about 2 years ago. We were more agile before that, but our process, which was well adapted to our situation, didn't have a name since it had evolved internally (together with the customers) for about 10 years. We made a mistake not to connect a buzzword to it.
The output has dropped considerably with Scrum, much because of the planning meetings, but also because of the treatm
Agile and Scrum Are Like Communism (Score:5, Insightful)
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!"
Re: (Score:2, Interesting)
I thought it was more of a cargo cult. Do the right motions, and the gods will reward you with deliverables.
Re:Agile and Scrum Are Like Communism (Score:5, Insightful)
With that said, and reading the comments here on
Re:Agile and Scrum Are Like Communism (Score:5, Insightful)
Agile's biggest problem is that it tends to turn out systems that are dirty snowballs. Gluing bits and bobs onto a system using Scrums and Sprints as a filtering device only encourages the bits and bobs becoming unglued later as the system wavers on its rickety foundations. And even the term "sprint" is a term to keep the entire "team" working as if it were always running the last few yards of the last leg in a relay race. Micromanagers using it are telling their people in precise terms they think the people are lazy dolts who require constant needling and pushing to produce. The people get that message loud and clear, and will find ways to push back.
And Scrums are a godsend for micromanagers who think ordering their flocks daily activities is somehow managing. The point scoring is also tailor made for micromanagers to show their bosses how "much" progress is being made..."Lookee here, see this magic number". Those numbers are pink unicorns and pixie dust to micromanagers.
Re: Agile and Scrum Are Like Communism (Score:5, Insightful)
What I see are a ton of Agile shops turning out crap, and Agile Evangelists handwaving it away with the excuse that "it's not being done right."
Well if 90% of the places can't do it right, then it's not really a useful system, and all those Scrum Master Certificates are worthless.
The primary purpose of Agile seems to be selling Scrum Certs, loudly defending the model in order to sell more training, and getting Scrum Masters to loudly defend their decision to dump a pile of money on a Cert which is effectively useless.
Re: (Score:2)
What I see are a ton of Agile shops turning out crap, and Agile Evangelists handwaving it away with the excuse that "it's not being done right."
Well if 90% of the places can't do it right, then it's not really a useful system, and all those Scrum Master Certificates are worthless.
Well if 90% of people can't do exercise right, then it's not really a useful system, and all those Fitness Coach Certificates are worthless.
Well if 90% of people can't eat properly, then it's not really a useful goal, and all that education about food is worthless.
Good grief... the lack of logic and insight here is astounding!
PS. The certification part is a whole separate issue.
Re: (Score:2)
Agile is fundamentally a consultancy methodology, with an effective sales pitch. The true goal is to offload project risk onto the client, especially one who doesn't actually know what they want. The negotiation goes a bit like this:
Our job is to help you figure out what it is that you want. You give us some ideas, you pay us for a month, we go away and build something then bring it back to ask if this what you indeed wanted, we get your feedback and you can keep paying us again for next month. You don't ne
Re:Agile and Scrum Are Like Communism (Score:5, Insightful)
The problem with implementing Agile the right way is simple: it's too hard.
Management absolutely hates facts like:
1) Each team must do their own estimates, and estimate numbers are not comparable between teams.
2) Early estimates cannot be treated as commitments, especially since they are wildly inaccurate (due to lack of key requirements).
3) Changing requirements comes with the consequence of changing the costs and delivery dates.
4) Velocity cannot be used to measure productivity.
Their hatred of these facts is so deep that they will always reach in to any well-formed agile process and break it in a misguided effort at escaping these facts.
Business Analysts fall into similar traps, either treating agile as an excuse to go hog-wild with requirements changes, or sticking with waterfall planning processes and not understanding why that doesn't just work with an agile process.
Developers fall into traps too, sometimes thinking that Agile means they will never have to push to hit a deadline again, or that they need to have a higher velocity than other teams to look good, etc.
So, in sum, Agile actually can be done right....just not by humans.
Re:Agile and Scrum Are Like Communism (Score:4, Insightful)
I particularly struggle with management on estimates. I insisted that for 70% of the work, we don't need projections, and that allows us to properly focus on the minority of work that has *real* deadlines. Management feels like if you don't know when you'll get to it, and no one is specifically going to be looking for the delivery, why would we do it? So we end up with BS no-one cares stuff effectively blocking sudden and important real requirements because we are flagging stuff as 'need to do in three weeks time because someone demanded a random guess'.
Re: (Score:2)
If no one is specifically looking for the delivery, why in the world would you do it? It sounds like it's not a priority to any user.
The important reason to estimate work in advance is because it lets you align budgets with objectives and schedules. The estimates need to be somewhat reliable, so you need to do them often enough that you can get them right. As a side benefit, grossly wrong estimates are a sign to ask what went wrong, so you can do better next time.
Re: (Score:2)
Sometimes you have things that people have asked for, but you did not make a commitment for. They want it, but they are not *expecting* it per se.
Also there are things where the users are unhappy about something, but unable to conceive of how it could be better and are resigned to think of it as a sad reality and thus are not expecting change for the better.
Also if you are going to cover more breadth of function and take on responsibilities that the users would not have thought of at all.
Contrast with havi
Re: (Score:2)
Agile and Scrum in real life .. (Score:2, Insightful)
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
Re:Agile and Scrum in real life .. (Score:5, Insightful)
I have said point blank to my management that I don't *want* a team of 50 programmers they 'help' get for me, I want 4 or 5 programmers I actually vet. This makes no sense to them, because more people == better, but in software small teams almost always do better.
Re: (Score:3)
More people look better when you show the org chart to investors. That's all.
Re: (Score:3)
Lower wage bills look bloody fantastic when you show the accounts to investors.
Re: (Score:2)
Re: (Score:2)
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!"
So it's exactly like socialism, christianity, anarchism and RS-232?
Re:Agile and Scrum Are Like Communism (Score:4, Informative)
Re: (Score:3)
I remember when Agile was called XP. That was before the seminar and certification industry got hold of it.
XP made sense, but only by comparison with what came before it. If there's one thing I've learned after 25 years in this business, it's that fundamentalists make shitty products.
Re: (Score:2)
There are two success criteria for a methodology:
* how big of an advantage it provides if implemented correctly
* how easy it is to get it implemented correctly in practice
That second part is really all the difference. I've seen pretty amazing results of agile methodologies in my practice with the right crowd, but most of the time it's not even about *hiring* the right crowd, it's about *having stakeholders buy* into agile first, a step that is often conveniently skipped by agile evangelists.
Re: (Score:2)
All these software methodologies are basically doing the same. They wrap up a few obvious truths of development (deliver what the customer wants on time) into aphorisms, rituals, dogma, mantra etc. and expect people to blindly follow it if they want
Re: (Score:2)
Yep. And if almost nobody can make it work in practice, it's not a good method, regardless of the shining successes you can point at.
Re: (Score:2)
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!"
Agile is not communism. [agileadvice.com]
Exercising sounds great in theory, falls apart in practice, and there will always be someone who says, "You just didn't implement it the right way!"
Eating healthy sounds great in theory, falls apart in practice,...
Just because a thing is hard to do or commonly not done well does not mean that the thing itself is bad, wrong, or irrelevant.
Re:Agile and Scrum Are Like Communism (Score:4, Informative)
I have seen weeks where the entire 40 hours were all Agile/Scrum related meetings. This meant that there was no significant coding done whatsoever.
In all of my IT work, I have never understood why some managers think that calling meetings will enhance productivity, and if that doesn't work, call more meetings. I don't know if this is incompetence, or an issue with ego. Either way, it hamstrings actual productivity.
Re: (Score:2)
I have seen weeks where the entire 40 hours were all Agile/Scrum related meetings. This meant that there was no significant coding done whatsoever. In all of my IT work, I have never understood why some managers think that calling meetings will enhance productivity, and if that doesn't work, call more meetings. I don't know if this is incompetence, or an issue with ego. Either way, it hamstrings actual productivity.
Trust me, you can do that without being "Agile", where the team is constantly micromanaged and have tasks piled on by tons of different people. The former has a lot to do with the latter because priority is given to those who keep nagging the developers to do something. Which is often not the big boss who really should set the priorities, because he's too busy for that. Calling in more meetings is trying to "up the volume" of their issue, like it steals a bit of time but hopefully they get a bigger piece of
Re: (Score:3)
I have seen weeks where the entire 40 hours were all Agile/Scrum related meetings. This meant that there was no significant coding done whatsoever.
Then you weren't doing either agile or scrum. The only routine "meeting" should be the daily scrum; 15 minutes max - what did we complete yesterday, any problems (team blockers) that need to addressed, what are the priorities for today? If you are not spending 90%+ of your time working on producing the software, then you're doing it wrong.
In all of my IT work, I have never understood why some managers think that calling meetings will enhance productivity, and if that doesn't work, call more meetings. I don't know if this is incompetence, or an issue with ego. Either way, it hamstrings actual productivity.
Traditional management types really don't like agile because - budgets and time-sheets aside - there is not much for them to do. The team manages itself on a day-to-day ba
Re:Agile and Scrum Are Like Communism (Score:5, Insightful)
But that's the problem. You can say, "Well, that's not Agile", but so many attempts to do Agile wind up like this. If the method seems to create problems in implementing it, it's not a good method.
Re: (Score:2)
But that's the problem. You can say, "Well, that's not Agile", but so many attempts to do Agile wind up like this. If the method seems to create problems in implementing it, it's not a good method.
In my experience the problem is not with the method, but with people assuming that because it's "agile" you can just come in one Monday morning and say "Hey, we're agile now!", like in the Dilbert cartoon. First, you have to pick which agile approach you are going to adopt, e.g. Scrum, Kanban, XP; there is no generic "agile". Then, you have to make the people and organisation investments to adopt your chosen approach properly. You can't blame the method because some development shops don't do the necessary
Re: (Score:2)
What I don't get, and it applies to so many people posting in this topic, is why people accept this.
Just turn down the meetings. Take ownership of your own productivity. Educate and train your manager. Learn how to fucking run a project without needing a project manager. Constantly assess what you're doing and how to improve it, and work as a team to do exactly that.
Too many people that think their job is programming then blame other people for the poor processes they follow. Be more professional!
(not targe
Re: (Score:2)
So why don't you compare North Korea to South Korea then?
It's weird, the Communists are all about equality... so they set up dictatorships. We're supposed to be suspect of all the power from money being in one place, but it's no big deal when they set up yet another dictator with all the political power to implement Real Communism this time?
That's the thing you guys just don't get, giving some random dude unchecked power because they promise that this time you'll get Real Communism (TM) is virtually guaranteed to turn out badly. Even for you who support it--the worst thing to them is the evil heretics who don't believe in exactly the right sort of Communism. You'll be the first ones sent to the gulags by the Glorious Communist Leader. And then after the country goes to hell, some new idiot will say the problem is that they didn't practice Real Communism.
For all the failings of capitalism, and there are many, you've managed to do consistently worse. If you want us to believe you, go move to a Communist country. Oh right, the only ones left are horrible. No wonder. Now why do you want to bring that here?
Nicely said.
Re: (Score:2)
If you read more than talking points you would realize that communism is an economic system, not a political one.
Actually, if you read more than the talking points, you would realize that communism is both an economic system and a political one. So of course there hasn't ever been a communist state, in fact it describes itself as stateless, meaning it has no borders, meaning it has no jurisdiction, meaning it has no rules or laws (and yes, all three of these are properties explicitly described.) The idea behind all of this is that capitalism causes all of the ills of the world, so the moment the whole world is communi
Re: (Score:2)
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 pre
Re: The best explanation was written long ago (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
You nailed it quite well. A manager can bury someone in processes, fill their calendar up with meetings, then turn around and say they are a poor performer via the metrics set (it could be deliverables, it could be per project, anything.) This reminds me of the Alice in Wonderland croquet game where the rules change dynamically.
Agile and Scrum are great for middle managers, because they look productive. However, as a benefit to a company or organization as a whole, it hamstrings productivity.
To think of
Re: (Score:2)
To think of it, I don't know anyone who is not a muckety-muck manager who -likes- Agile/Scrum.
I do. I've worked with many of them. I've been inspired by many of them. I've met them at conferences and read their books.
I've also tried implementing the things they do, adapted them to work in my environment and made a success of it. But that's because I can think.
Re: (Score:2)
I'm fascinated by this. How limited is your exposure to the industry?
I've worked with agile teams in the UK, Bulgaria, multiple parts of the US, France, Germany, Costa Rica, Malaysia and Brazil.
I wonder how they can repeatedly deliver quality software but none of the companies you've worked for manage.
AGILE is utter shit (Score:4, Insightful)
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.
Re:AGILE is utter shit (Score:5, Insightful)
If you think about it, back in the 90's, do you remember TQM [asq.org]? It spread like a frickin' religion across Corporate America. Every company from GE down to your local strip-mall-based franchise retail outlet preached the Gospel of Deming. The justification boiled down to pretty much the same thing: "This is why Japan kicked our asses back in the 80s! We need to implement this!"
Here's how TQM actually turned out: Some orgs implemented it beautifully. Some gave it lip service then ignored it. The rest picked out what they wanted and shit-canned the rest. Eventually most of it got ignored while a few good bits got absorbed or were mutated to meet the C-level's expectations of it (basically they neutered it except for the bits where they could take good ideas from the proles and claim them as their own.)
Pretty much like how Agile (and its bastard spawn, such as Kanban, etc) is turning out.
The more things change...
Re: (Score:2)
Re: (Score:3)
And people make fun of China claiming inventions from other countries.
Re: (Score:2)
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.)
Are you shitting me?
Why are we losing market share? Our competitors are releasing new features faster than we can keep up.
Why are we losing money? Our cost of change is eating up our margins.
Why are we being shut down by the regulator? We couldn't change the system to stay compliant.
I've seen these things at multiple companies, include a $700m IT write-off because the management team kept ignoring issues with the programme but knew they had to replace the legacy system because of all of the above.
Re: (Score:2)
"Why are we losing market share? Our competitors are releasing new features faster than we can keep up."
That's wholly your fault for not using your brain to think of what features your desired customer base might want. That's BASIC BUSINESS PLANNING ONE OH FUCKING ONE. agile would not have saved your lazy ass there.
"Why are we losing money? Our cost of change is eating up our margins."
Wait until you see how much money you're losing with all those useless meetings wasting man-hours.
"Why are we being shut dow
Re: (Score:2)
That's wholly your fault for not using your brain to think of what features your desired customer base might want.
It's quite hard to plan for internet banking when you're writing a core banking system in 1975.
That's BASIC BUSINESS PLANNING ONE OH FUCKING ONE
Is it fuck. Basic business planning 101 is 'Everything will fucking change'.
Wait until you see how much money you're losing with all those useless meetings wasting man-hours.
Who the fuck asked for lots of meetings? Not me.
Your fault for not starting with an extensible and flexible in-house framework.
Wait? You started by telling us to get it right in the first place, now you're telling us that we have to have flexibility? Make up your fucking mind.
Not to mention the excessive cost, performance challenges and systems management overheads of trying to be flexible and extensible.
Literally every problem you've just mentioned would not have been solved by AGILE. It would be solved with a proper fucking coding class.
Literally ev
Re: (Score:2)
Around the 90s is when software development was truly in its prime, despite the shit languages and lacking hardware.
Have you heard of the Software Crisis [wikipedia.org]? It didn't magically go away in the 90's. CASE, RUP, SDLCs, CMM/I, ISO, and project management were all trying to fix the software crisis... and didn't. Based on actual data, Agile is the only thing so far that has had an impact (albeit small):
1995 Data - 17% successful software projects (none "Agile"). [projectsmart.co.uk]
2015 Data - 11% successful with waterfall, 39% successful with Agile. [infoq.com]
Methodologies Are For Hacks (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Management and leadership styles need to depend on your team...
I disagree. Good management is good management. The best managers I've ever had were the ones that understood that their role was largely to structure work, and shelter the workers doing that work from the management above them. If someone is poisonous to the team, good managers figure it out and either mitigate that or get that person off the team.
Bad managers have workers sit in useless meetings. Good managers go to the meetings while the workers get shit done.
Sure, you need to modify your management styl
Re: (Score:2)
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 sa
This is actually good for agile believers (Score:2, Interesting)
Considering that agile is a giant scam to sell consulting, training, books, etc.... low adoption only means more customers to fleece!
Re: (Score:2)
Re: (Score:2)
Does ITIL stand for "Interminably Ticking Inconsequential Lists"?
Re: (Score:3, Insightful)
Anything good will invite bullshit artists to pretend like they can teach you how to do it. So the presence of crappy consulting, training, books, etc....doesn't automatically mean agile is in-and-of-itself a scam.
Much like programming, doing agile right requires above-average intelligence, specifically in one's ability to think abstractly and understand the process deeply. The agile community is brimming with people who only have a surface-level understanding of how it all works, and they ruin everything
Re: (Score:2)
If your team can "do agile right" on a project, it can probably be just as successful using almost any process. Conversely, most projects are harder with agile than with other processes. So there is seldom, if ever, a good reason to do agile -- unless Zed A. Shaw would think you're a bad guy.
bah (Score:4)
I love Agile (Score:5, Funny)
Agile is amazing. All of our competitors should adopt it.
First item on the Agile Manifesto (Score:2)
"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 th
Re: (Score:3)
Sorry, that went out the window when consultants saw money to be made. Processes and tools are big money makers. Telling people "just talk to each other" isn't enough to make a lot of money.
Re: (Score:3)
Quite possible. Fortunately I am a technology consultant, not a management one. So while I do not tell my customers processes and tools are mostly bullshit, I sometimes have a chance to demonstrate it. Of course, a high daily rate helps because then they take you seriously. But overall, I think you are quire right and it is the reason why corporate IT typically is a mess and often going for a train-wreck. We have customers that cannot even implement basic things anymore because their IT is so wrecked by con
Re: (Score:2)
Too many engineer are wimps that cannot tell management how things really are.
Or they gave blunt honest feedback before and got fired for not being a "team player".
Agile was doomed by the name (Score:4, Interesting)
Re: (Score:2)
The name would have doomed it, project managers love the buzzword, love self-affirming that they are 'formally' 'Agile', and they also love making things unidirectional. They love using tools instead of interactions, because a tool can allow for measurement, but conversations are so much more subjective.
Never mind that delving deep into the subjective nature of the work in my experience always leads to *much* better work and it being *much* easier, management doesn't have any metrics, so they don't like it
Re: (Score:2)
"Conversational development? So you think standing around talking all day will get the project done? You're fired!"
And that's why it's called "agile" rather than "conversational".
Management likes metrics (Score:2)
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+
Re: (Score:3)
Add to that knowing *precisely* what people will be doing 6 months from now. Yes I know this is nominally exactly *not* something advocated in the words of Agile, but because so many in management demand it, the consultants have found ways to present epics with stories planned for months as still 'Agile' to collect their check and let the company have warm self-affirmations that they are now 'Agile'.
In addition to metrics, they have the hope that applying project management can magically allow them to use
The reality.. (Score:2)
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 tr
Organizations find agile is garbage (Score:2)
Seriously, itâ(TM)s a bunch of snake oil. Get over it and learn to shop a product.
History repeats itself. (Score:2)
Math (Score:4, Insightful)
"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...
Re: (Score:2)
Traditional IT project management (sometimes called "waterfall") produces successful results less than 20% of the time. Agile is an improvement over that. Check out the Standish Group's Chaos Report for 20+ years of data on this problem.
Agile' is mostly just 'We're lazy and incompetent' (Score:2)
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 b
What is this Agile? (Score:2)
Speed AND quality you say.. (Score:2)
Sacrosanct Schedules (Score:3)
"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.
Waterfall organization undermine Agiles feedback (Score:2)
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
agile is dead (Score:2)
Dave Thomas gives his reasoning:
https://www.youtube.com/watch?... [youtube.com]
Survey (Score:2)
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.
Agile is nonsense. Agility is the goal. (Score:2)
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 meth
Fake news (Score:2)
Agile might work...if tried (Score:2)
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, l
*headdesk* (Score:2)
Re:No one actually does this, it's just me-too wan (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
Oh dear... Coding is easy, finding people who can code and work effectively in a team is hard.
That's what's important.
And... Coding is easy, finding people who can write bug-free code is hard.
Scrum just makes you build sh*t faster unless you are doing test-driven development, (proper) refactoring and (proper) continuous integration.
Knowing that Agile isn't SUPPOSED to be fast (Score:5, Interesting)
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).