Why Your Users Hate Agile 597
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?"
Agile Hitler said it best (Score:2, Funny)
"Why weren't you at the fucking stand up meeting???"
Agile summed up (Score:5, Funny)
Agile is to proper software engineering what Red Bull Flugtag is to proper aeronautic engineering....
Re: (Score:2)
They've thought about it an awful lot, have lots of "great" ideas on how to make it better, and maybe have even been nearby a few times when someone else was doing it .
But they have never done it themselves and the thought of actually DOING it scares the crap out of them.
The "Academic Dream World" Argument. (Score:5, Insightful)
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?
Where these proffessors the same profs who teached (Score:3)
I can't help but think of the saying "De beste stuurlui staan aan wal"/"bachelors' wives and maidens' children are well taught", sure these profs "know" what went wrong... and where is the proof that what they THINK is right? I can tell you why Hitler lost the war, it was his silly mustache. I have now educated you on this fact but that doesn't make me right.
Just because someone analysed a disaster and claim X caused
Re:Agile summed up (Score:4, Insightful)
Academics with degrees in software engineering describing how to write code is like a horny virgin describing how to have sex:
The same goes for academics with degrees in medicine describing how to treat a patient, academics with degrees in civil engineering describing how to build a bridge and academics with degrees in accounting describing how to balance the books at year-end, I take it?
This is one thing that really p!sses me off about the programming world: the notion that "the real world" is all about graft and experience, and that actually thinking about what you're doing and why is a bad thing. I've just started programming again, and I'm following the advice I was given during my CS degree because it's good practice, and a good idea. When I cut corners, I acknowledge I'm being lazy, but I don't swear about ivory tower academics — I choose to break the rules for short-term convenience having assessed the impact of doing so, which is still good practice. That's what the "real world" coders forget: anything can be good practice if done for the right reason. The academics don't demand that we do everything one way every time, just that when we diverge from the "best" path, we do it conscious of the consequences.
Re:doesn't work (Score:5, Interesting)
"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
Re:doesn't work (Score:5, Insightful)
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.
Re:doesn't work (Score:5, Insightful)
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.
Re: (Score:3)
People *need* to know even a vague timeline of "will it be this year?"
Agile purists tend to frown on this, focusing more on your rolling releases where it doesn't matter what you ship as long as you ship. Could b
Re: (Score:3)
"it'll be done when it is done" isn't the only thing that an agile customer has to go on. There are high and mid-level estimates that give them a general idea. If you're doing something other than SCRUM (like Kanban), you can use cycle time to determine a completion timeline. With a little bit of metrics analysis, you can even provide a probability that you'll be able to meet a particular time estimate.
Two other things that will make a HUGE difference is whether or not you have a committed product owner, an
Re: (Score:3)
Everyone i worked with the last 10 years, loves being agile. Mostly the developers.
However i live and work in europe, perhaps it is a cultural difference.
Re:doesn't work (Score:5, Insightful)
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.
Re: (Score:3)
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.
And that's exactly why Agile is so important. You get to show your results early in the process, so if the customer wants something different, it's cheaper to change it. If you show the finished product after a long process based on wrong assumptions, it's going to be a lot more expensive. Weeding that stuff out early is one of the core tenets of Agile.
Re: (Score:3)
And that's exactly why Agile is so important. You get to show your results early in the process, so if the customer wants something different, it's cheaper to change it. If you show the finished product after a long process based on wrong assumptions, it's going to be a lot more expensive. Weeding that stuff out early is one of the core tenets of Agile.
The problem is that customers are not nearly as available as people would like. Either they're located offsite (and won't relocate to be with you or allocate space for you to be with them), or they're short of time because of their other commitments, or they the kind of people who hate being shown works-in-progress.
Also, customers aren't (necessarily) users or vice versa. That's a major piece of tension right there.
Re: (Score:3)
THat's great, if you're writing something that's highly customer visible and understandable, like a UI. If you're building a front end webpage, go agile. If you're writing a back end set of service or algorithms, the customer won't be able to see anything, and won't be likely to understand it even if they do.
With traditional methods, you have some possibility X of major change towards the end. The value of X depends on how good your engineers are at design and requirements gathering. The cost depends on
Re:doesn't work (Score:5, Insightful)
...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.
Re: (Score:3)
Re: (Score:3)
If you've properly engineered the code, then it will handle additions to the code base with much more ease than if you hadn't bothered to engineer it in the first place.
And yes, it's going to be a PITA at times, but the alternative is to do a complete rewrite from time to time when the code becomes an unmaintainable mess.
Re: (Score:3)
All of that applies regardless of the methodology. Agile doesn't mean you throw engineering out the window, it means you refactor constantly, exactly as much as is required. I think XP dictates that you do the simplest thing that will solve the problem, although I will still tend to engineer a more expandable solution. Sometimes it pays off, sometimes I waste my time and implement a more complex solution than is ever required.
Re: (Score:3)
No worse still, I'm an end user. A HAPPY end user. Whatever *insert company here* is doing their software meets all taxation and financial regulations, comes out in advance of tax time, and has done so long before agile was a blip in some idiot manager's mind.
Re:doesn't work (Score:5, Interesting)
"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.
Re: (Score:3, Interesting)
You've fallen into the trap of using their terminology. As soon as 'the problem' is defined in terms of 'upfront design', you've already lost half the ideological battle.
'The problem' (with methodology) is that people want to avoid the difficult work of thinking hard about the business/customer's problem and coming up with solutions that meet all their needs. But there isn't a substitute for thinking hard about the problem and almost certainly never will be.
The earlier you do that hard thinking about the
Re:doesn't work (Score:4, Interesting)
"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 [youtube.com]
Re:doesn't work (Score:5, Interesting)
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).
Re: (Score:3)
260 people maintaining 420,000 lines of code, written to precise externally provided specifications that change once every few years.
This is fine for NASA, but if you want something that does roughly what you need before your competitors come up with something better, you'd better find some brogrammers.
UI/Process Stability (Score:2)
Re: (Score:3)
You can't build a chicken coop properly, much less a modern house, much less a skyscraper without *really detailed* specs, the bigger the project, the more detail. And everyone buying the building or building it is supposed to realize that any changes are really expensive. How can you tell t
Re: (Score:3)
obligatory non-xkcd (Score:5, Insightful)
http://programming-motherfucker.com/ [programmin...fucker.com], do you speak it?
Agile is not a golden bullet (Score:5, Interesting)
Re: (Score:3, Interesting)
Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework,"
This is just nonsense.
Software is done after X hours. X does not vary on the fact that you do it iterative or in one big bang. So the cost is the same.
However experience has shown that small iterations/increments are easier to handle.
Agile in practice is typically waterfall without a project plan That is completely wrong. Every agile (Scrum(Kanban/XP)
Re:Agile is not a golden bullet (Score:4, Insightful)
Journals and conferences don't want to publish negative results, so you very seldom hear about all the people who try a process and find that it sucks for them.
Process success stories in the software field have always been driven more by special circumstances than science. Nobody has yet figured out how to (or at least bothered to) control for variations in sample-group productivity well enough to generate reproducible results for most process changes, and all the practitioners want to optimize their processes for different things. For example, CMMI and its ancestors are good if you have a load of time, good requirements control, and a few good leaders mixed with a bunch of more ordinary workers; Agile is good if your customers value whims over checking all the boxes and having really robust software; etc.
Finally, software changes can have chaotic effects, which makes it hard to apply a lot of the control, prediction and robustness methods used in other engineering fields. This makes me think that there will always be a large element of individual skill and domain expertise in building and delivering successful software, and that processes will always need to be carefully chosen based on the team and the project.
Developers hate Agile too (Score:5, Interesting)
Re: (Score:2, Informative)
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.
You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.
Re:Developers hate Agile too (Score:5, Insightful)
Re:Developers hate Agile too (Score:4, Insightful)
This is totally true. And I think the main part of the SDLC they try to avoid is planning. I've both been a developer and had developers writing automation code as projects for me as an infrastructure engineer, and the most frequent abuse is zero planning. And that's the thing that makes agile seem endless to users like me. The developers keep having to rewrite everything every dang sprint because they didn't put enough planning into the architecture to make it flexible enough to meet the requirements. And speaking of requirements gathering, that consisted of getting a bunch of user stories and then diving straight into coding, rather than taking the time to get into the true details and really flesh what the users needed. Which is another agile abuse.
I'm honestly getting pretty darn sick of agile, because even with the defects in other paradigms, I think better software was developed more quickly. It's amazing what a little up front thought (which most other paradigms call for) will get you. And again, a lot of people will argue that it's not agile that is the problem, but the abuse of agile. I agree in theory that abuse of agile is the problem, but since 99% of projects seem to do agile wrong in practice, it might be time to throw the baby out with the bath water and get a new paradigm that isn't so easily misinterpreted.
Re: (Score:3)
Re: (Score:3)
One of the hardest things for process designers to do is to fit their processes to the people who will use them.
Most hard-core proponents of Agile don't understand this. This shows up in the small number of places that do stand-up meetings right, that do automated *and* thorough testing right, that elicit useful input and direction from the customer, and so forth. Once you throw all the Agile processes together, few places can do most of it right, and that's one of the biggest reasons that Agile ends up b
Re:Developers hate Agile too (Score:5, Insightful)
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.
Re: (Score:3)
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).
So you're saying if a fellow team member is doing something in a way you think could be done better, you just stay silent? If a team member is planning to do something that you think isn't actually necessary because of something you're doing, you ju
Re: (Score:3)
Then why can't people instead send a daily e-mail to you alone as the project manager. Why force everybody together and hear about stuff about which they couldn't care less?
In other words, it's a way to keep people
Re: (Score:3)
If you truly couldn't care less about what your team is doing, then they aren't your team and/or you're not a team player. You're either a Rambo or a drone, neither of which is a good fit for an Agile team.
And that's fine. Frankly a lot of software developers aren't a good fit for Agile. Many got into software specifically because the
Re: (Score:3)
And yet, somehow, projects like, oh, the Linux kernel, the Apache HTTPD server, and just about every other open-source project out there seem to be able to muddle along without face-to-face communication.
Re: (Score:3)
I like coworkers who are motivated and talented such that if I know (from some initial communication) they're working on X that's due on date Y, I can rest easy knowing they'll deliver quality code on time. I have plenty of my own stuff to think about. I'd rather not have to concern myself with everybody else's stuff on a daily basis. If I'm working with such people, I shouldn't have to care either.
Re: (Score:3)
Which is why you should have implemented the specification we mutually agreed upon at the outset. As long as you do that, I shouldn't have to care what you do on a daily basis.
That can happen by you walking ove
Re:Developers hate Agile too (Score:4, Insightful)
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.
No one who advocates Agile says that you should just ignore that you have issues until your next standup. Obviously if during the day you have issues you should tell someone. Nice strawman though.
Not a strawman - if you simply discuss issues as they arise, then what's the point of having dailies?
Re: (Score:3)
"You're doing it wrong" is the first excuse ever given when someone criticizes Agile. At the same time "you're doing it wrong" applies to just about every group using Agile that I've seen. There's a whole industry grown up around Agile consultants who go around to companies to tell them "you're doing it wrong".
Re: (Score:3)
"You're doing it wrong" is the first excuse ever given when someone criticizes Agile. At the same time "you're doing it wrong" applies to just about every group using Agile that I've seen. There's a whole industry grown up around Agile consultants who go around to companies to tell them "you're doing it wrong".
Yep. Agile can never fail, only be failed. If it appears to have failed, it's because you're not really devoted to its principles. You must be on fire with the spirit of the scrum, brother! You must accept the stand-up into your heart and soul!
(Listening to a bunch of Agile true believers talking about programming is like listening to preachers at a revival meeting, only without the nice singing in between sermons.)
Re: (Score:2)
Admittedly that's because most do Agile quite wrong. I saw a study somewhere that showed that those that the more Agile processes were followed, the better the success rate. Doing half-assed Agile doesn't work well and burns out developers.
Re: (Score:3)
I'd love to see a citation for that study. I've been waiting a decade for someone to show me actual data that supports a claim that various Agile practices cause a measurable improvement in some useful way, and so far I've yet to find a paper where the methodology and/or conclusions couldn't be debunked literally in a few seconds.
M. Folwer said it best: Don't do scrum w/o XP (Score:5, Insightful)
He says it quite nicely:
http://martinfowler.com/bliki/FlaccidScrum.html [martinfowler.com]
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...
Re: (Score:2)
Goddam I wish I had me some mod right about now
Re:M. Folwer said it best: Don't do scrum w/o XP (Score:5, Insightful)
Exactly. Part of the reason XP never took off is that it forces business people to confront reality. You can't PowerPoint your way out of a pair of developers standing in front of you explaining that you're the one who needs to decide what the fuck in going to be built right here, right now, and to accept the consequences of supporting it.
Re: (Score:3, Insightful)
Yep. Getting stakeholders to face reality is always the challenging part. We managed to do it (OK, mostly do it) by running some extensive JAD sessions. No one left until things were agreed to and signed off by people who could make that commitment.
It doesn't mean that things didn't change down the road, but at least people understood the change, the weight of the change, and what that change would cost. Sometimes the change was documented and pushed out, and at other times the change was important enough t
Are you nuts? Don't talk agile with the customer (Score:5, Insightful)
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.
Re: (Score:3)
"...talk about outcome, not process."
But with Agile there is no outcome, just process. Agile does not work toward an end nor does it invest in understanding when there might be one. It is optimized for projects for which the intent is a continuous stream of incremental deliverables of little or no value and no completion. Great for sustainable billing and the pretense of interchangeable man-months, bullshit for anything worth doing.
Re:Are you nuts? Don't talk agile with the custome (Score:4, Funny)
Re:Are you nuts? Don't talk agile with the custome (Score:5, Interesting)
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
Re: (Score:3)
Re: (Score:3)
I second the advice of not exposing external customers to internal processes. If developers want to use an agile process internally, fine, but talking about agile processes like Scrum to clients is bound to make them uncomfortable. I'm not surprised at all that users hate agile.
Customers don't want to hear that their feature request will need to be made into a Story and put in the Icebox, and that afterwards you'll play Planning Poker and put it in the next Sprint. It's really just elaborate way of saying "
Agile definitely has a place (Score:4, Insightful)
But, it's like every other tool; it was made for a certain job. You try working in screws with the claw end of a hammer, and you can expect your results to suck. If you don't have a staff of above-average, disciplined developers and small or well-understood project goal odds are you're applying the wrong path. Agile isn't for project managers who just want to save money and speed up development.
Agile isn't what I hoped it would be. (Score:4, Interesting)
I've done agile for the past few years and always waterfall before that. Was looking forward to agile because it sounded more flexible, but that's not what I've observed in practice. Everybody is so touchy about finishing up all of the sprint tasks by the end of the two week period, that there is a strong disincentive to bring anything new in, when you're finished up. No one wants to skew the metrics.
Between the aribtrary development cycle and the constant meetings, I find it far less productive than waterfall. Especially since so much waterfall is implemented in an interative fashion anyway.
Re: (Score:3)
Funnily enough, most (academic) software engineering researchers understand that "waterfall" was originally intended as an exaggerated -- strawman -- description of a methodology that nobody uses in practice. Most practitioners also understand that any non-trivial project involves some backtracking, and most involve some iteration on parts of the development lifecycle, and thus don't try to use a strict waterfall method. Most Agilistas didn't get either memo.
Re: (Score:3)
amen.... but your problem isn't Agile, its the methology you call agile you're using.
I used to do agile year and years ago - we had 6 week iterations, no standups, and it worked beautifully. Tell that to an agile proponent today and they'll tell you it isn't agile.
I've had a project where we spent roughly half of a 2 week period on admin and setup tasks,so we asked for the sprint to change to 3 weeks so we could get some work done - and were told no, that's not agile.
The problem isn't with agile, its with t
Re: (Score:3)
We've been evolving our agile approach over time to see what suits us.
Yes, the manager wants 100% completion for the burn down, I always say 90-95% should be a good target (all backlog tasks are between 15 minutes and 4 hours, shorter is better for us- we plan to the method level; we include Unit Testing and Code Analysis as separate tasks if the team gets out of habit).
And we have no problem moving backlog items for the current sprint back into a general backlog if we realize our planning missed something.
No process? (Score:4, Insightful)
She's been frustrated by her Agile experiences — and so have her clients. "There is no process.
If there is no process, it's not Agile. It's laziness with a name as its excuse.
Agile has a very different process than Big Design Up Front, but it definitely has processes. Frequent releases are a process. Scrum meetings are part of a process.
Simple answers. (Score:3)
"Clients ask, 'How much will it cost?'" says Hecker. An Agile-style answer is frustratingly ambiguous, he points out, along the lines of, "We think we can do it as described in about two months plus one month of bug-fixing so that's about three months unless we choose to make refinements and improve the product along the way, in which case it will be longer." "Then the client responds, 'Umm but, how much will it cost?' and I begin to hear the anxiety in their voice," says Hecker. "They wanted a crystal clear answer to a seemingly simple question, but it's hard to supply that answer because Agile projects are always a shifting sand."
This is just silly. As an agile developer you just write to a spec and the spec contains features and milestones. You ask "What do you want it to do?" They tell you. You write a spec for them with everything they asked. They ask "How much will it cost?" You tell them. Then if they want evolutionary developments you add those on as a fair fee later for the extra work beyond what was in the original spec. This isn't a problem with an agile development philosophy.
Agile programming is like evolving a species. Just because you might end up with a giraffe, doesn't mean your first spec can't be a very clear one for an antelope. If the client wants to make the neck longer and add some spots later, it is good that you choose a flexible and agile basis, but there is no need to give the client a primer on selective breeding and evolutionary genetics before you even begin and get them concerned with all the details. Details are the programmer's job.
I don't hate Agile (Score:5, Interesting)
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.)
Users don't hate agile... (Score:5, Insightful)
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. [youtube.com]
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.
What many developers call agile is not agile (Score:4, Insightful)
I've seen actual agile, and I've seen stuff called "agile", which means, "we don't plan, but we do standups". "We're using agile" is a codeword sometimes for "we don't like or even understand SDLC, so we'll use no process and call that lack of process agile."
Not even remotely describing agile. Her "has 17 years of web development experience" jibes with my experience in a 5-man web shop where the term agile was literally a euphemism for "no process", and there was a COO asking for 6-month gantt charts despite the "agile" label; vs a stint at a top-3 software company where we had agile tools (ie, Rally), everyone got trained on it on our team, we had a very defined process (including using gitflow for branching and a review process pre-merge), and a full-time scrummaster.
I don't even think this is really giving agile a bad name, because I think anyone who has experienced both (or, say, just real agile) could tell the difference easily.
agile paradox (Score:3)
What developers see as iterative and flexible, users see as disorganized and never-ending
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.
Anyone who expects predictability and tractability from what is fundamentally an uncertain project is going to be unhappy. But that is the sort of unhappiness that you can't really do much about.
This is how it works (Score:5, Insightful)
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!
Agile is not the problem (Score:4, Insightful)
Agile can work nicely to develop the customer requirements into a modular system where components can be quickly added and removed as opposed to the blob of spaghetti that Waterfall can produce. However both Agile and Waterfall can end up with that same blob of spaghetti when the developers are not disciplined enough to design carefully instead of quickly.
Re: (Score:2)
And the most important question why is management pushing agile down the throat of developers?
Much easier to fire developers, sub in new and unprepared ones, and then blame delays on the "agile" programming.
Re: (Score:2, Insightful)
Because, as every good manager knows, all problems can be fixed by making them more agile!
Is your well oiled development team on schedule, and the producers are twiddling their thumbs with little to do? You need to be more agile!
Have recent changes to the way your dev team works caused an on track project to go off the rails? You need to be more agile!
Have your senior developers got so fed up with the piss poor management team behind your project, that they've all just quit? You need to be more agile!
Has
Re:I tell them I feel the same way! (Score:4, Insightful)
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.
Re:I tell them I feel the same way! (Score:5, Insightful)
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.
Re:I tell them I feel the same way! (Score:5, Interesting)
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.
Re:I tell them I feel the same way! (Score:4, Insightful)
Agile processes deliver useful working software at frequent intervals -
I love that definition... If you failed you weren't doing Agile..
Just because you've produced something working at frequent intervals, doesn't mean the user won't see it as "disorganized and never-ending"
Re: (Score:3)
Re:I tell them I feel the same way! (Score:4, Insightful)
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.
well.. there's a difference between doing agile where you're supposed to and in making the user a part of the testing team..
why would the user care how the sw is developed? they don't. but if the fucking sw they have in active deployment changes where buttons are weekly as the developer is doing reactive development, that is going to suck balls.
Re:I tell them I feel the same way! (Score:5, Interesting)
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.
Re:I tell them I feel the same way! (Score:5, Insightful)
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.
Re: (Score:3)
The problem is that even the client can't be sure what they want. I finished a roughly 2 year project last year and when you're working on a project of that scale 2 years is long enough that the client's business requirements wont necessarily be the same at the start of the project as when they finish. You can't blame the client for that, and it's something you have to deal with.
The clients have to deal with changing markets, they have to respond to competition, and so forth - that's just a reality of busin
Re:I tell them I feel the same way! (Score:4, Insightful)
False analogy. Designing and creating a car is much easier to manage as a "waterfall" since it is so much harder to change and the problem domain is often in less "flux". The sheer energy and expense to design a car; which consists of market research, basic R&D e.g. engine and tire materials, the design of the car, the design of the factory, the design and construction of the manufacturing equipment, the training of workers, etc., is so huge that upfront design makes sense.
In software the problem domain is often in flux, e.g. financial reporting regulations, and the cost of changes in software are lower. So software must be soft or lose relevance AND the fact that it is soft creates the danger of too many changes. We cannot think of software as no different than a factory, that is the original sin of software development.
Re:I tell them I feel the same way! (Score:4, Insightful)
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.
Re:I tell them I feel the same way! (Score:4, Insightful)
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.
Re: (Score:3, Interesting)
Of course there's a big difference. Software is essentially the most malleable and fungible thing humans have ever devised. The big problem in software engineering that doesn't arise in automotive engineering is that in software engineering, the requirements are frequently in flux. If you can fix your requirements as precisely as the requirements for a car, than yes, there is no difference. But in general this isn't true. Unless you're writing software for NASA or something similar, most such requirements o
There is no difference? (Score:3, Insightful)
You are a fucking retard if you think there is no difference between making a software product and making a car. And I sure hope you never EVER get to work on ANYTHING more important then... fuck it, I hope it you never get to work on anything period.
Some rather obvious, to anyone with a brain, differences:
Car: Road safety regulations, any car going on the road needs to qualify in most countries to a very thick binder of rules.
Software: no regulation.
Car: Environmental regulations dictating fuel consump
Re: (Score:3, Insightful)
You seem to fail to understand that there is no difference between designing a car and designing a software product.
I beg to differ. Cars have a fixed design: body, chassis, steering wheel, gears, seats, engine, tranny, suspension, fuel tank, exhaust, etc. Car manufacturers only change the spec of each of these components. Once you've manufactured cars for a few years, you know how much time and effort is required to make small changes for the next version.
The same does not apply for designing new software. Software design's scope is several orders of magnitude bigger than car design's because the former can do much mo
Re:I tell them I feel the same way! (Score:4, Insightful)
I really beg to differ there - you see the design that goes into a car and you'd understand that software is pathetically simplistic in comparison. There's a reason a new car takes years from inception to delivery, and why my car doesn't have a USB media, or Android or iPhone interaction - when it was designed, these components were too new for inclusion in car specs. Your argument that software is always new, while it has some merit in that our industry does too much re-engineering of stuff that should be stable, doesn't compare to car designs that have to utilize new stuff too.
Still, it doesn't take away from the fact that cars are designed well, and software is hacked together on a sloppy basis. No matter what unit tests or "best practices" or methodology you use, the comparison is still that software is cobbled together.
Now software used to be well designed, (and I don't mean where that means a huge requirements specification that can never be fulfilled), but designed as software. When I started out we were taught to write software by first laying out on paper how it would work and how it would interact with all of its components. Nobody does that today, and its probably why the software of yesteryear are still running your banks systems compared to how Microsoft cannot produce software that requires service pack after service pack, or a framework that they won't scrap and replace with something else after 2 years!
If we want our industry to be mature and well-respected, and for our software to keep running for decades, then we have to move away from the continual reinvention of the same old shit. We have to put up with moving goalposts all the time - thanks to the suppliers like Microsoft that keep on changing the OS or OS components so they can sell us new versions. We don;t help ourselves by chasing new languages and frameworks all the time too though. If we could fix this, we could start writing software that did whatever it was designed to, and didn't need replacing.
Re: (Score:3)
VOTE DOWN (designing car != designing software) (Score:3)
This comparison (designing a car - designing software) comes up again and again and again and again.
Just a thought: The basic function of a car has not changed since car #1 beginning of last century. Everything else were millions of very tiny gradual improvements.
Tell me again how software design is like that?
Re: (Score:3)
False analogy, yes. But not for that reason. The real analogy would be: I ordered a car and working with the engineering team I slowly discover I needed a camper van. That's what I get home with and end up much happier because I got the right product. Obviously that analogy applies to custom designed software and is seldom appropriate with cars. If I buy something off the shelf, think about a car or about Word, I usually know what I need because I already used it. But Word as seen from inside MS is custom d
Re:I tell them I feel the same way! (Score:5, Insightful)
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.
The real truth... (Score:3)
It doesn't matter what you call your process, many development teams will devolve into this behavior. The fact of the matter is that 'agile' has the distinct honor of being the most 'hip' thing, and as such it is the set of labels of choice used to hide behind.
Of course. most of the terminology about agile stems from a host of BS that seems more infomercial than useful. The original 'manifesto' was a collection of straightforward statements that are pretty sensible, though mind numbingly obvious. It has
Re:The problem I have with Agile (Score:4, Insightful)
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.
Re: (Score:2)
Don't forget the consulting and speaking fees! Those are critical.
Attack of the pseudo technological acronyms (Score:3)