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?"
The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development. Agile has a specific application: development of experimental software, where the project sponsors know they need something in a particular area but do not know exactly what. Agile (and iterative development in general) lets the target change over time as knowledge is gained. Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework," and there is a great deal of this in iterative development. Agile in practice is typically waterfall without a project plan: the project sponsor knows what is desired, and when, and is trying to get it for cheap. Iterative development fixes the time taken ("timeboxing") and the cost (level of effort); what is unknown is how long it will take (or alternately how much you can put into a sprint). Starving Agile has the same result as starving typical development: you only get the 1/3 of the software that is apparent, not the 2/3 that makes that 1/3 truly functional, reliable, and maintainable.
I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
"Proper software engineering" does work, its called "Systems Engineering", is well established and successfully used for large-scale mission-critical projects in almost every industry outside of IT - which seems to be blind to anything invented outside of IT.
Systems engineering has its own professional accreditation organization: http://www.incose.org/practice/whatissystemseng.aspx
"Proper software engineering" doesn't work.
You're right, but you're going to the other extreme. The problem with all methodologies, or processes, or whatever today's buzzword is, is that too many people want to practice them in their purest form. Excessive zeal in using any one approach is the enemy of getting things done.
On a sufficiently large project, some kind of upfront design is necessary. Spending too much time on it or going into too much detail is a waste though. Once you start to implement things, you'll see what was overlooked or why some things won't work as planned. If you insist on spinning back every little change to a monstrously detailed Master Design Document, you'll move at a snail's pace. As much as I hate the buzzword "design patterns", some pattern is highly desirable. Don't get bent out of shape though when someone has a good reason for occasionally breaking that pattern or, as you say, you'll wind up with 500 SLOC's to add 2+2 in the approved manner.
Lastly, I agree that there is no substitute for good engineers who actually talk to and work with each other. Also don't require that every 2 bit decision they make amongst themselves has to be cleared, or even communicated, to the highest levels. If you don't trust those people to make intelligent decisions (including about when things do have to be passed up) then you've either got the wrong people or a micromanagement fetish. Without good people you'll never get anything decent done, but with good people you still need some kind of organization.
The problem the article refers to about an upfront design being ironclad promises is tough. Some customers will work with you, and others will get their lawyers and "systems" people to waste your time complaining about every discrepancy, without regard to how important it is. Admittedly bad vendors will try and screw their customers with "that doesn't matter" to excuse every screw-up and bit of laziness. For that reason I much prefer working on in-house projects, where "sure we could do exactly what we planned" gets balanced with the cost and other tradeoffs.
The worst example of those problems is defense projects. As someone I used to work with said: In defense everything has to meet spec, but it doesn't have to work. In the commercial world specs are flexible, but it has to work.
If you've ever worked in that atmosphere you'll understand why every defense project costs a trillion dollars. There is absolutely no willingness to make tradeoffs as the design progresses and you find out what's practical and necessary and what's not. I'm not talking about meeting difficult requirements if they serve a purpose (that's what you're paid for) but being unwilling to compromise on any spec that somebody at the beginning of the project pulled out of their posterior and obviously doesn't need to be so stringent. An elephant is a mouse built to government specifications. Ok, you can get such things changed, but it requires 10 hours from program managers for every hour of engineering. Conversely, don't even think about offering a feature or capability that will be useful and easy to implement but is not in the spec. They'll just start writing additional specs to define it and screw you by insisting you meet those.
As you might imagine, I'm very happy to be back in the commercial world.
"Proper software engineering" doesn't work.
As a Software Engineer in the formal sense (Engineering is regulated profession here in Canada) I can assure you that "proper software engineering" works great - and it's often Agile. Software Engineering is just like any other type of engineering, you have to pick the right tool for the job. That said, a lot of under-qualified people go around claiming to be Software Engineers and think that generating piles of paperwork will make their crap code (and crappier designs) smell better. They are just as bad as these people
If anyone thinks that there is complete, 100%, nailed down design for a 75-story skyscraper before any digging starts, and that the design for the 69th floor is similarly nailed down before the 3rd floor is finished, they need to spend some time on a construction site. The overall shape of the building, the structural design, the very bottom and top floors, and the allowable parameters for design of the later floors, sure. But the exact design of floors 50-72? No. Plan for what happens when the selected elevator supplier goes bankrupt, the ship carrying a key delivery of structural steel sinks, the developer finally signs a tenant for 68-70 and he wants an internal staircase and private elevator for his offices? No. Look up "fast-track" in a construction dictionary.
sPh
If you're not doing Xtreme Agile, you're not doing Agile right.
That is correct comrade. Failure is always caused by insufficient ideological zeal and purity.
Until the thing is built or the software is shipped there are many options and care should be taken that artificial administrative constraints don't remove too many of them.
Exactly, and as someone who does both hardware and software I can tell you that that's better understood by Whoever Controls The Great Spec in hardware than in software. Hardware is understood to have physical constraints, so not every change is seen as the result of a screw-up. It's a mentality. I'll also admit that there is a tendency to get sloppy in software specs because it is easier to make changes. Hardware, with the need to order materials, have things fabbed, tape out a chip, whatever, imposes a certain discipline that's lacking when you know you can change the source code at anytime. Being both, I'm not saying this is because hardware engineers are virtuous and software engineers are sloppy, but because engineers are human (at least some of them).
I work in a government office as a developer. We get lots of projects that come from management, who may or may not actually understand the business they're managing. If they do, they can give you some idea of what they want. If they don't... they can give you a very vague, buzzword-laden description of what they want.
What would tend to happen is people would go off and try to use something like waterfall. They'd go gather requirements, build a big specification, design, etc etc. The managers in question would sign off. We'd build it. We'd then learn at the end that it actually doesn't do what they need it to do, and their business actually doesn't work the way they said it did. Why? Because managers and users suck at dealing with this type of stuff (in my experience). In house, consultants, it doesn't matter. This has been done wrong so many times that we decided to try something more agile.
And it's worked for us. We build the pieces that people actually do know we need (either because they're based on a paper process that we can look at, or because some user can articulate it). We get that into people's hands. They tell us what they hate, what they still have to do manually, and what would make their lives easier. Then we go off and build those pieces.
It's not actually saving us time, but the users have been MUCH happier with the end products. And since I like happy users and dislike spending time building things that are pointless just because two years ago someone thought it should be in the requirements, this works out pretty well for me.
It's not the right way to do every project or in every environment, but my users certainly don't hate it. (Quite the opposite, we get a lot more feedback from people asking for improvements now because they've seen it acted on more readily.)
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
I've worked in lots of places that claimed to do Agile, but few really did. Often it meant doing daily standups (or even sit-downs in one case!) and not having any good specs. Right now I'm working at my first contract that really is Agile, and it's fantastic. It is chaotic, but not because of us; it's the reality we're facing. We're doing several projects at once, the designs had to be sent back several times because they were wrong, business isn't really sure what they want, and we're being productive in spite of that.
We tell business what we need from them in order to do our work, instead of the other way around. We don't accept issues that don't meet our standards, and as a result, more and more issues do meet our standard. When we uncover a misunderstanding, we can change direction on a moment's notice, and because business, admin and others show up at our standups and our sprint demo, we discover these misunderstandings pretty quickly.
Not all is perfect. Not everybody around us really gets Agile, and particularly our tester would be much more at home in a Waterfall setting, but for me personally, it's working very, very well.