Slashdot Mirror
Why Your Users Hate Agile
Esther Schindler writes "What developers see as iterative and flexible, users see as disorganized and never-ending. This article discusses how some experienced developers have changed that perception. '... She's been frustrated by her Agile experiences — and so have her clients. "There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.' The premise here is not that Agile sucks — quite to the contrary — but that developers have to understand how Agile processes can make users anxious, and learn to respond to those fears. Not all those answers are foolproof. For example: 'Detailed designs and planning done prior to a project seems to provide a "safety net" to business sponsors, says Semeniuk. "By providing a Big Design Up Front you are pacifying this request by giving them a best guess based on what you know at that time — which is at best partial or incorrect in the first place." The danger, he cautions, is when Big Design becomes Big Commitment — as sometimes business sponsors see this plan as something that needs to be tracked against. "The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"
http://programming-motherfucker.com/, do you speak it?
Agile taken to an extreme can be a PITA. If a customer orders a car, they want what comes out of the factory to have four wheels and a steering wheel. Agile development means that who knows what the end product will be... will it be a bicycle, will it be a lorry, will it be a motorcycle, or perhaps it might be a unicycle. The only person who knows is the one with the loudest voice.
This isn't to say that waterfall is the best dev model, but there should be a balance, so one at least has a vision of what the end product will look like.
He says it quite nicely:
http://martinfowler.com/bliki/FlaccidScrum.html
Of course that was in 2009. Nothing has changed, and I've long past the point of being fed up with the non-technical fuck-tards that think they can sprinkle Scrum-dust on a mountain of technical debt and it'll go away. This is usually done in the presence of a stable of bad developers who lack the discipline to do the actual hard work of the XP practices that deliver good products in the first place.
The parent article author can STFU already. It just reeks of, "Wah! My agile hurts me because I won't do the hard stuff".
Oh, and while your at it agile wimps: stop fucking trying to do "distributed agile" with fucking China and fucking India in order to save 30% on what's already a crap-pile due to communication problems. It's not going to help one bit.
Also, get off my lawn...
*** Sigs are a stupid waste of bandwidth.
The customer thinks they are ordering a building, metaphorically speaking. They can walk around it in their heads, see the color of the drapes, measure the windows, there are quantifiable costs. You don't build things using agile techniques however. "Well, we'll put this skyscraper about here. Start digging and we'll see how she goes."
"The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"
How? Don't even talk about agile to the customer. Can you imagine a surgeon... "Well we'll just start cutting and figure it from there" no no, talk about outcome, not process. Agile talk is for the operating room, not the waiting room.
Almost everyone's doing it wrong, that's why it doesn't seem to work in practice. 99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.
As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care). And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
As TFA points out, that always works fine when your requirements are *all* known an are completely static. That rarely happens in most fields. Even in the ones where it does it's usually just management having the balls to say "No, you can give us the next bunch of additions and changes when this is delivered, we agreed on that". It frequently ends up delivering something less than useful.
If you're not doing Xtreme Agile, you're not doing Agile right.
Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.
What you're failing to recognise is that there is little incentive to work beyond what you're told to do. I once worked on a product that always hit its dev targets on time, every release contained additional features that were not asked for (but were gratefully received by the clients), and every developer knew what they were doing now, and what they'd be doing in the near future. We had pride in what we were creating, and then it went agile.
Suddenly long term planning went out the window, and the dev team was forced into working in a reactive fashion, rather than a proactive one. Code became buggy, mainly due to the product owner not wanting to expend effort on things like 'testing' and 'documentation'. Any developer problems that needed to be fixed (you know, those important architectural refactors that are needed every so often), would be put into tickets, and would then be buried by the product owner so far down the backlog that they'd never be found again. In the end, if you had some spare time at the end of the sprint, you'd spend that time looking for a new job, rather than worrying about the complete and total mess the codebase had become.
Agile f**king sucks big time. You have a single point of failure, and that point of failure is the product owner. If your product owner is the best software engineer that has ever existed, then agile might work for you. If however your product owner is human, then it's likely your dev team would do better by actually making the decisions as a team. Agile does not promote teamwork, it pays lip service to it, and in the process, it removes any incentive for the team to work as a team.
The problem with Agile is that it gives too much freedom to the customer to change their mind late in the project and make the developers do it all over again.
http://michaelsmith.id.au
It frequently is. It doesn't matter what methodology you use- if you change major features/priorities at the last minute it will cost multiple times as much. Yet frequently customers expect it to be cheap because "we're agile". And by accepting that change will happen you don't push the customers to make important decisions early, ensuring that major changes will happen, instead of just being possible.
I still have more fans than freaks. WTF is wrong with you people?
Users don't hate agile. They want a system that is usable, delivered quickly and that works. When done correctly Agile does work and gives users what they want. but it does have its drawbacks especially in dealing with larger teams and larger problems. Users are also a subset typically of stakeholders. Stakeholders come in various categories but the more important the stakeholder, the more influence and stopping power they can have for their project. It's up to your Scrum Master or PM to keep them happy and if they're not, you'll be out on the streets in no time regardless of the methodology. To keep key stakeholders and keepers of the PMP flame, there are techniques and methods to reign things in but also not to make it draconian as to prohibit actual productivity. On the other hand those who hate agile are the ones who usually have invested a lot of time in "process." While agile has it's processes, they are considered anti-patterns by those who have defined things like structure and status reports and 'check the box here, did you check it? I'm still waiting for you to check the box. I haven't seen you check that box yet, were you going to check it? You have to check the box.' It reminds me of this.
What bothers me more and more is the FUD that's generated around any process change that instantly creates this knee jerk reaction against any changes to Software Development practices and techniques. Shit, if we all stuck our heads in the sand, we'd still be writing COBOL on Mainframes with POS facilities like TPF/ISPF. Anybody for punch card compilation? How about decolated listings?, that tablet thing is just a fad and you need to use pencils on 5 part form paper the all the nice carbon paper stains on it. No Fucking way do you need visual tools... Those are bad and promote bad habits we can just program everything with the switches on the front panel of the computers, yeah, bring back front panels and switches and blinky lights. That way we can troubleshoot bad instructions by looking at the registers...
Shit, when RUP came out everybody bitched that it took a special set of software to do those funny use case diagrams but guess what they didn't realize that it was the modeling that was key, not the tool but that point was missed and everybody wrote it off. Use Case driven development? It will never work I heard, shit that was what 15, 16 + years ago and people still bitch.
For those who don't like Agile, I suggest really trying to get involved with it, try it you may like it if not don't work with it and certainly don't work on an agile project if you're against the methodology; all you'll do is fuck it up. For those Agile folks who claim all the other processes are bad and don't produce anything, you also have to realize that businesses are defined by their policies and processes, for Agile to work you have to be able to live within that structure and not all software is done in an incubator setting with you and your fellow software developers being bunk-mates all living on Top Ramen. There are processes in the world, requirements and not all of them can be told as simple stories and for those who don't like architects, too bad, they help keep the orchestration together on those bigger projects and yes all systems have "qualities" that nobody likes to talk about when you start talking about scaling and all the other non functional requirements that won't show up on your story board.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
This attitude explains why software still sucks so badly - people making exactly the same mistakes they were making forty years ago. Mistakes which could have been avoided had they spent a day reading "The Mythical Man Month".
I don't know where you learned your Software Engineering, but at my university, the SE courses included lots of case studies as well as studying the various methodologies. Our professors had a very good understanding why some large project failed, yet again. So be dismissive of the Ivory Tower if you want, but don't fool yourself into thinking they know nothing.
I'll grant there's lot of things to get right, but can we at least learn from previous failures and stop repeating the same mistakes again and again?
Plan My Week for iPhone
...but they can be trusted to say what is most important to them at the time.
No they can't. If you are delivering to customer requests you will always be a follower and never succeed. You need to anticipate what the customers need. As with the I guess made up quote attributed to Henry Ford, "If I listened to my customers I'd have been trying to make faster horses." Whether he said it or not, the statement is true. Customers know what they have and just want it to be faster/better/etc you need to find out what they really need.
Paying taxes to buy civilization is like paying a hooker to buy love.
You are a problem.
You seem to fail to understand that there is no difference between designing a car and designing a software product.
All the things that go into designing a car should go into designing software. The fact that you don't do it that way shows the failure is you.
Chasing the current fad is for those without the ability to produce something of quality. They don't provide actual benefit, just waste resources.
The reason that software 'developers' get by with it and engineers don't is because most software can't result in someones death, where as an engineering failure on a car can.
You've tried to compare apples to oranges ... but only because you don't realize your oranges are really just another apple.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Uhh. One simple example of how they are vastly different.
Cost of recalling 5 million mufflers due to tiny flaw in production == HUGE
Cost of minor bug fix for (almost all) software == not so huge
This single difference drives all sorts of different optimizations for process.
Business unit: We want XYZ, We have a budget of $x and we want it done by July 1st.
IS Department: You see this is a math problem. XYZ costs $y not $x. You can't come and tell us exactly what you want to have done and exactly what you are going to pay. You can tell us one or the other and we'll provide the opposing data.
Business unit: That's not acceptable, and what about the date?!?
IS Department: We literally have no idea how long this or any project will take.
Business unit: We need hard facts! We need to claim our project is affordable and will be done by our arbitrary date! We need you to lie to us!
IS Department: Ok, well, we'll use a method called "Agile" and we'll completely make up some time and costs estimates. But the whole point of Agile is that we'll revise these dozens of times during the project so that, in the end, we can claim that our estimates are accurate because we basically just made them match what they actually ended up being at the end of the project. We will blame you for the overruns in our documentation, and you will blame us in yours. Then, in some meeting somewhere we'll generally complain that all projects over-run estimates by an average of 200% and gloss over the fact that this basically proves estimates are completely made up and are of no use at all.
Business unit: Perfect!
It's not that agile encourages laziness from the client... it's more that agile realizes that many (most?) clients don't really know what they want up front.
I find mention of the car design up above particularly useful, as you may have a client go through a lot of trouble to explain that they want a car and work with you to design a beautiful station wagon. You produce that station wagon perfectly to spec, and the user grudgingly accepts the station wagon but is never fully satisfied with it because what he/she *really* wanted was a sports car, but the user was unable to fully realize it until you handed over the station wagon.
Now that the process is over, though, the user is stuck with the station wagon unless he/she is willing to start the process again and throw more money at it (and at least in my contrived example, they got a working car).
The underlying goal of agile is to get the user to realize he/she wanted the sports car at a point early enough in the process to either change course and make the sports car with minimal extra overhead or realize the end product is simply going to be a station wagon and live with it or cancel the project early.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Errm, that's exactly what waterfall is. You have a big upfront specification phase (essentially your user manual from your example) followed by a design phase followed by development etc.
The problem is that users truly don't know exactly what they need, and even if they did, those requirements will change over time in response to the market changing. So by the time that you've spent months writing a spec, 50% of what you specified will not be what is actually required. Worse you've now spent months writing out of date documentation and have NO software to show for it and opportunity to start getting back any of your investment - paper specifications are not a business asset. Then you spend still more months writing code against that spec, meanwhile another 50% of the remaining correct spec is now out of date meaning that by the end of development you've actually only delivered 25% of what the customer really wants and 75% of what you've developed is wrong. And you've still not got any software into production to be returning on the investment you've made.
That's why people looked at other ways of developing software and why agile gained traction.
It's not a perfect approach, but IMHO it's the least bad approach that we've tried so far.