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?"
But the alternatives are worse, so... there's that.
"Why weren't you at the fucking stand up meeting???"
And you can do the in depth planning for the plan-less agile method , right in foundation team server-ices ( New word! For all the servers and all the services on top!)
http://blogs.msdn.com/b/bharry/archive/2013/06/03/visual-studio-2013.aspx
I mean, how can you not have enterprise agile capabilities in your devops team?
Agile is to proper software engineering what Red Bull Flugtag is to proper aeronautic engineering....
There is some value to UI/process stability. Even if the overall operation is optimized, the time it takes to retrain users still counts for something...
The more appropriate question is why your developers hate agile? And the most important question why is management pushing agile down the throat of developers?
http://programming-motherfucker.com/, do you speak it?
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.
A new highway was constructed by my house and most of the exits existed but they were not open because there was still work to be done to finish the ramp. Lots of drivers were anxious to have the ramps completed and have the highway open. I guess all engineering projects frustrate users and make them anxious.
Is getting any work at all out of the devs that use it. They seem to spend 50% of their time in meetings - scrum meetings, planning meetings, grooming meetings and that's just internally. The other 50% of the time seems to be finding how long they can spend to spread one simple thing out over the sprint, and of course once that's out the way _nothing_ else happens until the next one begins. The upshot of all this is that actually getting anything done is like steering a supertanker from the next planet.
So I've come to understand "agile" as meaning "waste nearly all of your time doing meta-work instead of actual work" - the sooner this management fad is replaced by the next one, the better.
I'm sure its proponents will now immediately wheel out the old "no true Scotsman" argument.
Communism is awesome, but there just hasn't been a real Communist state....
Christianity is awesome, but the church isn't true Christianity
Democracy is awesome, but we just need more to be a true democracy...
"Proper software engineering" doesn't work. Code that actually does work is invariably ugly and violates any best practices you can possibly imagine. Code that follows those best practices and whatever the current paradigm fad is, are over budget, over schedule, and even though they incorporate all the correct patterns for abstraction and maintainability, this results in such a huge volume of excess sloc, that it is less maintainable as a function of sheer size. You don't need process or patterns, or even documentation (though it would be nice). The only thing you need are good engineers that actually communicate with each other, and if you don't have that, then no amount of process or patterns or paradigms or practices can save you. I should note however, that if you just want to generate billable hours then you absolutely want every last one of those Ps and mediocre (but not bad) engineers.
refactor the law, its bloated, confusing and unmaintainable.
Since when does Agile mean overwriting people's changes at random in your version control system? I can't say I've ever encountered such a bizarre thing anywhere I've worked and done Agile.
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.
Dear user: you can have a Big Upfront Crystallized Waterfall Development and we'll all pretend that nothing will ever change and what you get is what you get -- or we can try and make it better along the way as we develop better understanding of the lame incompetent efforts you have half-heartedly made when laying what you asked for.
Users are agile in changing what they asked for into what they wanted; developers have to agile to match those changes.
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.
Here's how to sell Agile : It's like Groupon. Maybe you won't have what you want, but you will end up with something and it will be cheap.
"What developers see as iterative and flexible"
Really? Because I think its the latest in a long line of mumbo jumbo project leadership tools for managers that don't know what they're doing, so they seek out a guru to tell them. Usually with a lot of nice sounding [Barnum statements] for weak minded managers to cite as evidence.
There are many more efficient tools for communicating. If none of those are working, all the meetings in the world aren't going to work either. The difference is that physically moving people into the same area takes more time. It also makes whatever is communicated harder to recall unless you expend that much more effort recording the proceedings.
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 mutated to be a large set of vocabulary generally hijacked at will.
XML is like violence. If it doesn't solve the problem, use more.
Gee customer, this is how it feels when you change the spec, add features, demand arbitrary and contradictory changes with no notice.
once my Chrome finished updating to version 244...
developers have to understand how Agile processes can make users anxious, and learn to respond to those fears
Soo.... To make Agile work developers have to understand user 'feelings' and respond considerately. Is it just me or did this whole Agile thing just turn from a fun one night stand into a committed relationship with cards and anniversaries and stuff?
I think I'd rather just stick with Agile sucks.
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.
I swear to God...I swear to God! That is NOT how you treat your human!
"...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.
That's kinda what I'm saying actually. In the real world, agile talk is idiotic.
At some level agile is agile. At its core it encourages doing more of less rather than less of more. If your a software sweatshop please tune out now.
I think encouraging people to make piecemeal changes rather than investing in hard creative designs to better address the application domain is great advice for all of our competitors.
You guys go do that thing...add your widgets and features in low level codes while we configure the same in a RAD framework before you can say uncle. Be disruptive release little shit updates to production customers all the time...I'm sure they will be thrilled at your responsiveness to their needs. Place no bounds on global complexity and just let all the shit pile up because well features are worth it and using your brain is a bad thing (tm). I love agile and I hope our competition does too.
So you've worked at Google? Beta is the goal.
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.
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.
"First they came for the slanderers and i said nothing."
I disagree. If you can't get your customer to go along with agile, then agile might not be right for you. One of the key observations behind agile is that customers often don't really know what they want up-front, and that they're better at pointing out the differences between an intermediate solution and something workable. As I understand it, that's one of the driving forces behind the short sprints: start with the bare bones, and work on what the customer perceives to be the biggest missing feature. Keep doing that until the customer likes it.
I understand that not all customers can do this, however.
The way I've used agile is not to have multiple iterative launches of a product, but to have multiple iterative points where you *have* a launchable product. The advantage of Agile isn't constantly churning out crumb-like updates to freaked-out users, it's being able to say on any given week "we could launch with X feature set now if we had to, and have Y feature set still to build" rather than the non-agile alternative which is "it doesn't work but we are 30% towards completing it".
This enables you to be able to set a firm launch date and be able to meet it with a working product. You can either chose to launch iterative updates afterwards, or just stick with what you launched and move onto a different project - whatever the business decides.
In reference to the summary: if there is no process, you are doing Agile wrong. If your developers are overwriting each others work, you are using SVN wrong. Neither of these are inherent problems with Agile, you're just being incompetent - and there is no methodology to overcome incompetence.
Quality and re-usability aren't even on the radar, so in the long run, code is more expensive, buggier, and harder to extend and maintain. In practice the mindset almost always becomes, "just get something done, somehow, so we can move on..."
In the real word, comprises need to be made, but Agile doesn't consider software to be a valuable asset, it is a disposable tissue suitable for wiping your nose and never using again. Later, when you have to maintain or enhance it, it is an undocumented mess with poor design, ragged interfaces, and often without even a clear understanding of what it is supposed to do.
In other words, it expresses perfectly the general opinion of what we now expect.
"I understand that not all customers can do this, however."
A very fortunate few in my experience.
"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.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
Agile dictates that you have practically continuous customer input to the development process. How do you propose to get that -- and to communicate your expectations about those interactions with the customer -- without telling them about the methodology?
It was sort of Agile - all of the Agile-buzzwords and all that. But there was *TONS* of process wrapped around it. You couldn't commit anything unless the sprint was in the right state and you had a story in the right state, and the tasks were in the right state. Part of the explanation is that they needed to accommodate customers who were in highly regulated industries, where everything you do needed to be traceable and documented.
You really had no motivation to do much of anything above and beyond. Even fixing trivial "no-brainer" bugs got deferred simply because there was too much process involved to actually check in the fix.
But from one who actually had to do it, I would describe it as "soul-sucking".
Yup. A Troll-bait comment subject. But not every project is one where it can be afforded to "fix it" next month/next quarter. Device drivers. Compilers. Mainframe OS's. I heard a figure recently (from in-person discussion with a Mainframe SW person) that downtime costs them upwards of US$10,000 PER SECOND of downtime. Agile focuses on fast responses to customer bugs, not on ensuring that the number of bugs experienced by the customer is virtually zero. The point is that Mission Critical content has to have a correctness level which is an order of magnitude (or more) than a game or a less-than-wonderful UI. A bad case scenario: Oh, I'm sorry, Miss/Mr. medical patient of Therac25 (http://en.wikipedia.org/wiki/Therac-25) - we'll fix that in two revisions by using our Agile process (its a tough bug to fix), and we're sorry that you will contract a horrible form of cancer in the meantime.
If you are working for a customer, you still need a roadmap, some sort of over design. Your customer needs to know where you are going. You can't just say "we'll give you an iterative version with a new feature or two in two weeks" and say that every two weeks. Because then you'll do exactly what you described, leave the customers and programmers confused. You don't need to design every last thing out, but you still need a roadmap.
"Agile" techniques are useful when the problem can be treated as a large number of decoupled features. This is the case for many web-based systems. (Especially since the database system does most of the the stuff that really needs to work right.). It's not too useful if the problem isn't like that.
This is part of the curse of open source, which tends to turn into a set of features in search of an architecture. Some open source projects have a strong architecture, but they tend to have a "little tin god" problem.
I have been work in software development accounting sector.
1.Will exhaust Developer because of time constraint.
2.User tend to bypass normal accounting procedure,making development agile faster but inconsistent software.
3.Software love by user. No the user think differently.User also exhaust numerous of testing and blaming the vendor because inexperince while the the vendor much confuse since they follow the new and fast agile development.
4.Hardly to get break even.
**
Now i'm moving to non customize accounting software.It had to because customer usually don't understand how software and accounting works.
More report on excel,make user itself tend to do agile reporting rather then forcing developer to agile reporting.
BI tools->unsure it will help or not.
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
Whereas my experience is more with a bewildered business unit representative being handing a 200 page "spec" in dense type and bizarre, technical language and told he has until Thursday to approve it (with all the time invested, it is understood that no spec can ever be rejected); then being equally bewildered when the mods delivered (which do in fact match the spec, modulo interpretation) don't do anything like what he needs them to do or thinks he asked for. Similarly with dozens of business unit reps sitting in a room reading laboriously through aforementioned spec line by line and being told to "sign off" on each page; when it doesn't work they are contemptously asked 'why didn't you speak up in the review meeting?'.
sPh
Agile or Not, users should NOT care, which means, if you can't satisfy 66% of your users with your product and/or your services, then you are doing bad business, it's that simple.
key words: Agile Portfolio Management, ALM blog, Application Lifecycle Management, Application Lifecycle workflows, backlog of business initiatives, backlog of scenarios, backlog of user stories, Build conference, configuring any infrastructure, enterprise agile, enterprise agile capabilities, granularity, higher-level backlog, in-flight releases, Kanban support, lightweight code commenting, multiple Scrum teams, nifty Git innovation, pending changes, Project Server integration, Release Management, sprint after sprint, sprint management, Team Foundation Server, TFS 2012, trace the relationships, version control solution, VS 2013, VS Premium, web based test case management solution, work breakdown ...
AccountKiller
Agile, has process, lots of process, it is just different. If you are doing Agile with process then the problem is not Agile it is your teams lack of understanding of Agile development methodology.
"How do you respond to user anxiety from Agile processes?" :))" :/
I try to calm them down the best i can.
If it doesn't help, i try to use the Jedi thought trick.
"You are not worried, you have nothing to fear, you will not feel troubled by the mad havoc caused by the ever changing user control base classes, data model, web service contracts, everything will be fine at the next milestone
The reason your users hate iterative, continuos improvement production cycles is because they don't actually know what they want or how to express it and they don't like being made aware of that fact.
This is the most ridiculous article I've ever read in my life. Either I'm mistaken, or the original author thinks Agile is an anthropomorphic entity that:
1. Magically adds "too many people".
2. Prevents anyone from adding any process.
3. Enforces SVN? Without undo/merge semantics, moreover!
There is no process because you didn't put any in place! How dumb does this have to get? If there are "too many people", well I don't know that non-Agile prevented there from being "too many people". Ask some people to back off. My God, how difficult is it to walk over to someone and say, "Dude, 10 other people are working on it already. Do something else." My goodness - developers overwriting each other is the stupidest "issue" I've heard in years! How the heck does "making fast decisions" translate to "our developers suddenly forgot conflict-resolution when merging branches"?
Burn the witch!
That's the flexibility needed in the real world, which is what overly rigid advocates of the Big Plan don't get. Real projects always have with a certain unavoidable level of changes and chaos. Agile is designed to be pure chaos.
As a project manager who has run projects using a bunch of methodologies I would never expect my development teams to be responsible for managing the expectations of end users. That's my job. In my waterfall run projects, especially the ones with long schedules it's my job to set the expectation that if we agree on a design 12 months before we plan on delivering then change requests are to be expected. From both sides as well! Users will learn new things, understand their end state better and be impacted by changes in organisational goals. All of which will change their minds on the design we agreed and have been building. Similarly with development teams. Other projects will come along and change interfaces half way through, people leave, assumptions are proven wrong or right and this can involve more changes. In an agile project I generally tell my end users that I'll let them off the hook on locking down their requirements to the nth degree by the end of a phase, but in exchange for that they need to be prepared to engage with me and my team in what might look chaos from the outside but is just a different way of getting to the same end point. I remind them of this trade off along the way as well. My point is it's not the developers job to manage the expectations of what will happen in an Agile program. Developers should be left to do what they do best; develop awesome software that enables business to do what they want to do. Managing peoples expectations is my job. Josh.
Imagine a Gartner style Magic Quadrant...
X-Axis is developer work ethic - Lazy/Energetic
Y-Axis is Agile process Poor/Good
Problem in my experience (10 years as a hired gun development PM) is that far more teams that shout agile are firmly in the bottom left quadrant. When you get one or can move one to the top right it's so good that I (almost...) feel guilty taking the money. But more often than not I cringe when I'm given an 'agile' team to run because I know I'm going to be pushing crap up hill.
It works well for small teams who already use good practices and know exactly what needs to be done. The programmers keep things in their heads rather than having to write documents or have meetings ad nauseum. It is honestly not common when it works flawlessly, but it can work and cut a lot of corners to get a product out the door.
I found some of the opinions at 37signals a bit self serving and conveniently leaving out a lot of gotchas, though. Yes, going straight from concept to code is great when you aren't just the programmer but the client as well. And as you spread responsibilities out to more team members, guess what? All those processes that were tossed come back into play as being necessary.
To me, though, a big red flag was the mention of code routinely getting stomped on even though they are using SVN. On my projects we come to a screeching halt when a conflict arises and we resolve it carefully. If programmers are routinely choose 'use mine' on commits then there are some bad practices going on. That's also true if things are getting pushed 'live' too quickly. It sounds like Esther is letting the programmers run the asylum.
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
> Agile is designed to be pure chaos.
You're doing it wrong.
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"
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 "OK we'll write it down and do it later", and doesn't really give anyone any assurance that 1) you know what you're doing from a technical POV or 2) that they will have what they need by the time they need it.
Non-committal is a big issue for agile. If you want, do all that Scrum shit internally with your team, but just tell the clients in plain English that you need to figure out how much work is involved, and that you'll give them a timeline and will stick to that deadline.
Another part of the problem is stupid terminology like "epics", "planning poker" and "ScrumMaster" (TM). Personally I find it embarassing to our profession - real engineers use technical jargon to describe the systems they are building and how they operate. But software engineers are completely obsessed with process and methodology - and are only able to talk about these things. It's amazing how we understand so little about the businesses we automate.
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
Agile Succeeds Three Times More Often Than Waterfall
http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall
But when I first heard about Scrum with its "pigs" and "chickens" I immediately thought of Animal Farm. :)
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.
You are doing it wrong.
None of these silly little 'styles' are the 'one true way' to do it, if you trap yourself into any one of them, you're doing it wrong.
Agile however is just (as other have pointed out) another way to say 'we just throw any crap code at the wall that anyone wants to make, and see what sticks'
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
"Customer" doesn't have to be the actual customer. It can a be product manager or marketing acting on behalf of the actual end customer. If Microsoft adopted Agile do you really think they'd be sending their specs to each and every Windows user asking for feedback?
I recently encountered a project that states that it is being managed as "Agile." One of the developers told me that their version of Agile is more like a really, really short Waterfall process. I didn't see any reason to disagree with that so I was wondering what Agile really meant in the actual Real World(TM).
Does that mean we're doing it wrong? I'm not sure. It seems to work well enough for our internal and external customers.
Kriston
Once again, an attack on agile. I understand if slashdot disagrees with agile approaches, but posting such blatantly wrong stories only makes slashdot look bad, not agile. Disclaimer: I'm both a full time agile programmer as well as freelance, and my users from both jobs LOVE it. Instead of seeing XYZ feature in years, they see it in weeks.
if there is no process, then there is no Agile
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.
Inadvertently, you've just come up with an excellent analogy. Surgeons don't actually work that way, and a good thing too. In fact, no one who has to do any complicated and tricky task with a specified outcome works that way ... except a certain group of fad-following programmers.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
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.
Well other than exploratory surgery, which some surgeons are more than willing to do. A find a better metaphor is a surgeon doesn't ask the director if it's okay to wash their hands.
Because you are doing it wrong.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
So what you are saying that most changes in the design of a building is because of emergencies.
We have the same emergencies in software development, the selected libraries don't work as advertised, the vendor goes out of business, the implementation of some things don't work out in practice because of CPU usage. It is nasty, to be sure.
But we have the problem that late on during construction of our software, they want us to have the building move around and stop at work addresses of the tenants so that they don't need to take the bus to work. I mean how hard can it be, just strap some wheels underneath it.
In the UK, isn't that what rugby players do and football hooligans are?
Like a good neighbor, fsck is there
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.
The business representative should be handed a business requirements document, written by a decent business analyst, that clearly explains to them in words they understand exactly what the system will do.
It's wrong to expect someone to sign off on a document they don't understand, and whilst it may achieve the goal of deflecting accountability, it won't result in a good product.
I like my coffee the way I like my women - roasted and ground up into little tiny pieces.
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!
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 consumption and construction materials.
Software: no regulation, you can even do it in .NET if you hate the world.
Car: Has engineers work on it.
Software: Has software engineers working on it. These are NOT real engineers 99.99% of the time. Real engineers have to sign off on the stuff they design.
Car: Your car looses its brakes on the highway, you can sue.
Software: Your software crashes during crunch week, SUCKER!
The above poster then claims people can't die because of software error... is he really that dumb?
He seems to think that software design CAN be approached the same as car design... and this is were his REAL ignorance shows.
Cars get many times the budget and especially TIME that software gets. But cars also (increasingly so) re-use parts over and over again. Entire car lines are build on the same chassis, with the same stock engines. And what car maker makes it own tires?
Cars also work on universal roads, nobody would put a Jeep on Mars and then call tech support because "it doesn't work".
Software developers often are expected to create a complex piece of work, with many custom parts at a breakneck pace. It is because if you ask a real engineer to build a car in a week, he would snort at you. That is because the entire world accepts that this cannot be done. Software? They expect you to code a facebook, youtube, gmail competitor over the weekend for a hundred bucks.
and THAT is the big difference. Not in quality or capability of the people but in the treatment they get from management. And that is because car management people have learned that anyone who promises them a new car design in a week is stoned while software managers think "wow, I finally found the only honest developer".
Oh and finally, if car designers pulled of what software developers have been doing, our cars would not just run on water, they would do it on the rings of Saturn. See the current Jeep fiasco and the refusal for a callback despite a very high incident rate.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Sometimes I wonder if half the people on Slashdot know anything about what they're commenting on.
I know, I must be new here.
I specialise in what Agile people would disparagingly call Big Design Up Front. I've been making a bit of a career the past couple of years of rescuing Agile projects gone bad. I call my niche a "delivery architect".
I practice what is sometimes called Iterative Waterfall. I do a lot of design work to determine what is needed to meet the system requirements. I'm talking whole-hog stuff here - use cases, written atomic factored requirements, logical class model, physical database model, screen designs, functional processing, deployment models, the works.
I can do this work "pretty fast" because I'm "pretty good" at it and have a lot of experience at it. My current project manager, surprised at the quantity of deliverables I churn out, asked me last week if I work nights and weekends. I actually work 38 hour weeks.
When I'm done with the design, I hand a task list over to the developers to build. And they build it, once. There's no refactoring into an implied design, I've given them the design and we build to it.
I measure the work progress, and tell the client how long it will take to deliver.
This is the part that an Agilista will tell you will fail "The design can't cater for things that change" they will tell you.
They're right.
The design can't cater for things that change, **but I can**.
I don't just handpass the design to the devs and go on holiday. Any change that comes up, any problems that occur in the implementation of the design, they all come back to me. I refactor the design in my modelling tool, and issue the task changes and a revised schedule.
I monitor the work *all day* and *every day* until we're done. I'm hands on. I'm often not the best coder/developer in the teams I have, but I'm good enough to know what the hell should be going on.
Devs sometimes try and pull the wool over my eyes about how long some program should take, or how hard it is. I find that after I've coded up their work and checked it in and pulled them off the task because I've done it myself, the lies stop pretty damn fast.
We don't zigzag all over the problem space, and neither do we progress like a laser-line. We do tiny course corrections as needed, continually.
It works. It's predictable. I don't know why everyone doesn't work this way.
I have a couple of theories.
One is that many devs are "design blind", just like some people are "colour blind". They just don't have some part of the brain needed to do design. Spolsky reckons some devs are "pointer blind" and "recursion blind" and can never understand pointers or recursion. I think the same thing about design.
Another theory is that most devs just don't have the discipline to dive in and **think** about all the things needed to do a design, and do them. It's hard work. I'd much rather just jump in and start coding myself, I've just learned over 30 years that the design way of thinking gives better results faster.
I'm sure that Agile "works". Lots of things "work". If you're in LA and you want to get to New York, walking "works", it's just not very effective.
My way involves me and the BA's thinking so hard for a couple of weeks or months that our heads steam, and after that it's just a simple matter of tracking the work allocations and making decisions.
Jaycee.
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 it, does not mean X caused it. This is ESPECIALLY important to remember when these people have for decades been teaching the people do did X.
When people say hindsight is 20/20, they are wrong.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
If the user is not happy with agile development then clearly things are going very bad indeed.
In my company we do agile because the internal client wants it. They are the only ones who stand to benefit from an agile approach.
For us ICT agile development makes things only much more complicated:
* There is no overview
* No specification: you must find out everything yourself, making sure that your decisions do not impact something else.
* Multiple versions of the software are developed in parallel with enourmous problems for configuration management, development environments etc.
The only net profit is that the internal client
* Gets a first working version that is actually used in production much quicker.
* Can see the evolution of the system iteration (slice) afther slice, reducing the risk on the 'this is not what we asked for' syndrome.
Normally the client is driving the scope of each iteration (slicing) them selves. So they should be very much in control of what comes out of an agile project. If that is not so (as seems to be the case here) one of the fundamental pillars of agile development (client and ICT form ONE team) has been ignored.
That approach works well if you're selling many, many copies of your software, or if the customer representative is intimately familiar with the customer's actual needs. For most more specialized development efforts, having a customer representative ends up adding a middleman, confusion and extra work.
If a user requests a new feature or behaviour then capture it in tests, implement, and release. No-one can now overwrite the behaviour without breaking the tests which should force either some internal resolution or feedback to the user: "Bob said this number should be calculated this way, you asked for it this way, you need to agree between yourselves". If developers are overwriting each other's changes then you are really are doing it wrong.
The way it was taught in my college class anyway, Agile is simply a different process for implementing code. The problem is not how the code is written but how the customer requirements are written. Both Agile and Waterfall will suffer greatly if customer requirements are incomplete or worse, contradictory. The results are always having to go back and rewrite code
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.
When that project is rolling along, the application is seldom usable for documentation purposes because of missing or changing functionality. And since there're no specs to work from, it's damned hard to write documentation for the product.
You guys can write all the fancy code you want, but if your users don't have reliable docs that explain how it all works, you might as well have been sucking your thumbs as writing code. Your application will be misused, misunderstood, and eventually your development and support teams will be expending as many hours supporting the current application as they are trying to code updates, because you wanted to be trendy and were too damned lazy to provide the tech writers with technical and functional specs.
No such fast-track in other markets. The permitting authorities do want the items you mentioned and any necessary impact studies and site plans. The contractors usually want the first iteration of the detailed designs (work plans) along the rest of the material like cost estimates before even committing under a contract for the job.
Iterations on the plans as responses to changing conditions do happen in the preliminary design phase, the permitting phase and during the construction phase. Each step do tend to incur various amount cost multipliers and risks to the calculations, strongly depending of the nature of the change.
he wants an internal staircase and private elevator for his offices?
Customers who have such interests do make a commitment already in the earlier stages of development. The space is often reserved and sold long before the building reaches its top height.
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?
"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."
Damn skippy it becomes something to be tracked against. The customer is going to validate against the Big Design so your agile team's adult supervision better be doing it too!
0 1 - just my two bits
All these development models are designed to deliver code to a customer. There is a beginning and an end. Waterfall, Agile, whatever - they all assume this. They just disagree about how you take the journey.
It's true there is a beginning. But for the developer there is no end. He is never thinking about the end, because the end is when the code dies. If it dies, he has failed. Thus he doesn't plan for it, instead he actively plans for avoiding it.
Software isn't a deliverable product. It doesn't wear, and if it constantly evolves it will never die. In that way it's like a living organism. Occasionally it sheds copies that are delivered to the customer, but for the developer that isn't a singularly important event. Instead the developer is constantly thinking about about where he wants to be in 10 minutes, in 10 hours, in 10 days, in 10 months and 10 years, fully aware that if he gets any of those decision badly wrong the organism in his care might go extinct.
Thus any development process, like Agile or Waterfall, that plans for a definitive end point will never be satisfying solution. They are all based on a fiction - software should be treated like a toothbrush, something you deliver to the customer and forget. In their hearts, all developers hope that isn't true, for their code anyway.
She writes "there is no process" ...
If they have no process they should consider using one. What has that to do with "agile" or not?
Nothing!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Is getting the customer/boss to agree to "done is done". When developing iteratively every time a sprint ends I find the user sitting around in deep thought trying to think up something else that might be useful ... sometime ... to someone. Projects never end, people keep coming up with what if this happens I might want scenarios.
Maybe not so much of a problem in contract/software development shops but I think the majority of people that develop are in house as I was at the time and there is no direct cost for these endless "projects". Rather than saying there is nothing to do and give you more vacation as a perk (yeah right) or find other problems to work on it is easier to keep bumping the version number on the corporate dashboard every other week. It is easier for your manager than for him to actually have to come up with know ideas or admit that perhaps he doesn't have enough work for a full time dev.
The customer will know about the process pretty quickly when you just start coding without listening/attending to 3mths worth of requirements analysis planning meetings.
I think it is easier if you phrase it about adaptability. We don't require you to know upfront exactly what you want give us a general idea and we'll give you working code to play with regularly. That way you can decide maybe something isn't really needed, maybe something you thought wasn't important becomes important etc and we aren't stuck with a lot of wasted time building something you wanted last year rather than the thing you really need today.
Agile is designed to be pure chaos.
More accurately, Agile is designed to operate in chaos, and bring structure to it.
this is one of the largest buzzwords in the industry lately in concert with virtualization. i'm surprised i don't see many "articles" on ./ about agile.
i'm not sure i quite understand how or why a software development methodology has become the defacto standard for the project management community as a whole. literally, overnight, project managers have become scrum masters and every project from developing a new predictive pricing solution for sales to an os upgrade project becomes managed as an "agile" project. did manifesto group envision (design/declare) a new project management methodology or good practices for developing (building) software?
"...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.
How long has the Linux kernel been under development? Is it done yet? What version of Windows is Microsoft on?
I've never seen a software project get completed. All I ever see are a series of major releases and minor releases, and eventually the project is discontinued. How is that different than Agile? You work and you work and eventually you have something that is worth releasing to the outside world. Then you keep working and working until the next time you have something worth releasing to the outside world.
Or just maybe, we could take the wiser road and listen to all opinions and pick and choose the best from everyone. Say, instead of drawing a line in the sand and stereotyping/demonizing the people on the other side. When people stupendously say "I'm right and they're wrong" they're usually wrong themselves on multiple counts. A majority of the time, each side of the argument will have at least some valid points. I think you also misunderstand the idiom of hindsight is 20/20 not even mentioning it's usually used in the context of sarcasm. Of course decisions are easier if you already know the outcome.
Agile development is a method that has its respective strengths and weaknesses, it's not the method. There is no "one way" to do everything. Especially with something as ridiculously broad as software development. We're not arguing religion here, c'mon folks, use some sense.
I was once attached to a group doing an early flavor of CAD in the Cloud. I was THE documentation person for a dozen or so developers. I was writing the HELP as a series of JSPs, with just emacs as the authoring tool. I never got any notice of what had changed, I just saw some of the new stuff, which was fluid to say the least. Once, I was told, "Just look at the program," to see what had changed. Really, a dozen programmers changing everything and I had no notes at all? And at every single meeting I heard the twin refrain, "Don't change the docs, we have to localize it," and "The docs really s_ck." Which statement was true and what should I have done about it?
The kicker was that as a favor to users (as expected, the product was real bear to use), I created a cheatsheet in the form of an index. This was an alphabetical listing of the commands and each entry had a short explanation of what each command did and a showed a command stream with the most common options. All the command streams were cut-and-paste from an "approved" manual. This index sat on a boss's desk for about three or four revision cycles. If you count the number of real revisions, you have the first pass and then the second pass to "fix" bugs created by the first pre-release. QA was so backed up checking releases that they had not reviewed the docs in MONTHS.
Anyway, when the boss finally looked at the index, all the COPIED command streams were somehow wrong. How do you carefully explain that fictional docs are really hard to create? So now, the problems with unreviewed docs based on amorphous code become MY problem. The product died soon thereafter, but as the doc person I was blamed for poor work habits and being uncooperative.
It is worth noting that not a single email, note or conversation was ever held to tell me what changes had been made. Both QA and development kept me isolated. And I was uninvited from all meetings. Yup, QA did not look at the docs for months, the developers issued about 8 total rewrites of the code, I was struggling to document just the new stuff I was told about (yes, the pre-release flavor was always different for every single "new" part of the code). In reality, I created a draft flavor for each feature, reviewed the changes made since the developer did the first show-and-tell (round 2 or of corrections), and then I would fix the docs after the developer made more fixes. And this was just for the stuff they TOLD me about.
Please keep me out the loop forever when the code is agile. Agile means no one ever tells what they have changed
If you aren't talking agile with the customer, you aren't doing agile. Agile isn't a way of producing code, it's a way of producing what the customer wants. It involves them intrinsically.
When we build an app for a client, they often start off with a long list of features they want. I've seen companies take their money, go off and build what they asked for, then watch the client discover that once their users are actually using it, it becomes apparent that half the features they asked for are unnecessary and half the features they need they didn't include. A lot of the information that makes this apparent is information that is unavailable to you at the start of a project.
Instead, we focus on building the minimum feature set necessary for the client to start getting value, then see how it is used in practice, and plan the following features using this information. The client ends up getting what they really needed after all and ends up much happier.
The difference between the two approaches is that the first is traditional and the second is agile. It is also something that you cannot do on your own as an internal practice - the client needs to be involved in these decisions at each step along the way. Whether you call it agile in front of them or not doesn't really matter - you are talking agile with the customer one way or the other if you are doing it properly.
Talking about outcome not process only makes sense if you assume the client is not involved in the process, and that's a recipe for building something that is ill-suited for the client's needs. Agile development assumes the client is an integral part of the development process for a reason.
Bogtha Bogtha Bogtha
I am getting sick of this quote. Probably because I keep seeing it when Gnome developers blow off their users, but that is beside the point. Henry Ford lost half his market share by refusing to listen to his customers. They wanted colors other than black and they wanted to be able to getting financing from the Auto company rather than a bank. Ford refused to listen. He didn't listen to his staff, he didn't listen to his customers, he didn't listen to his family. And then GM was larger than Ford and he finally caved to the inevitable. Ford paid a more than livable wage. Ford brought the slaughter house methods to the industrial plants with the assembly line. Ford wisely took on the horse with his automobile and didn't listen to his customers for that major paradigm shift. However, he continued to ignore his customers at great cost. Moreover, I would hypothesize that most of us are not Henry Ford and that most of us are not trying to bring a major change. Listen to the customer. You don't always have to agree, but you better have a damn good reason for going a different direction.
Our team is the user end of Agile and I have to admit; I was really very tired of it about 8 months; at 1.25 yr into the project am really ready to look for something better.I don't want to talk to the programmers every day - they need to talk to each other all the time- I want to take a look at each release doing some testing and give feedback and get stuff fix. The effect of Agile for me on this project is 2-2.5 hrs of meetings every day. The programmers seem to be in meetings about 4 hours a day. The rest of the pEng's in the building are able to get being with thing like walking over and talking to each other without a formal daily chat.
Life is like untied shoe laces; it always tripping you up and getting in your way.
Agile is designed to operate in chaos, and bring structure to it.
The problem is when you start with chaos. At best Agile is a band-aid.
Agile is designed to operate in chaos, and bring structure to it.
The problem is when you start with chaos. At best Agile is a band-aid.
The problem is that we have chaos. Agile is a way to solve that problem.
Agile, like many new ideas, has a tendency to overreach. The exasperated users are the same ones who dread system updates. They see any technological change or inconvenience as the result of a vast technocratic conspiracy. These people are the ones who want it "to just work" and have little patience for the tedious process of taking matters to that point. These complaints stem from taking this group outside its narrow comfort zone.
On the other hand, there are end users, usually termed "power users", who love their engagement with technology and its processes. It is these people who should be part of the ongoing development process. The larger mass of users should be consulted and upgraded, but infrequently. Of course, this requires you not break backward compatibility with each new release. You know who you are.
"The" problem with agile is that it is hard to implement properly. And that is a fact, some aspects of agile (like teams with members that are fully-devoted to, and only to, that team) are basically impossible to achieve in a real world environment.
But the problem is more compounded by agile being less than intuitive. People who think they understand it, but don't actually get it, produce chaos like that being described in the article summary. Developers stomping on each others changes, a lack of progress, and so on...these are direct results of completely missing important aspects of agile.
When exactly two things are true: 1) your people actually understand agile and can do a good job of getting it mostly right, 2) your product's operating environment is the sort that agile serves well, then and only then does agile bring you to great success.
In basically every article I have read where people are complaining about agile, it is obvious that one or both of these are not true.
While I'm interested in what my team members are doing, rarely is it necessary for me to be up-to-date on their daily activities. A weekly catch-up meeting is fine for general "what is everyone working on" stuff.
We all have areas of expertise, and I don't have enough knowledge to have input in some areas of what is being done...similarly, there are only a couple people on the team with the knowledge base to comment on what I'm working on.
Yeah, that's how it should work.. GP's observed process is unfortunately common, particularly (in my experience) with outside consulting firms. I remember finding a few lines in a 400+-page spec and wondering why anybody ever thought that was a good idea. My wife was once offered a job trying to get some customer control back over an Accenture project, and decided she didn't really need to be tied to those railroad tracks.
That's sort of the waterfall equivalent of a manager abolishing planning, micromanaging, and calling it Scrum.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Agile doesn't solve problems. People do. There's your problem right there.
That is all.
Agile is designed to be pure chaos.
No, Agile realizes that software development involves chaos. It provides tools to deal with the reality of that chaos.
Software sucks. Open Source sucks less.
I (as an architect/developer) and my business users love agile. For me, it's all about identifying requirement changes ASAP to minimize rework. Would you rather a requirement change before you work on it or after? The user thinks they know what they want but it's so abstract as a bunch of thoughts in their mind that they can't possibly identify every detail. But put a tangible product in front of them and a lot of what they want changes. It's inevitable.
So for me, I want the user to see the work ASAP so we can proactively identify these changes before we've wasted a bunch of time doing the wrong stuff. Our users totally bought in so it's like having one day iterations instead of the two weeks that we had before. I suppose YMMV with the user and technical team.
Here's a big difference: with agile, you can (and seemingly, many do) carpet and furnish the 67th floor before the hole for the foundation has been dug. Then they're not stuck trying to figure out how to get the 67th floor half way up the building when they're ready to start building it, nevermind moving the elevator shaft...
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
What? It's obvious that Q is a prerequisite for X. And where did the contract specifically state Y version 1? Didn't you know there was a new version due, you blithering bunch of imbeciles?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
8gb memory limit? really? No thanks.
Agile doesn't solve problems. People do. There's your problem right there.
You are entirely correct. Agile is a tool to solve that problem. You still need people to wield that tool properly.
A hammer can be used to make things, but it can also be used to destroy. Even the best hammer won't turn a crappy carpenter into a master craftsman.
Yet another frantic debate about Agile on Slashdot where the word "testing" is only used a handful of times. :(
I am not a software engineer, or even more than a hack programmer. I am a marketing professional with a BSEE (old school analog stuff). My run-ins with Agile -infused third party developers has always ended with the same questions. What is the schedule? Do you have a schedule? Will you even be able to give a rough schedule? Answer is generally 'you don't understand how Agile works, you ignorant marketing guy!' Then you get everything BUT a schedule. Obviously, I don't understand software or Agile...
Don't involve the end-users in the process AT ALL. That way they can't complain during development. After development however...
No, unlike your English teacher.
Seems to me if the developers are over-writing the source code, the problem is not the difference between Agile and Waterfall. Sounds to me like the development shop doesn't know how to develop period and is blaming the development methodology instead of poor in-house processes.
It is possible to mess up source code trees when doing Waterfall projects, also. I know that for a fact.
Hitler's mustache wasn't silly. It was dignified. It was his military planning that was silly.
In most professional fields the professionals that work in that field are accredited or even licensed. No civil engineer builds a bridge without being licensed and having personal liability for failure. Doctors that practice without a license go to jail. But in software people are revered for being successful hackers, participating in 24-hour hack festivals, and making things happen more individually than within a team. No programmer ever seems to be held accountable for failures. The field of "programming" attempts to convert itself to "software engineering" by defining methodologies and processes. Doesn't Agile just celebrate the fact that programming teams can't engineer solutions to problems, so they have to loop around "trying" until the solution is finally close enough (or the funding runs out)?
Such mustaches were quite popular in the 1930s. My grandfather had one, and kept it all the way through WW2. Woe betide anyone who asked him why he had a Hitler mustache; he claimed he had it first, and therefore it was Hitler who had a my-grandad mustache, and without so much as a by-your-leave. Strong words would be in order when the British army got to Berlin...
One thing's sure, he certainly had it last.
It's true I tell you, feller at work's next door neighbour read it in the paper.
Agile works and so do other methodologies. The trick is to know the methodolgy you are using well.
Personally I like a pragmatic approach. I tend to gather as much information as possible up-front. Then I write up a preliminary (!) sepcification used to make a judgment about the time and money involved. I the customer sees the light I go ahead with agile and a reasonable flexible timeline and a budget that is flexible -10%/+25%. Then I go on with Agile. But that doesn't mean there's no control, only more feedback. And not every input of everybody who happens to be passing by is fed into the coding cycles.
Anyway, if an agile (or "normal") project is disorganized it usually means that your project managment sucks. Nothing more :)
"You don't build things using agile techniques however."
Yes, you do. You specced out a new staircase. I built it for $3,000. After you saw it, you decided you couldn't live with it. We specced out a new staircase. I built that for another $3,000, tearing down and removing the old one for free. You decided you liked the first one better after all. Another $3,000, and everyone and voila.
I will happily rebuild things as many times as you please if you pay me each and every time.
"Love heals scars love left." -- Henry Rollins
I do not program. I have never programed anything after a cobol class and some assembler, I am +60yo.
Confusing academic reality, application actuality, iterative and flexible project development, and users' (worker / manager) observations is RFD.
Disorganized, failure ... never-ending proves the venture architect a/o project developer was a failure, that is all.
Agile as a project development tool (software, hardware, services ...), from my observations, is highly structured and demanding on discovering what makes the very best application for a specific community of users (workers / management). C*Os / managers need to be included for top-down OrgOps explicit (legal, core / product processes) reality-plan, and the worker-bees / pack-mules are needed for the bottom-up build workflow functional actuality.
Only two projects did I observe Agile being used in the interest of the entire community (Users/customers, programmers, OrgOps managers ...). I was impressed at delivery and production by the full community expectations. Agile is not the problem, but poor performance by OrgOps persons with career agends can / do make anything fail. C*Os / managers, programmers, and users must be a community with a common purpose and respect.
C*Os / managers (or others) mid-stream changing requirements must be tracked just like software-bugs with an impact statement on schedule, cost, functionality ... that must be signed before proceeding. I suspect, all communities' legal offices will be very happy.
So, stop the whining and do a better job at making a complex community work together. Agile is about meeting users' expectations and sometimes exceeding all expectations.
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?