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.

168 of 270 comments (clear)

  1. Agile takes a rare group by Anonymous Coward · · 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

    1. Re:Agile takes a rare group by Anonymous Coward · · Score: 1

      We were doing agile well for a while, when the tech team was administering it themselves.

      But the company grew. We are now full of people that think that velocity measures productivity. Every bad thing that comes of that is coming of that.

      My conclusion is that doing Agile right requires more than sitting through training. The ones administering it really have to be smart. They really need to get it, on a deep level. A surface-level understanding results in cargo cults and chaos.

    2. Re:Agile takes a rare group by ctilsie242 · · 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.

    3. Re:Agile takes a rare group by fahrbot-bot · · Score: 4, 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.

      --
      It must have been something you assimilated. . . .
    4. Re:Agile takes a rare group by Z00L00K · · Score: 1

      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 participants.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    5. Re:Agile takes a rare group by ctilsie242 · · 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.

    6. Re: Agile takes a rare group by Anonymous Coward · · Score: 1

      when you have management that feels like it needs to be able to look like it's, you know, "managing things" to keep the IT nerds in line, Agile is letting the inmates run the asylum.

      What, business and developers setting work priorities without management? thats crazy talk! So lets make sure we have daily standup...er status meetings. Lets be sure we spend time weekly or biweekly in time-sucking ceremonies...
      That being said, I've had experiences where the business owners were sharp, had buy-in from their management, and the devs were still able to deliver despite IT management's intentions, by working with the business owner. there was good feedback going both ways. Like it should be, Agile or not. People interested in simply getting things done.

      Other teams were not so lucky. Maybe scrum master was a legend in his/her own mind. maybe the team had too many chefs and no cooks. Maybe the business side could not change from old mindset of "throw it over the wall to IT", "how come it's not perfect", and/or "what, another delay?" (from yet another unspoken/undisclosed business requirement is revealed at end of cycle...)

      or "business analysts? we don't need no steenkeen business analysts! after all, when I was a dev I often was my own business analyst..." (-IT director)

    7. Re: Agile takes a rare group by Reverend+Green · · Score: 1

      Well that's dehumanizing.

    8. Re: Agile takes a rare group by ctilsie242 · · Score: 1

      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.

    9. Re:Agile takes a rare group by umghhh · · Score: 1

      Could this be that with size grows structure and thus complexity? Seems like a nature's own law? Suddenly you have external constrains that you did not have before. The growing size does seem to force hierarchic organizations all on its own. One way of dealing with it is practical i.e. do what is needed and the other ideological - do what is is in a book. Besides - naturally even if there are some individuals that are well fitting in the agile model there are also others that don't and work better in strict hierarchies. To each its own they used to say. Accepting reality is core to agile I thought but then ideology can disturb perception so much that there is no way you can act on facts. This is seen in so many different areas of human life that the q. why would it not infiltrate agile model does not even need be asked. A the end the only q. is: do we do our project in efficient enough way? But the IT seems so reach body for all the ideologies today then better not ask too many questions. You may be slapped in the head with new 'no ideology' ideology and that can be painful.

    10. Re:Agile takes a rare group by Anonymous Coward · · 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 treatment of all the developers as "resources" instead of individuals. So instead of letting the team divide the work between them as they see optimal, everyone now has to work on all parts of the system regardless of knowledge or ability (this is a big system). So far no sprint has resulted in a working release and every sprint starts with tasks to make the previous release work. The testers are upset because they don't get _anything_ from the team until the last days of the sprint, whereas we used to have a constant flow of work to test (and subsequently release).

      I guess Scrum can be an improvement if the organisation is completely non-agile from the start, but for us it was a great step backwards.

      True agile development is wonderful, but management has to let go of some control for it to work properly, which is why we get "Agile" instead.

    11. Re: Agile takes a rare group by Anonymous Coward · · Score: 1

      Everyone feels treated like Dilbert and thinks they are Alice, but really if you are here you are probably Wally.

    12. Re:Agile takes a rare group by marcjps · · Score: 1

      you don't have scrum - the scrum master's role is to help the team apply scrum. yours isn't doing that, he's being the usual "pretty bad project manager", pushing the development team around reactively when he'd be better off leaving the scrum team to plan their stories, while he greases the wheels between the devteam and the organisation/client.

    13. Re:Agile takes a rare group by PmanAce · · Score: 1

      Your team is pointless if it takes that long, agile/scrum is an easy concept. We use it for our big projects and everything is fine. The only thing that irks me is people use poker points in hours and not complexity.

      --
      Tired of my customary (Score:1)
    14. Re: Agile takes a rare group by famebait · · Score: 1

      Agile is not scrum. What you describe is neither.

      --
      sudo ergo sum
    15. Re:Agile takes a rare group by apoc.famine · · Score: 3, 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.

      --
      Velociraptor = Distiraptor / Timeraptor
    16. Re:Agile takes a rare group by fahrbot-bot · · Score: 3, 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.

      --
      It must have been something you assimilated. . . .
    17. Re:Agile takes a rare group by Greyfox · · Score: 1
      Like all the other managerial processes, it's just another silver bullet sold to your company (Along with training and tools to the tune of several hundred thousand dollars,) that will magically fix all your software development problems if you just take the time to learn it and do it correctly.

      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 really broken, it doesn't matter how well you manage them. So let's say you're sitting in a dysfunctional turd of a company. I mean a really bad one, the type of company where the only people still working there are the people who absolutely can't find a job somewhere else. Now let's make that company agile. Will that actually solve any of their problems? No, it'll just pay to send some agile coach's kids to private school.

      --

      I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    18. Re:Agile takes a rare group by SimonInOz · · Score: 2

      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.

      --
      "Cats like plain crisps"
    19. Re:Agile takes a rare group by sjames · · Score: 1

      The problem is that Agile, like most management fads is based on observing the interactions in a few rare highly productive teams of unicorns.

      Of course, being management based, they remove all elements of the spontaneous nature of the teams organization and turn lose guidelines into hard rules.

      Like the semi-mythical island cultures who believed that by building a bamboo mockup of a runway and tower, they would cause the planes full of magical objects to return, they expect that by dictating the form, the managers can cause the average dev team to turn into unicorns.

      When it fails to produce stunning results, the whole thing devolves into arguments over who has failed to understand the scripture in their holy book of choice.

      It simply HAS to be that someone isn't following the micro management to the latter because it CAN'T be management's fault.

    20. Re:Agile takes a rare group by Kielistic · · Score: 1

      Team members don't -- and shouldn't -- interact with everyone else on the team; that's inefficient

      Then why are they on a team? Perhaps you've just never worked on a team of more than three people or on a tightly coupled codebase that is very easy to step on other peoples toes without knowing it.

    21. Re:Agile takes a rare group by Gr8Apes · · Score: 1

      I'm not sure what hell you work in, but I can assure you Waterfall, for one, really does exist and was used successfully more often than you might think until the bastardization of Agile went through Software development management like an extra large Chipotle burrito. Note that I personally use a looser variation of waterfall tuned to smaller faster deliverables, but it's not "Agile" as I actually do deliver.

      --
      The cesspool just got a check and balance.
    22. Re:Agile takes a rare group by Gr8Apes · · Score: 1

      Welcome to the 88% that don't do agile correctly.

      88%? I'd still say that this company failed to do it right and that it wasted at least 5 man-hours of time a day so we're still at 100% (I'm assuming you've had experience with 9 jobs with agile and can't round correctly ;) Why? Because you don't just hop into a meeting and back out without it disrupting what's most likely your most productive part of the day. You also don't go back into coding full tilt after a 15 minute interruption. And if you needed 1 minute to describe 3 lines that could have been sent via email, well, what's the point of the meeting? Conversely, if you're stuck because of something, why wait for a meeting to get help? That's a waste of potentially another day. And the real point here is that most of the team doesn't care or need to know, but the "management" does, and they're using this vehicle so they don't have to go round and actually talk to their team members.

      what people normally describe agile to be like, however, seems to be a nightmare.

      your description only highlights how much of a time sink useless scrum meetings are. I've never been anywhere where scrum didn't negatively affect a project's timeline. Even in the one place that did far more positive things with Agile than your situation and really only allowed the management to stay on top of the team's progress. It did not help the team achieve anything they needed to do, project resources needed, or really anything other than force management to prioritize certain features over others which any competent team lead / project head would do regardless.

      --
      The cesspool just got a check and balance.
    23. Re:Agile takes a rare group by fahrbot-bot · · Score: 1

      Team members don't -- and shouldn't -- interact with everyone else on the team; that's inefficient

      Then why are they on a team? Perhaps you've just never worked on a team of more than three people or on a tightly coupled codebase that is very easy to step on other peoples toes without knowing it.

      I have and when things are well designed -- code and team -- no one is, or should be, stepping on any toes. Teams are for things that are too big for one person, or require more skills and experience than one person can provide, in the time allotted. Delegation and compartmentalizing are important.

      --
      It must have been something you assimilated. . . .
    24. Re:Agile takes a rare group by Kielistic · · Score: 1

      I have and when things are well designed

      There's a weasel statement if I've ever seen one. If the code is "well designed" why should anybody be touching it in the first place?

      Delegation and compartmentalizing are important.

      Which is why communication is important. I am seriously perplexed by your assertion that team members should not interact or communicate with one another. I'm thinking we have very different definitions of what "team" means.

    25. Re:Agile takes a rare group by hondo77 · · Score: 1

      When you have a daily stand-up meeting that can take six hours...

      ...it's a sign that you're doing it very wrong.

      --
      I live ze unknown. I love ze unknown. I am ze unknown.
    26. Re:Agile takes a rare group by fahrbot-bot · · Score: 1

      I said that everyone doesn't and shouldn't need to talk with *everyone-else" on the team, not that they shouldn't communicate at all as needed. There's a difference and I'm perplexed that you don't understand that. Furthermore, even well-designed code can need various types of work - also perplexed that you don't understand that. I imagine you're being contrary and/or obtuse to just be so - or simply lack any real-world experience. In any case, I think we're done here. Cheers...

      --
      It must have been something you assimilated. . . .
    27. Re:Agile takes a rare group by Kielistic · · Score: 1

      I was being purposefully obtuse because stating what should happen when things are well designed is an asinine truism (blah blah, lacking real world experience blah blah). Teams should have a certain amount of cohesion: including, but not limited to, a basic idea of what others are working on. Otherwise it's not really a team. Peace bro.

    28. Re:Agile takes a rare group by david_thornley · · Score: 1

      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.

      This is not evidence that Scrum doesn't work, in much the same way that unrestricted cowboy coding isn't evidence that Waterfall doesn't work. This is evidence that people can do all sorts of stupid things and call it something else.

      I've seen Scrum done right, and it worked great. The people involved were also great, so, to be honest, I don't know if it would have gone as well with other methodologies.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    29. Re:Agile takes a rare group by david_thornley · · Score: 1

      Because you don't just hop into a meeting and back out without it disrupting what's most likely your most productive part of the day. You also don't go back into coding full tilt after a 15 minute interruption.

      I've normally got things to do that require a lot of concentration, and things that don't. If I know that the standup is at 9:45 every morning, I don't start anything that requires concentration before then. At 10, I can start concentrating. If it's on a fixed schedule, people can work around it effectively. If it changes from day to day, or, worse, is unpredictable, it will screw things up.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    30. Re:Agile takes a rare group by Gr8Apes · · Score: 1

      I've normally got things to do that require a lot of concentration, and things that don't. If I know that the standup is at 9:45 every morning, I don't start anything that requires concentration before then. At 10, I can start concentrating.

      So, essentially if you work a normal day, you're wasting 2-3 hours in the morning waiting for this thing to pass, get in maybe 2 hours of "concentration time" because then you have to break for lunch and well, you kind of get where I'm going with this by now

      --
      The cesspool just got a check and balance.
    31. Re:Agile takes a rare group by datavirtue · · Score: 1

      I agree that dailies are a waste but the rest of your comment is absolute bullshit and reflects a general shitty attitude. I have seen many problems and misunderstandings averted in a weekly standup.

      You may have had bad experiences but I don't think the format of the meeting was the problem.

      --
      I object to power without constructive purpose. --Spock
    32. Re:Agile takes a rare group by datavirtue · · Score: 1

      This is classic systems-over-people mentality.

      --
      I object to power without constructive purpose. --Spock
    33. Re:Agile takes a rare group by LQ · · Score: 1

      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 really broken, it doesn't matter how well you manage them.

      Ever come across the "There are no bad teams, only bad leaders" piece of management BS?

    34. Re:Agile takes a rare group by david_thornley · · Score: 1

      I'm not wasting time. As I said, there's things I need to concentrate for and things I don't. I need to do some record-keeping work, run tests, etc., and not all code reviews require real concentration. Given that all our meetings are in the morning, and adhere to a predictable schedule, there isn't a big problem.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    35. Re:Agile takes a rare group by DarthVain · · Score: 1

      Definitely not Agile though management might have called it that.

      We've been adopting more and more Agile.

      As it turns out, I've been doing more less a modified waterfall (with Agile components) for years before I even knew Agile was a thing, or it gained in popularity.

      Like a lot of management buzzwords, I think Agile it is often misunderstood, and misapplied. From my limited experience with the Agile training and associated projects, I would say that not all projects are really appropriate for Agile (I'd say many in fact). Not only that, but I don't think it is particularly effective at what it is supposed to do, and can only be if controlled very tightly, which in I'd say most cases it isn't.

      I'd say it does lend itself to more rapid application development (when controlled and interference kept to a minimum), however the cost seems to be incomplete and buggy systems. However this is by design rather than oversight, in that they *know* that it isn't complete, and that those 100's of bugs exist, but they are pushing what they have to production, and will fix the rest later so to speak. Always in the next sprint, to which other stuff comes up, and then it is the next, and so on. In the end you never really get completed, stable, solid software, but rather a living document that constantly needs development more less forever (which in a sense is also true for any system, but at least it isn't constant). It is a good way to keep developers busy and projects continually going.

      Anyway as you've probably guessed, so far my opinion of Agile isn't all that high. I have seen it work in very specific circumstances, but I have seen some messes as well. I think I prefer a modified waterfall myself, where you detail out as much as you can, though perhaps leaving some requirements less so because you are uncertain if some of the lower priority stuff is actually going to get done, while at the same time working closely with the developers to remain flexible about issues that come up that require adjustments and changes to the plan, which as mentioned may have an impact on proceeding or not with some of the items.

      One thing in the whole system life-cycle that Agile pretty much ignores (other than possible feedback and more work), are the users and the frustration they have with the partial buggy systems. They just want something that works, and constantly having them deal with it is going to frustrate them, and really make them not want to use it, which then can compound problems when they don't or try all sorts of "creative" workarounds that cause all sorts of strife later on.

      Anyway as someone else mentioned, the trouble with Agile is most don't do it properly because it is too hard (like Managers not butting out), and as such isn't very effective as a result. Also trying to apply it to all projects equally is just as silly as trying to force a round peg into a square hole... for the sake of "ITS AGILE!"

  2. Agile and Scrum Are Like Communism by DatbeDank · · Score: 4, 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!"

    1. Re:Agile and Scrum Are Like Communism by Anonymous Coward · · Score: 2, Interesting

      I thought it was more of a cargo cult. Do the right motions, and the gods will reward you with deliverables.

    2. Re:Agile and Scrum Are Like Communism by Anonymous Coward · · 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.
       

    3. Re:Agile and Scrum Are Like Communism by ctilsie242 · · Score: 3, 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.

    4. Re:Agile and Scrum Are Like Communism by Anonymous Coward · · Score: 1

      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?

    5. Re:Agile and Scrum Are Like Communism by sysrammer · · Score: 1

      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.

      --
      His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
    6. Re:Agile and Scrum Are Like Communism by Anonymous Coward · · Score: 1

      So why don't you compare North Korea to South Korea then?

      I'm not the AC that you responded to, but sure. South Korea has never been a Randian capitalist or libertarian nation. It was run by repressive military dictatorships from 1950 to 1997. In that sense, the countries are reasonably comparable.

      There's nothing about dictatorships that are incompatible with limited capitalism and a growing economy. See also: China.

      If you want us to believe you, go move to a Communist country.

      The AC you were responding to was not saying "Communism good". The clue was the words "same shit", which you may have either missed or not understood.

    7. Re:Agile and Scrum Are Like Communism by sheramil · · Score: 1

      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?

    8. Re:Agile and Scrum Are Like Communism by Pseudonym · · Score: 2

      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.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    9. Re:Agile and Scrum Are Like Communism by Junta · · Score: 3, 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'.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    10. Re:Agile and Scrum Are Like Communism by Anonymous Coward · · Score: 1

      Generally it's because that's pretty much all management is qualified for. A lot of times it boils down to protective camouflage on the part of middle management when upper management starts breathing down their neck. "My team is in panic mode! I spent a full 40-hour work week last week telling them how urgent it is that they get to work."

    11. Re:Agile and Scrum Are Like Communism by Required+Snark · · Score: 3, Informative

      RS -232 actually worked most of the time, unlike the other examples.

      --
      Why is Snark Required?
    12. Re:Agile and Scrum Are Like Communism by q_e_t · · Score: 1

      Estimates can be poor, even with unchanging requirements, as the requirements may not be understood, effort required not understood, or something just turns out to be more difficult.

    13. Re:Agile and Scrum Are Like Communism by ctilsie242 · · Score: 1

      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 it, I don't know anyone who is not a muckety-muck manager who -likes- Agile/Scrum. Most put up with it as part of their job duties, but it doesn't really add anything productive. If a dev team needs daily meetings that take up half the day, something is wrong. This would not fly in any other profession (imagine doctors in meetings for four hours before doing operations, or waitstaff meeting for four hours for customer goals before hitting the tables.)

    14. Re: Agile and Scrum Are Like Communism by ArmoredDragon · · Score: 1

      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 communist, then there will be no more crime (after all, there can't be crime against laws that don't exist) so nobody will want to murder, nobody will want to steal, etc.

      Yes, this is what communists actually believe, and because this is all a big pipe dream to begin with, it only makes sense that communism hasn't ever existed. So when we hop back into the real world, what we have are those who followed all of Marx's steps and never made it to this mythical state of existence like he predicted they would. Because that is as close as it gets, that is what we can refer to as communism in the real world, and it has not, does not, and never will work. Instead, all that it ever does is enslave people.

    15. Re:Agile and Scrum Are Like Communism by Escogido · · Score: 1

      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.

    16. Re:Agile and Scrum Are Like Communism by DrXym · · Score: 1
      The golden rule of all religions is "do no evil", to which they throw in some morals about life, death etc. and wrap it up into layers of aphorisms, sophisticated rituals, dogma, mantras etc. If you want to get to heaven you do what your religion says or else.

      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 to reach software heaven.

      Yeah a process is better than nothing, and every methodology has a grain of truth about it. But don't take it too seriously. Things like scrum / agile work when people standup and say what they're doing and the release schedule is designed to iteratively get stuff out the door. But once you start sending people off on expensive training courses to be "scrum masters", or you start requiring devs to break tasks down into 15 fucking subtasks each with an estimate, or when someone starts bitching about "velocity" or the "definition of done", you're crossed straight over from pragmatism into process religious bullshit lalaland.

    17. Re:Agile and Scrum Are Like Communism by Kjella · · Score: 1

      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 the cake. The problem is that it usually turns into a shouting match until you're back to square one only with more time wasted on meetings.

      I recently took over as a Scrum Master and my first order of business was to say you don't get to fiddle with the priorities every few days, we're now time boxing two week sprints and the sprint planning is the one place you get priority for anything but hair-on-fire emergencies. I don't have a single product owner but I have a big pre-planning meeting where they have to agree on some joint priority for the next two weeks. That also includes "non-executing time" like workshops and other long sessions you want my team to spend time on. And I'll try very hard to avoid that people steal time through side channels, that's what breaks the respect for the system.

      Daily Scrum is primarily for the team and unless they indicate they need some kind of assistance it's over. I do the basic questions and really the only thing I'm looking for is if what they said they got done yesterday matches what they said what they would do in yesterday's stand-up. If someone indicates an issue, that's its own meeting with those that developer says he needs input from whether it's part of or the whole team, the product owner, those who requested the work or whatever. The rest I leave for the sprint review and retrospective, the review is the external focus on deliveries/progress and the retrospective is the internal one on the process/teamwork. So there can be whining but it's once every two weeks.

      I've tried very hard to "narrow down" the scope of Agile to say it's a working method. Break things into "Tasks", get them "Ready" and get them "Done". The big processes outside the two weeks you can use whatever other method you want. And we're not doing both in the same sprint, if you need us for design work or a workshop or whatever that's cool but if so what you get is time not deliverables. Time what will hopefully crystallize into tasks that are "Ready" for the next sprint. Oh and they prioritize, but we estimate and say what we think is realistic in the next sprint.

      If you want to make plans the team thinks is impossible you've already lost. I'm trying to keep this as fact-based and rational as possible, like do you dispute that we have X hours available? Do you as a manager/product owner think you know better than the team if we say this a 10 hour job? Do you dispute that 10+20+5... > X? I know you have a deadline looming, but something has to give here. Because we can go back the bullshit method we had before, where everything was allegedly "in progress" when you've touched it and "almost done" for months. That's just goading you along until somebody has to break the news that this shit is nowhere near finished.

      --
      Live today, because you never know what tomorrow brings
    18. Re:Agile and Scrum Are Like Communism by JaredOfEuropa · · Score: 4, Insightful

      You know: that's an apt description of many managers I've worked with. And it's not just Agile or Scrum either: they devour management books that vary between the blatantly obvious and the hilariously ridiculous. They are desperately looking for the right cargo cult, the right set of motions: "If I just find the right steps and follow them exactly, my projects will be on time and my department will run like clockwork".

      With that said, and reading the comments here on ./ about horribly dysfunctional Agile environments, my first thought still is that these organisations aren't implementing it the right way. Having 3 hour standups, screaming Scrum masters, and weeks fully booked with meetings means that you're not doing agile wrong, and perhaps you're not doing it at all. Agile is about taking small steps in small teams, removing process or demoting it to guidelines, getting closer involvement from the business, and what have you. But it won't turn cookie-cutter developers into "full stack" rock stars, nor martinet team leads into effective facilitators, and it won't provide management with a clue. And like those management books, it's not a panacea for all organisational ills.

      --
      If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
    19. Re:Agile and Scrum Are Like Communism by Jahta · · 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.

      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 basis; the scrum master is a facilitator, not a manager. And the staples of traditional management - like meetings, powerpoints and progress reports - are either eliminated or kept to the absolute minimum necessary. As a result, I've seen cases where traditional project managers deliberately set out to sabotage agile projects to show that "agile doesn't work".

      But mainly whenever I've heard people say "agile is crap", what they have really been doing is this. I've worked on many well run agile projects that were both successful and good places for developers to work.

    20. Re:Agile and Scrum Are Like Communism by gtall · · 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.

    21. Re:Agile and Scrum Are Like Communism by Chris+Mattern · · Score: 1

      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.

    22. Re:Agile and Scrum Are Like Communism by Chris+Mattern · · 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.

    23. Re:Agile and Scrum Are Like Communism by Entrope · · Score: 1

      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.

    24. Re:Agile and Scrum Are Like Communism by Cederic · · Score: 1

      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 targeted at you, sorry)

    25. Re:Agile and Scrum Are Like Communism by Cederic · · Score: 1

      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.

    26. Re:Agile and Scrum Are Like Communism by Junta · · Score: 1

      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 having your product relate to another product and that product *will* release an update that your software cannot work with, that's a hard deadline. Or a customer has said that purchase is contingent upon the function.

      For things that would improve your user experience, but are not "deal breakers" I've found it best to not commit a timeframe to the users and instead surprise them, or say it's being worked on but not express when you expect it done. When delivered, it's a very positive impression. When it slips without a promise, it doesn't tend to upset the customer. If you had said it would be ready by a certain time though, they will get much more upset. Of course, this is subjective, you can't just slip such deliverables forever, eventually the user would decide that your project is stagnant or that you never deliver on "we're working on it", so you do have to do enough to show continual progress, but it's a lot more nuanced and subjective than "you will have this thing you don't abosolutely need in precisely 2 weeks time".

      --
      XML is like violence. If it doesn't solve the problem, use more.
    27. Re: Agile and Scrum Are Like Communism by Anonymous Coward · · 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.

    28. Re: Agile and Scrum Are Like Communism by PaulRivers10 · · Score: 1

      I've also never met anyone who's actually doing day-to-day coding that likes agile. The only people I meet who like it are people who used agile to get *out* of coding. Managers, "architects" who uses agile to move away from day to day coding, "product owners" who again used agile to get out of coding under the agile system, and agile consultants. "Praise agile and we will reward you by removing you from the hell of working under agile!", basically.

    29. Re:Agile and Scrum Are Like Communism by Jahta · · Score: 1

      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 groundwork, skill up their people, etc. and then say "oh, it doesn't work". If you don't put the structures and skills in place up front, then chaos will ensue. Garbage in, garbage out. It's the same for any method.

      I've worked in development shops that put the investment into setting up well for their chosen agile method and consequently have got excellent results with it. But, like most things in life, if you fail to prepare, you prepare to fail.

    30. Re: Agile and Scrum Are Like Communism by Cederic · · Score: 1

      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.

    31. Re:Agile and Scrum Are Like Communism by James+McGuigan · · Score: 1

      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 need to do the hard work of actually creating a spec, and you are free to change your mind about what you want at any time and at any stage during the project. We provide the continuous integration guarantee, meaning we will always have a shippable product, and when you eventually run out of money we will declare the project a success and ship you "something". You get to decide when the project is DONE and we get a monthly paycheck with no risk of project failure.

      This of course is far better than the waterfall model, where the vendor insists that the client pays them for the privilege of spending several months with expensive architects arguing over a realistic and self-consistent spec, with no short-term visible progress to be reported upwards, with the vendor then having to quote a fixed price for the project, assuming all the risk of project failure, having to deal with un-billable client change requests not in the technical original spec, and then having the client argue that the original spec they spent so long discussing wasn't what they actually wanted after all.

      So by selling management the illusion of control, the vendor avoids of the politics of not getting paid.

    32. Re:Agile and Scrum Are Like Communism by under_score · · Score: 1

      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.

      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.

    33. Re: Agile and Scrum Are Like Communism by under_score · · Score: 1

      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.

    34. Re: Agile and Scrum Are Like Communism by PaulRivers10 · · Score: 1

      Hey look, you tried to throw out more marketing buzzwords and change the topic.

      Clearly you're one of the people I'm talking about - it sounds like you're an agile consultant right? Sounds like you give orders to a bunch of remote people you never see in person?

      Like I said, the "agile is magic" lines are always pushed by people who are not actually writing code under agile. Agile consultants. Managers. People who use it to get away from daily coding and out of morning standups. But for the people actually coding, agile sucks.

      You know what other system had an "owner" (product owner), and a "master" (scrum master) who was an uneducated person with little power to change the schedule but all the responsibilty for the people under them meeting timelines? The slave plantation system in the us south. Slave overseers are curiously in much the same position as scrum masters.

    35. Re:Agile and Scrum Are Like Communism by DatbeDank · · Score: 1

      There are so many logical fallacies in your post that i'm just going to walk away laughing.

      Try again better next time.

    36. Re: Agile and Scrum Are Like Communism by under_score · · Score: 1

      Please enlighten me. Point out a single logical fallacy and I will attempt to fix it.

    37. Re: Agile and Scrum Are Like Communism by Cederic · · Score: 1

      Well, I was doing agile development 16 years ago and delivering high quality working software.

      More recently I don't program and I don't tell teams how to program. They tell me what's working for them. I let them take ownership and responsibility for their own output, timelines and quality.

      If they're struggling I introduce them to people that can help. If they want to work another way I just don't give a shit as long as they're delivering and doing it well.

      I just don't recognise this weird incompetent inability to make a high discipline delivery approach work, this lack of autonomy in how people work and this need to reject ideas that I've made work myself, seen others make work and find to be a better way of working.

      I certainly don't fucking understand your slavery analogy. Where the fuck do you get that from?

    38. Re:Agile and Scrum Are Like Communism by bongey · · Score: 1

      Worst place I worked they had a meeting just to set up another meeting of which only half came to meeting for another meeting which had to be rescheduled with another meeting. It was meetings all the way down.

    39. Re: Agile and Scrum Are Like Communism by Pseudonym · · Score: 1

      Ummm, North Korea isn't a communist state. There aren't any communist states, never were in modern history.

      For the record, there aren't any capitalist states or libertarian states, either. Fundamentalism in any form is an inherently impractical form of government, especially in the modern era.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    40. Re:Agile and Scrum Are Like Communism by Lije+Baley · · Score: 1

      Your sig is so old. It seems like you've had it for 20 years. Maybe you should change XML to JSON so the kids can eventually grok it.

      --
      Strange things are afoot at the Circle-K.
    41. Re:Agile and Scrum Are Like Communism by Junta · · Score: 1

      JSON is interesting.

      On the one hand, on balance it's a lot more sane than the xml atrocities of the early 2000s.

      On the other hand, the people who overthought things and overengineerd XML making it needlessly complex have been mandating weird stuff in JSON, but they aren't as pervasive as it was with XML's height of craziness.

      Of course, it's replaced with another sort of craziness, with REST (a generally good ideal of actually using the HTTP protocol vaguely as intended) people saying "no need to promise day to day compatibility, because hypermedia!"

      --
      XML is like violence. If it doesn't solve the problem, use more.
    42. Re: Agile and Scrum Are Like Communism by sjames · · Score: 1

      The logic isn't wrong. What use is a system that cannot be successfully implemented 90% of the time? A few failures here and there are just that, butif a system fails 90% of the time, it isn't the people, it's the system.

      Yes, if 90% of people can't eat "right", then it's useless to blame the people. Perhaps you have an unworkable definition of "right". Ask yourself why. Perhaps it demands more prep time than people actually have. Perhaps it isn't actually meeting people's needs. Perhaps the foods "right" calls for are too expensive or hard to find. Or perhaps people are doing it "right" but it only actually works for the small minority of advocates. It's often easier (and more profitable) to blame implementors than it is to admit that "right" isn't right.

    43. Re: Agile and Scrum Are Like Communism by nyquil+superstar · · Score: 1

      I really, really, *really* doubt that organizations like that have a scrum certified anybody around! Every time I see this, it's because someone thought they could read and article or watch a "scrum in 10 minutes" youtube video and then do it with perfection.

    44. Re:Agile and Scrum Are Like Communism by nyquil+superstar · · Score: 1

      But if you actually *aren't* doing it right, then it's not a failure of the framework! And it's nuts how many people *don't* do it the right way. Hell, look at the top comments right now... 6 hour standups. Christ, I could make good money doing scrum consulting. If standup is timeboxed to 15 minutes, and you take 6 freaking hours... then you can't blame the framework, because you aren't using the framework. It's like me blaming my Ferrari for sucking at off-roading, and it turns out I really drive a Ford Focus. It's NONSENSE.

    45. Re:Agile and Scrum Are Like Communism by nyquil+superstar · · Score: 1

      Gawd yes. You are the first person that I think nailed this. It's nuts. Somehow our culture has distilled into "I can be an expert after a 10 minute youtube video" and it's ruining us. A scrum master and product owner should be just as committed to expertise in the framework as developers are to writing good code. *That* engenders respect and, I posit, results that are actually good.

    46. Re:Agile and Scrum Are Like Communism by david_thornley · · Score: 1

      I can find successful Agile projects. I can't find an example of successful Communism bigger than a few thousand people or longer than a generation that actually works (and that tends to require a charismatic leader). I've concluded that Communism doesn't work with actual human beings. (It might be a superb system for a hitherto undiscovered form of intelligent life.) I've concluded that Agile can work very well.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    47. Re: Agile and Scrum Are Like Communism by david_thornley · · Score: 1

      I've concluded that Libertarianism, like Communism, is unworkable for societies formed of actual human beings.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    48. Re:Agile and Scrum Are Like Communism by david_thornley · · Score: 1

      Because, when you're making progress only 25% as fast as expected, you need six-hour daily meetings to figure out why. Duh. Haven't you ever been a manager?

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    49. Re:Agile and Scrum Are Like Communism by david_thornley · · Score: 1

      That's why the Agile Manifesto is written to discourage fundamentalism.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    50. Re:Agile and Scrum Are Like Communism by Pseudonym · · Score: 1

      Yes it is. Shame that few listened.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    51. Re:Agile and Scrum Are Like Communism by toddestan · · Score: 1

      One way it happens is when you have to split your time between more than one project. Of course, each project expects your attendance at their set of meetings. So working on two projects, you now have 2 sets of meetings. Two projects is still manageable, but any more than that and you're spending a significant amount of time in meetings and overhead.

    52. Re:Agile and Scrum Are Like Communism by DarthVain · · Score: 1

      Well to be fair, that isn't an Agile specific issue. That is a Management and/or Project Management issue.

      I've had plenty of examples where a project manager is constantly asking me about my progress on various fronts where I felt like screaming at them that I have done nothing because I have literally been in meetings with you all day, when did you expect me to do the actually work, and then they will schedule some more meetings with me for "updates"... I think I have at several times pointed out that I can get work done on a project or I can sit in meetings with you, but not at the same time... Choose one.

      I think in some cases it is a matter of justifying existence, and others it is just poor organizational or PM... Though to be also fair sometimes it is simply a resource issue, where you are the only resource, but then again, that would fall under management issue.

  3. Methodologies by Anonymous Coward · · Score: 1

    Nothing turns me off an interviewee than these bullshit methodology buzzwords. Can you actually fucking code? That's what's important.

    1. Re:Methodologies by under_score · · Score: 1

      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.

  4. AGILE is utter shit by Khyber · · Score: 3, 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.

    --
    Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    1. Re:AGILE is utter shit by Penguinisto · · Score: 5, Insightful

      If you think about it, back in the 90's, do you remember TQM? 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...

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    2. Re:AGILE is utter shit by rmdingler · · Score: 1

      Parent and Grandparent are the best two posts on the thread, including this articulate, informative, maternal copulator.

      --
      Happiness in intelligent people is the rarest thing I know.

      Ernest Hemingway

    3. Re:AGILE is utter shit by The+Evil+Atheist · · Score: 2

      Kanban is Agile's bastard spawn?

      And people make fun of China claiming inventions from other countries.

      --
      Those who do not learn from commit history are doomed to regress it.
    4. Re:AGILE is utter shit by Cederic · · Score: 1

      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.

    5. Re:AGILE is utter shit by Khyber · · Score: 1

      "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 down by the regulator? We couldn't change the system to stay compliant"

      Your fault for not starting with an extensible and flexible in-house framework.

      Literally every problem you've just mentioned would not have been solved by AGILE. It would be solved with a proper fucking coding class.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    6. Re:AGILE is utter shit by Cederic · · Score: 1

      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 every problem I've just mentioned has sweet fuck all to do with the code. But feel free to entirely fucking misunderstand every single fucking point, I kind of guessed you didn't have a clue before writing my first response. I'm doing this for the benefit of others, you appear to be a lost cause already.

    7. Re:AGILE is utter shit by under_score · · Score: 1

      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? 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").

      2015 Data - 11% successful with waterfall, 39% successful with Agile.

    8. Re:AGILE is utter shit by Khyber · · Score: 1

      "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."

      You missed the key fucking words IN HOUSE. As in you think of what you need and develop it yourself, instead of doing like agile idiots do and use pre-made shit that fucks them left and right.

      "Literally every problem I've just mentioned has sweet fuck all to do with the code. But feel free to entirely fucking misunderstand every single fucking point"

      You mean feel free to blow through your bullshit deflections and keep cutting at the core of the problem - you have people that can't fucking code. PERIOD. Including yourself if you keep believing your bullshit. And AGILE will never save your sorry ass from that.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    9. Re:AGILE is utter shit by Cederic · · Score: 1

      doing like agile idiots do and use pre-made shit

      What the fuck does development methodology have to do with library, engine and other component reuse?

      Do you write your own OS from scratch and refuse to use anybody else's? Did you release the language you've created and its compiler so we can use it too? Are you really wasting your company's time writing web server technology instead of just configuring one of the dozens of perfectly capable ones out there?

      you have people that can't fucking code

      I have people that can code, but better yet, know when and how to code and when and how not to.

      I'm not deflecting, but you are continuing to fail to understand. I pity your colleagues.

    10. Re:AGILE is utter shit by david_thornley · · Score: 1

      Our current hardware is literally overpowered for every task we need it to do, if proper coding would be taught and implemented.

      We'd love more powerful hardware. We spend a lot of work trying to get things to work faster on the computers we have. If we had computers that ran faster, we could spend more time getting stuff to work than getting it to work fast. It's not a common problem, but there are people who are writing software that solves hard problems.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    11. Re:AGILE is utter shit by diaz · · Score: 1

      "Fad Surfing in the Boardroom" ( https://www.amazon.com/Fad-Sur... ) is a great book that covers many examples of this. The best part of the book is that it talks about these fads, how the original idea started, how they *should* be implemented, and how they're actually implemented poorly.

  5. Methodologies Are For Hacks by NicknameUnavailable · · 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.

    1. Re:Methodologies Are For Hacks by DrXym · · Score: 1

      Ah but they're no longer "managers" in the agile world. Instead they're "scrum masters". You just have to change the title in front of a person's job and suddenly all the problems resolve themselves. And these people are newly indoctrinated on whatever week long course they been on for their new role and you'd better believe they are going to inflict that mindless process on everyone else regardless of it making sense or not.

    2. Re:Methodologies Are For Hacks by apoc.famine · · Score: 1

      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 style based on your team a little, but I think it's crazy to assume you'd need to come up with a completely different style for different groups of people. If you can't work under good management because of stylistic differences, you're a shitty employee.

      --
      Velociraptor = Distiraptor / Timeraptor
    3. Re:Methodologies Are For Hacks by NicknameUnavailable · · Score: 1

      One size has never fit all and the idea it can has caused nearly every issue in the world.

  6. This is actually good for agile believers by Anonymous Coward · · Score: 2, Interesting

    Considering that agile is a giant scam to sell consulting, training, books, etc.... low adoption only means more customers to fleece!

    1. Re:This is actually good for agile believers by ruir · · Score: 1

      The same as ITIL. However, the most worrying part is Slashdot being (ab)used as a free advertising platform for that BS.

    2. Re:This is actually good for agile believers by Anonymous Coward · · 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 they touch.

      So, while I am in the group that believes agile works well when done right, I qualify that by saying that it is so hard to do right that it may as well be a scam.

    3. Re:This is actually good for agile believers by NicknameUnavailable · · Score: 1

      Much like programming, doing agile right requires above-average intelligence, specifically in one's ability to think abstractly and understand the process deeply.

      Thanks man, haven't had a good laugh in awhile.

    4. Re:This is actually good for agile believers by Hognoxious · · Score: 1

      Does ITIL stand for "Interminably Ticking Inconsequential Lists"?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    5. Re:This is actually good for agile believers by Entrope · · Score: 1

      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.

  7. bah by ruir · · Score: 3

    Agile and ITIL are a load of BS.

    1. Re:bah by nyquil+superstar · · Score: 1

      I'm no fan of ITIL, because I think it's overkill for almost everyone. But Agile? What's not to like about planning, developing, and evaluating the outcome of your work regularly? What's not to like about having the right amount of specs/documentation? What's not to like about letting the experts (the developers) work in the way they see best?

    2. Re:bah by ruir · · Score: 1

      Agile got nothing to do about planning, it is just lingo for micromanagement by clueless PHBs.

    3. Re:bah by nyquil+superstar · · Score: 1

      Sure it does! There is literally a sprint planning meeting that happens at a set interval. It's literally baked in. Beyond that, teams should be experimenting to find out what planning strategies (including style and quantity) they need, and crucially, are working for them (as determined on a set schedule as part of the retrospective). You didn't give me much to work with, but I feel like you are working from a basis that is... misunderstood.

  8. No one actually does this, it's just me-too wannab by Anonymous Coward · · Score: 1

    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.

  9. I love Agile by WaffleMonster · · Score: 5, Funny

    Agile is amazing. All of our competitors should adopt it.

  10. First item on the Agile Manifesto by gweihir · · Score: 1

    "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.
    1. Re:First item on the Agile Manifesto by Junta · · Score: 2

      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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:First item on the Agile Manifesto by gweihir · · Score: 2

      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 constant new things and doing things "better" as suggested by some business consultants that do not care one bit about the well-being of their customers. What I actually expect is some Fortune-500 folding because of IT problems pretty soon. Sony regrettably survived, but apparently it was close. I know of at least one more where it was a really close thing recently. This stupidity really has to stop, but we need a "reference catastrophe" or two before we can make that happen.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:First item on the Agile Manifesto by jez9999 · · Score: 1

      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".

    4. Re:First item on the Agile Manifesto by gweihir · · Score: 1

      There is absolutely no requirement for "blunt". But "honest" is required or everything hoes to hell.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  11. Agile was doomed by the name by NotSoHeavyD3 · · Score: 3, Interesting

    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.
    1. Re:Agile was doomed by the name by Junta · · Score: 1

      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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Agile was doomed by the name by Entrope · · Score: 1

      "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".

  12. Management likes metrics by fahrbot-bot · · Score: 1

    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. . . .
    1. Re:Management likes metrics by Junta · · Score: 2

      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 cheap random developers to either accelerate or replace development.

      I've seen projects that were surprise successes, largely because a really good and motivated technical team did something unbidden. Then seen such efforts utterly ruined when the business tried to 'help' by putting it under project management and reassigned developers to be 'more effective'.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  13. Agile and Scrum in real life .. by Anonymous Coward · · 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 super coder produces more and better output than 50 Indian H1-B slimeballs

    1. Re:Agile and Scrum in real life .. by Junta · · Score: 4, 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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Agile and Scrum in real life .. by religionofpeas · · Score: 2

      More people look better when you show the org chart to investors. That's all.

    3. Re:Agile and Scrum in real life .. by phantomfive · · Score: 1

      This sort of problem can be solved by figuring out what management really wants. Since they are human, they will often fail at being able to explain it, so you have to ask yourself questions like, "Why did they ask that question? What do they really want?" Sometimes it's as simple as giving them daily status updates. If that's all it takes to make them happy, then I am happy to do it, even if it's utterly a waste of time. Making people happy is ok.

      --
      "First they came for the slanderers and i said nothing."
    4. Re:Agile and Scrum in real life .. by Cederic · · Score: 2

      Lower wage bills look bloody fantastic when you show the accounts to investors.

    5. Re:Agile and Scrum in real life .. by Junta · · Score: 1

      It's simple enough: the corporate strategy is hiring more in cheaper geographies. This could be fine if:
      -The cheaper geography provided the *whole* dev team, and not just part of it (navigating 12-hour time zone differences is a nightmare)
      -They actually picked solid developers in the cheaper geos, instead taking them at face value because they have no hope of vetting candidates, and unable to recognize "too good to be true" because they are clouded by the "cheap geo" thing (When a good candidate actually comes online, I can be sure they will be moving on to another company in their country for more money within the month).

      The more developers is an olive branch to say "sorry you can't have a local team, but we can give you *more* developers to make up for the inconvenience", never acknowledging that in some cases, no quantity will make up for lack of quality.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  14. The reality.. by Junta · · Score: 1

    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.
  15. Re:No one actually does this, it's just me-too wan by Junta · · Score: 3, 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.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  16. Organizations find agile is garbage by Balial · · Score: 1

    Seriously, itâ(TM)s a bunch of snake oil. Get over it and learn to shop a product.

  17. Re:It's a crutch by NicknameUnavailable · · Score: 1

    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.

  18. History repeats itself. by The+Evil+Atheist · · Score: 1

    Nothing good ever comes out of a manifesto.

    --
    Those who do not learn from commit history are doomed to regress it.
  19. Math by Sir+Realist · · Score: 3, 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...

    1. Re:Math by under_score · · Score: 1

      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.

  20. Agile' is mostly just 'We're lazy and incompetent' by Sarusa · · Score: 1

    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.

  21. Re:Agile from my practice by Sarusa · · Score: 1

    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.

  22. Death march to Utopia by Anonymous Coward · · Score: 1

    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.

  23. Re:It's a crutch by NicknameUnavailable · · 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 same time (though the illusion that they do/can is often there for the person attempting it.)

  24. Agile fails into waterfall by Maxo-Texas · · Score: 1

    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.
  25. What is this Agile? by TJHook3r · · Score: 2

    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'.

  26. Speed AND quality you say.. by ausrob · · Score: 1

    "accelerating the speed of delivery of high-quality software" aha. Typically, speed and quality are somewhat mutually exclusive.

  27. Re:The best explanation was written long ago by clawsoon · · Score: 1

    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.

  28. Sacrosanct Schedules by SwashbucklingCowboy · · Score: 2

    "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.

  29. Waterfall organization undermine Agiles feedback by Mybrid · · Score: 1

    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.

  30. agile is dead by plopez · · Score: 1

    Dave Thomas gives his reasoning:

    https://www.youtube.com/watch?...

    --
    putting the 'B' in LGBTQ+
  31. Clueless Shops by nowwith25percentmore · · Score: 1

    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".

  32. Survey by PPH · · Score: 1

    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.
  33. Agile is nonsense. Agility is the goal. by Qbertino · · Score: 1

    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
  34. Fake news by fluffernutter · · Score: 1

    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.
  35. Agile might work...if tried by paulxnuke · · Score: 1

    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.

  36. Re: The best explanation was written long ago by c6gunner · · Score: 1

    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.

  37. *headdesk* by jythie · · Score: 1

    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.

  38. Knowing that Agile isn't SUPPOSED to be fast by raymorris · · 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).

    1. Re:Knowing that Agile isn't SUPPOSED to be fast by datavirtue · · Score: 1

      Yeah...there is always an available blame goat to wave at real problems.

      --
      I object to power without constructive purpose. --Spock
    2. Re:Knowing that Agile isn't SUPPOSED to be fast by raymorris · · Score: 1
  39. Re: The best explanation was written long ago by clawsoon · · Score: 2

    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.

  40. Great statistics by SoftwareArtist · · Score: 1

    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."
  41. universal magic bullet secret powder by epine · · Score: 1

    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.

    The leading figures were Albert Einstein and Niels Bohr.

    17 of the 29 attendees were or became Nobel Prize winners, including Marie Curie, who alone among them, had won Nobel Prizes in two separate scientific disciplines.

    This conference was also the culmination of the struggle between Einstein and the scientific realists, who wanted strict rules of scientific method as laid out by Charles Peirce and Karl Popper, versus Bohr and the instrumentalists, who wanted looser rules based on outcomes.

    Starting at this point, the instrumentalists won, instrumentalism having been seen as the norm ever since, although the debate has been actively continued by the likes of Alan Musgrave.

    Even then, there's always some slack-assed Jules-Emile Verschaffelt in the room, to screw things up.

  42. Re:Agile like a pair of concrete shoes by datavirtue · · Score: 1

    "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
  43. Re:Waterfall organization undermine Agiles feedbac by datavirtue · · Score: 1

    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