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???"
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.
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.
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.
"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
From what I have seen they're not lazy, the amount of meta-work is high, and no developer likes doing that kind of paperwork when they could be programming instead. What happened is that they made an earnest attempt to properly follow the methodologies that were mandated by upper management, and this is the result we got. Not the brightest bunch, really.
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.
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.
Don't forget the consulting and speaking fees! Those are critical.
XML is like violence. If it doesn't solve the problem, use more.
"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.
That's kinda what I'm saying actually. In the real world, agile talk is idiotic.
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.
"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
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."
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.
Then your "best practices" are probably wrong and just a poor analogy of what software developers think physical engineering is about. Engineers didn't leap onto CAD like a drowning man onto a liferaft when it emerged because it was a better way to draw, we did it because it was a better way to handle changes. When one portion of a design changes others often have to change to fit, which is very different from the illusion that portions of a design have to be set in stone and later portions warped to fit them no matter the consequences. 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.
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.
"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.
"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
True, but the problem is when the Great Plan becomes too rigid. It's necessary to change it as warranted. This actually seems to be easier in hardware, when you say "sure I could get that last 1dB of dynamic range you wanted, but it'll double the price and power consumption", or "yes we could put that function in module X as planned, but it'd be half the cost and complexity if we move it to module Y". Good systems engineers know this. Of course the headache of being a systems engineer is fighting with the implementers - half the changes or spec relaxations they ask for make sense, and the other half are about laziness or incompetence.
I do hardware and software in a 50/50 split, so I see both sides. Hardware is more easily understood to have physical constraints, but every thing in software that isn't exactly as planned is seen as a failure of the implementers.
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?
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.
The problem with Agile is that it gives too much freedom to the customer to change their mind late in the project and make the developers do it all over again.
http://michaelsmith.id.au
"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.
With agile you're supposed to work on isolated 'features', and that kind of implies you'll be using feature branches. Now, let's talk about branching in SVN. With SVN, when you create a branch, you are actually creating a fork. The two forks will quickly diverge, and so you have to synchronise your fork with the trunk every so often. If you're working in a team of say 30, then you may have 30 separate product forks active at the same time. At the end of a sprint, the developers will enter a race to see who can jab their fork into the product first. If you're the first person, the meat is nice and tender, and the fork will stick firmly into the product without a problems. If you're the last developer, you'll find that the product is nothing more than a pulverised mush of meat scattered around the trunk, and your fork wont stick no matter what you try. I call this developer the 'spoon'. The spoon's job is to scrape up the remnants of the product, roughly form it into something that looks edible, and then commit the resulting mess, before pissing off down the pub. During this process, there is a good chance that the spoon will have missed a couple of forks that have fallen behind the table, still with a bit of meat attached. Branching in SVN is only slightly better than a nervous breakdown, but the end results are more or less the same.
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
> 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.
The resulting mess has nothing to do with Agile. If your process doesn't require testing, that's often the result. Testing is the most effective way to document specifications and is a common requirement that product owners choose to throw away. That's a choice made to improve the process. The fact the PO can't understand the result, is not the fault of the process.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
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
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).
that's the point. responding to change, quickly. you're saying that the goal of agile is the problem of agile.
you imply changing their mind late in the project is a bad thing? agile at least gives them an OPTION.
http://www.fastcompany.com/28121/they-write-right-stuff
This is my evidence that "proper software engineering" *can* work. The fact that most businesses (and their customers) are willing to save money by accepting less from their software is not the fault of software engineering. We could and did build buildings much faster than we do today, if you are willing to make more mistakes and pay more in human lives. If established industries and their customers began demanding software at that higher standard and were willing to pay for it like it was real engineering, then maybe it would happen more often.
Impressive stuff, and not unique to the space shuttle. Fly-by-wire systems are the same way. You're talking DO-178B Level A stuff. It works, and it's very very expensive. If it was only 10x the cost of normal software development I'd be amazed. I agree that way too much software is poorly planned and implemented crap, and part of the reason is that nobody wants realistic cost estimates or to make the difficult decisions about what it's supposed to do up-front. But what you're talking about is aerospace quality. You couldn't afford a car or even a dishwasher made to those standards.
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.
It frequently is. It doesn't matter what methodology you use- if you change major features/priorities at the last minute it will cost multiple times as much. Yet frequently customers expect it to be cheap because "we're agile". And by accepting that change will happen you don't push the customers to make important decisions early, ensuring that major changes will happen, instead of just being possible.
I still have more fans than freaks. WTF is wrong with you people?
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.
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
The customer has just as much of a right to experiment and be wrong about things as the developers do, but they can be trusted to say what is most important to them at the time.
The theory is that if you are always delivering what is most valuable as fast as possible, you are getting a better result in the short run, and will probably be just as good as rigorous design up front in the long term.
Don't forget Perforce. Branching/Merging is super with Perforce. CVS and SVN suck big time. People's bad impression of Version Control is mainly because of these 2 products.
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.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
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 customer's problems that you are trying to solve the cheaper, faster and better quality the result will be.
Cheaper? Yes, because bugfixing that is done later in the project is a lot more expensive (as numerous software engineering studies have shown)
Faster? Yes, because there's less rework. (Also, since there is usually a time = money equivalency, you can't have it done cheap unless it is also done fast.
Higher quality? Yes, because you don't just randomly stumble across quality. Good design trumps bad design every single time.
Agile causes anxiety in the clients because the first thing you do after the requirements have been gathered is to ask the client to prioritise them. Naturally the client is going to start imagining worst case scenarios, where the developers can't do everything they've been asked to do*, and so they push back, saying that everything is important, and then the developers want to know what is the most importantest (sic). The solution is to do technical prioritisation. If I go to Honda to tell them how to build my car, and then tell them that the tyres and steering wheel are the most important things to me so they should start building those first, Honda will politely tell me to let the experts do their thing. By analogy the whole thing of making the clients prioritise the features really only works when you've already got a car, and they're choosing what options to add (read as: additional features after you've done everything that was on the initial requirements)
*Not unreasonable, given that even the Agile evangelists say that 60% of software projects fail.**
**Before Agile became the dominant methodology the failure rate was widely reported as 30%.***
***Make of this what you will.
Agile can also cause anxiety in the customer for other reasons. Imagine if you wanted a wooden chair and your developers all ran into the forest and each started madly chopping down a different tree. When you tell them the particular type of lumber you want it to be made out of they tell you to bog off because they're not at that stage of the project yet. Of course, that's not actually what happens. In fact everyone is chopping madly into the same tree (but all at different heights ... )
Disclaimer: none of the Agile projects I've ever been on have failed. But then neither have any of the waterfall or RAD projects, or even those with a null or ad hoc methodology. The common denominator for success is not the methodology.
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"
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.
Amen.
Once upon a time [20+ years ago] the Air Force wanted "some Macs + software [written by somebody with an "in"]". But, they had to open it up to the RFQ process. They added a raft of requirements custom tailored to this "insider" system to try to guarantee that no other combination could match the RFQ.
However, the company I worked for met all the specs using a completely different system, even adding a "sweetener" such as you describe. The Air Force made it a requirement of my company, but not of the original competitor.
The Air Force awarded the contract to the original bidder. That is, until the GSA reviewed things and ordered the Air Force to award it to the company I was working for [we had the better system]. Rather than comply, the Air Force cancelled the entire project.
That was my first exposure to government contracting (and my last ;-)
Like a good neighbor, fsck is there
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.
We're getting buzzwordy here. To me "thinking hard about the business/customer's problem and coming up with solutions that meet all their needs" is the first and most important part of the upfront design, though I could care less what you call it.
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
Hmmm... Didn't seem like a problem when I was at SoftImage and we had several million lines of code and 80 devs. We had to adapt to changing market conditions, we had to get out ahead of our competitors, and we had to produce quality software.
That being said, we burned out a few QA guys here and there ;)...
Loading...
Bullshit.
If it's over budget when engineered, it means that you fucked up the budget in the first place. The difference between properly engineered and the ugly software that violates any possible best practices you can imagine, is that with properly engineered code you have more of the cost up front, rather than hiding it in trying to figure out what things like "I'm not sure why this is here, but the guys who wrote this quit years ago and removing it breaks the software."
You can never ensure 100% perfect code, but the best practices didn't get to be best practices arbitrarily, they address common problems that should be avoided. Gunky code is invariably, unstable and insecure code.
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.
Then keep the customer out of it, when you can. In many industries the customer rarely gets a chance to intervene. They may suggest features for the next release if they're a big customer but the only time when I've seen actual end-user customers involved with design is with contracting firms. Often instead the product may have many actual customers, from ten to one million, and so you have to rely on product managers to come up with the requirements. And if you have a product manager you have a lot of ability to push back if the requirements are changing.
Overall I get the impression that Agile works best with rapidly changing stuff that is pushed out to customers constantly, like a web site, but it can fall down when used with something that needs a more extensive design before starting. Agile also doesn't work well in industries that have strict regulatory control on processes, such as where every bug, fix, and change must be documented and filed. Now some of the ideas that Agile borrows are great, but they can be used outside of Agile (ie, test driven development).
A lot of these projects are created to ensure that the contractors are still in business in case they're needed. The stupid Boeing fuel tanker thing from a few years back wasn't because the USAF needed tankers, it was to make sure that the capability to make them was retained in case they needed something similar in the future.
In that case, Boeing was fine, but it was more about keeping them happy.
...but they can be trusted to say what is most important to them at the time.
No they can't. If you are delivering to customer requests you will always be a follower and never succeed. You need to anticipate what the customers need. As with the I guess made up quote attributed to Henry Ford, "If I listened to my customers I'd have been trying to make faster horses." Whether he said it or not, the statement is true. Customers know what they have and just want it to be faster/better/etc you need to find out what they really need.
Paying taxes to buy civilization is like paying a hooker to buy love.
But when I first heard about Scrum with its "pigs" and "chickens" I immediately thought of Animal Farm. :)
Call me crazy, but I always thought Agile was developed in response to customers doing exactly that, but under methodologies where it was much more expensive to do so.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
The way hardware usually works is that bugs get fixed in software, and the bugs often exist because there was no consultation with software to begin with. Very often the hardware gets designed with no input from software or firmware sides, and by the time someone working on the actual code gets to see the design for the first time it's too late to change it. Sometimes a workaround in software is not even possible or practical.
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.
No, the problem with Agile is that it promotes a mentality of "it'll be done when it is done", where vague double-talk is allowed to thrive. As such, customer service tends to suffer. Everywhere else in the world - outside of the siloed developers living in their Agile world - timelines matter.
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 be a couple bug fixes, could be an entirely new database schema that mandates a re-write of connectors that allow for other departments to interface with a vendors app... you never know until you check the release notes.
Thirty four characters live here.
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?
"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, and how much control you have over external dependencies. With respect to product owners, people can't just say, "here build this," and then disappear until it's finished. I've been there. It sucks. If there is one reason an agile project will fail, this is it. Product owners need to be fully engaged.
Finally, if the agile project is executed correctly, timelines shouldn't be *that* big a deal because the product owner is receiving delivery of the highest priority features along the way. I realize there are ways that this can be sidetracked (if, for example, the product owner decides that a delivered feature needs to be re-designed because of a faulty assumption), but that's what agile is supposed to accommodate.
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.
+1 though I do have to say, it is a very fine line to walk. I've had many customers come back with "we didn't ask for it, we're not paying" when the reality is, it often comes out to be the best and most used part of the software they are buying. The contract I am on currently is a prime example of the responsible parties not having a clue as to what they users of the software actually need. However, when building what the users actually need, the "stakeholders" get pissy about costs, implementation, etc.
Sort of, I find that agile works great in conditions where the product is in an industry with much regulation. Regulations tend to get changed, added to and sometimes even removed often enough in many industries that agile works great.
If you're doing it right, you're not having to "do it all over again". You're only having to change small portions of a piece of software rather than huge chunks or starting over.
If you're not accounting for overage/scope creep from the get-go, you're doing it wrong.
be glad they did, I did some work for the Air Force some years ago. It was a nightmare.
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.
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.
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?
No, don't be in such a hurry to move on, I'm afraid the next management fad will suck at least as much.
In the UK, isn't that what rugby players do and football hooligans are?
Like a good neighbor, fsck is there
As TFA points out, that always works fine when your requirements are *all* known an are completely static. That rarely happens in most fields.
Beyond 'hello world' that's always the case. Let alone in real-world projects the dates change, the team members change etc.
That's why the initial question to a customer who wants a software solution should be 'what do you want to accomplish', instead of 'what do you want'.
Nihil in publicum sputa.
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 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."
It does nothing of the sort. The methodology doesn't affect the scope of work, which (for fixed projects) should be specified in advance.
If you're asked to do something that is outside the agreed-upon scope, you re-negotiate the delivery time and the payment. End of story. Your coding methodology has literally nothing to do with it. If someone has pulled that on you, then somebody didn't firm up the original agreement like they should have. It's often a failure of management.
Sorry did we just step into a dimension where modular software no longer exists? There's no reason one can't start by designing a framework and then create small mini projects or even use agile programming to finalise the actual features or the user interface.
I like the earlier example further up saying that classical methods don't suit software like financial software because the rules change so often. Well financial software didn't just pop up in the last 2 years like agile did, and it's always been perfectly functional.
It seems people screaming for agile are those who don't know how to build agile software, and instead opt to agilely build software.
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.
They don't care what development process you use. The customer will change their mind late in the project anyway.
So it's not bad to take precautions for that.
bickerdyke
Yes. But Ford's car didn't take away the horses from the users. Rather seing the car made them want to own one instead of a horse. So you can't push any features onto customers, they will feel like they had their horses taken away, and NOT as if they just had been given a car.
bickerdyke
Only if the customer is willing to pay for the extra development time. If it's a fixed cost project the developers and the customer should have a contract to protect each others. if it's not, even for "pay as you go" projects usually customers compromise between what they wish and what they can afford both as cost and as delivery time.
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!
Um, that's kind of the point. It caters to that very fact of life, and you charge them for it.
To put in a rather simplified manner, the agile business model for clients should basically be that:
You give them a rough estimate of the time needed for their initial requirements by number of sprints, so it may be say, 20 2 week sprints with a sprint of 5 developers be charged at x rate. You produce a product backlog of all tasks at the start and prioritise them with the customer. You have a burndown chart that shows roughly what will be completed each sprint, this chart is a simple graph of feature completion against time so it is normally just a straight diagonal line starting at the top left (no features completed at start), and ending at the bottom right (all features completed at end).
At the end of each sprint you produce something from the set of features for that sprint and show it to the client, if they want to change or add anything you throw it on the product backlog and update the burndown chart. It may be that at this point that that changes and it now finishes past the original estimation point. That means the client can see the impact of the changes they requested and consider whether they really do want to pay for an extra sprint or whatever, or if they want to remove other features to still hit the deadline.
It controls cost and that's the point, it forces the client to consider the impact of any changes they request. The downside for some clients is that they can't abuse holes in specs and contracts to hold you by the balls to do additional work for free that you hadn't budgeted for (because all specs and contracts have holes, period.) but the upside for more honest clients and for the company doing development is that the client gets exactly what they pay for, no more, no less. They don't get ripped off, and they don't get to rip you off. Instead of paying for an arbitrary packaged product which can easily have overruns the client is paying to use your resources at some specific markup, hence why costs are controlled.
I'll be the last person to believe that agile is a silver bullet, I know full well that it's just another tool for the toolbox to be used when appropriate but it is rather tiresome to see all the people complain about it who are using it wrong, and then often say "People always just tell me I'm using it wrong, but it's not me it must be agile!" - bullshit, you ARE using it wrong. It's like a lot of developers haven't really learnt the whys, whens, and hows of agile and so make a complete hash up of trying to implement it then blame the tool. To give a programming analogy, it's like writing something in C/C++ without fully understanding pointers - you'll probably just about get something running, but it's going to be a buggy bloated, memory leak laden mess.
If you genuinely understand agile, and if you know when and how to use it, then it's a brilliant tool, but if you're a fucking idiot then you'll still be a fucking idiot even if you try and use agile.
Many of the comments modded up so here reflect that inherent lack of understanding, people are saying things that are just flat out wrong and don't make any sense if you actually have even a basic understanding of the point and use of agile.
I've used agile (SCRUM) and waterfall extensively to deliver projects and I don't pretend either is better than the other all of the time, but I know enough to know that most of what's said here about agile is bullshit born from inexperience and/or incompetence.
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.
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.
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.
...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.
That's not the difference between Agile and Waterfall, it's the difference between tailor-made contract work and selling a product. No customer is going to bear the risk for your crazy idea. They want what they know will work.
But if you want to make them something innovative anyway, showing them working results early makes it a lot easier to get their buy-in.
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 be a couple bug fixes, could be an entirely new database schema that mandates a re-write of connectors that allow for other departments to interface with a vendors app... you never know until you check the release notes.
In Scrum, the team commits to certain sprint goals, and the sprint takes a set amount of time. Not meeting the sprint goals is a big deal. It's not the end of the world, but often missing your sprint goals will be noticed. You can use this to estimate when it will be done.
Scrum also used to work with burn-down charts that gave pretty decent estimates of when it would be done, even taking scope-creep into account. But I've recently been told burn-down charts are out. I admit I don't quite understand why.
It has? You've clearly never worked in financial IT.
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.
"Little does he know, but there is no 'I' in 'Idiot'!"
As much as I hate the buzzword "design patterns",
The title of an 18 year old book is a "buzzword"?
People who roll their eyes at the phrase "design pattern" irritate me. There's nothing wacky about noticing effective ways people have solved a problem in the past, and giving those patterns names so that they can be efficiently referred to.
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.
From personal experience, it depends on how much knowledge of the final requirements you've got. One thing you've got going for you that the initial team didn't is the initial work they did figuring out requirements. They may not have produced a workable result, but the Agile team you're "rescuing" almost certainly accumulated a lot of information about what exactly's needed in the final product. You get to base your design off of that.
The hard part of course is where you aren't rescuing another team and don't have all the information they accumulated. That's where waterfall breaks down, because it's hard to do the whole design when you don't have much clue what you actually need to build. You have to do a lot of thinking and basically sketch out almost the entire final system, and that takes more time than management's usually willing to allow without seeing some kind of results (which you won't have because until your design's finished you can't start coding and producing what management would call results). Bear in mind that waterfall development got a bad rep precisely because of an accumulated history of failed projects, missed deliveries and products that didn't do what was needed (there's a lot of truth to the line from a filksong "It's just what we asked for / but not what we want."). Don't ask how many times we've started into things only to find out about huge areas that nobody even thought existed.
Simply put, if you're doing something that hasn't been done before you need to do a lot of exploration to figure out what the users really want and what the best way of doing it is. Agile didn't just pull the idea out of thin air, it came from the acceptance of decades of hard experience: on a non-trivial project you do not know and can not know all the requirements and gotchas going into it. The problem is often that management doesn't accept this, and they tend to panic just at the point in an Agile project where the developers have finally gotten a good handle on the requirements and are in a position to nail down a good design and start working towards it. That's compounded by a lot of Agile teams not having group buy-in on a single design and set of requirements. You don't have to get everybody to agree on what the best design is, but you do have to get everyone to agree on what the design will be for this project. When you don't, when you get every developer with their own idea of how it should work, it all falls apart.
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.
Yup, branching and merging in SVN sucks. The original author even admitted that the existing support is incomplete (). Use a better version control system such as Mercurial and Git from the open source world, or Perforce and Plastic SCM from the proprietary world. Do not use Accurev. I repeat, do no use Accurev.
Yet, in practice there's a huge difference:
In a waterfall scenario the customer most often doesn't see anything tangible until way late in the process. Only then are they able to see the project is off course...and by that time it's way, way off course requiring a large, expensive change.
In an agile scenario the customer sees everything early and often, allowing them to keep the project on course with minor adjustments along the way. Any changes they make late in the process are almost certainly to be a fraction of the size of changes they'd have required late in the cycle of a waterfall project.
Forcing most decisions to the front of the process only ensures that they are either wrong or take so long to make that they are no longer relevant by the time the product can be delivered. How wrong and how irrelevant is proportional to how much, how strict, and how early in the process you mandate decisions be made. This is why waterfall most frequently falls into the trap of delivering, "Exactly what they asked for, but not at all what they want/need".
Agile isn't about not making decisions early. Completely the opposite: Agile is about providing the knowledge required as early as possible to make good decisions. Decisions (aka "changes") are made as early as it is possible to correctly make them...and correct from mistakes as early by discovering them sooner.
By contrast waterfall forces most decisions to be made blindly, all but ensuring they will be very wrong, and only discovered after its much, much too late to do anything about it.
My
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.
"Changing their mind" is always bad. "Realising their mistakes" and "revising their assumptions" are good. The goal of "agile" is to adapt to new information, and to allow for the continued flow of new information. "Changing their mind" breaks that flow. It's not new information, it's something completely different. You can't "adapt" to a change of mind, you just have to start from scratch.
If your customer thinks agile lets them change their mind any more frequently then any other design philosophy, your customer needs re-educated. If you think agile lets the customer change their mind any more frequently then any other design philosophy, you need re-educated.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Call me crazy, but I always thought Agile was developed in response to customers doing exactly that, but under methodologies where it was much more expensive to do so.
Agile was about uncertainty in the spec. It allows you iterate and incorporate new information as and when it is discovered. "Changing your mind" means ripping it up and starting again, and that's no less painful in an agile environment than any other environment -- code that can be reused will be reused in the next design cycle, but an agile process is a continuity, and a change of mind is a discontinuity.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
If you're doing it right, you're not having to "do it all over again". You're only having to change small portions of a piece of software rather than huge chunks or starting over.
But that's nothing to do with "agile", is it? That's just a matter of high encapsulation, low coupling and other coding practices that result in high reusability. Agile methodologies might actively encourage these practices, but all good coders should be working that way anyway.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Except that you clearly didn't follow the same rigorous software engineer process as NASA. Dividing LoC by num_programmers says your guys spent significantly less time on the code than NASA, which is to be expected.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
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
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.
Oh, us poor beleaguered software engineers, everything gets dumped on us! Hardware screws up and we have to fix it.
Gimme a break. I see it from both sides. Yes I have an advantage of sorts when I get to design both the hardware and the software because I'm eating my own dog food (not so bad if you're a good cook), but if hardware gets designed without consultation with software then you're working in a disfunctional organization, period. Believe me, the hardware people in your organization have plenty of complaints about software too.
BTW, that "hardware gets fixed in software" line especially doesn't cut it when designing analog/RF or even digital that just runs too fast for software intervention.
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.
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.
The *point* of Agile is that there should be no time that is "late in the project".
With fixed, short, repeated cycle of iteration/sprint/whatever-you-call-it, such as 2-weeks sprint cycle, *every* cycle should be start with work estimated to fit in the cycle, and ends with deliveries of completed work that delivers value to the customer. It should work the same for the first cycle, just the same as the last cycle.
If there is a point in time that is considered as "late in the project", you are doing Waterfall, not Agile.
Oliver.
Sorry, this is nonsense.
In agile development you also have timelines.
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.
It does nothing of the sort. The methodology doesn't affect the scope of work, which (for fixed projects) should be specified in advance.
If you specify everything in advance, you can only start developing _after_ everything is specified.
In agile development you can start as soon as you have some "stories".
Your coding methodology has literally nothing to do with it Correct.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
The idea with Agile is that any changes are presented to the customer in terms of how long they are going to delay the project. Its up to them if the delay is acceptable.
Of course that only works if you have the balls to tell them that the change will add a year to development and double the cost. You also have to be ready to fight off claims that you should have made it more flexible in the first place so it shouldn't take a year.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Your problem here is using SVN while your work style requires something like git. SVN is not suitable for feature branches.
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?
"Then what you were doing wasn't agile". Yes, I know that is getting said a lot and dismissed, but it is completely true.
Agile REQUIRES process. It is just a different process than traditional SDLC. You replace some process controls with other controls.
Agile REQUIRES automated tests, and really TDD or BDD. This was true back with the original Xtreme Programming book from Kent Beck, and continues to be true. If you do not have a full suite of automated tests, both unit tests (mstest, nunit, etc) and integration tests (selenium, etc), then you are NOT DOING AGILE. The product owner doesn't get to "decide" this.
Did you pair program?
Did you frequently refactor?
Did your refactor only areas of code you were working in to support the next feature?
Did you offer insight and other options on features to the product owner?
Did you actually do use cases and usability testing with real users, not just product owners?
Did you do that testing every iteration?
Did you have a shippable product after every iteration?
Did you have build automation setup to the point of continuous deployment?
Did you really do agile?
So many places just toss out the whole SDLC and call it "agile". It is not. In your specific case, just the testing comment alone tells me that you were not actually doing agile.
Agile has formal process. There are some differences in the process details between scrum, kanban, lean, etc. However, they all have them.
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.
This is why you should keep the pure programmers to the higher level functions and let the HW engineers write the hardware interface. They still need to write debug code to test the hardware (Unless you enjoy sending prototype hardware between SW and HW engineers just to find out if the problem is a SW or HW bug.) so they might just as well add the extra glue to make the hardware abstraction. This way the HW bugs are discovered early in the prototype stage and the right person is given an opportunity to do a proper fix before it leaves his desk.
You still want the SW-guys to be involved in specifying the interface to the HW access functions, otherwise you will get an extra level of bloat when they try to adapt their code around the access functions.
An excellent approach. It forces the hardware guys to think about the software. It's also good for a team if at least some of the software people have a good understanding of how to write low level code to talk to the hardware. Even if they don't do most of it, it helps them to specify reasonable interfaces.
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.
http://xsisupport.files.wordpress.com/2012/09/softimage2013cer.png
I'd suggest that Autodesk and its ilk crashes far more often than NASA software.
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.
I think everyone agrees that the article is 100% true.
What does that have to do with the issue being discussed?
My comment isn't some comparison to whether or not NASA software is more or less stable.
I'm replying to someone who says that "proper software engineering" doesn't work and that code that does work is invariably ugly and violates best practices.
Someone countered with "well, NASA seems to disprove that with the following example", which was then asserted to be a very special case because NASA had a large number of people in a relatively small amount of code written to unchanging (basically) specifications.
I'm countering that with an example of what was a well engineered codebase with far less people than NASA used and far more code, and the code works well.
Loading...
Two timelines....always broken! Everyone hates Agile except the Agile trainers and the one writing Agile books.
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 exactly what the change is and how good your devs did with design. With Agile, X is 100%, and the cost tends to be fairly high because there is no design and no effort put to possible future use cases or changes up front.
I still have more fans than freaks. WTF is wrong with you people?
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.
That's definitely a problem, and it needs to be solved. If you can't have a Product Owner who's available to the team, you can't do Scrum. Product Owner is a vital job. It doesn't have to be the customer, though. It could be an analyst who knows exactly what the customer needs. That is absolutely fine, as long as the analyst keeps in touch with the customer's wants and needs.
Also, customers aren't (necessarily) users or vice versa. That's a major piece of tension right there.
That's a problem with every methodology.
Hey, it's Mr. Strawman. I haven't seen you in days!
First off- waterfall doesn't exist. It never has. It was made up as an example of what people thought development was like, and then immediately used to contrast with how software really was made. Really- check out the history up front.
Secondly, nowhere did I say waterfall was the preferred method. THere are more than 2 options here. Shocking, I know.
Agile is absolutely not about providing information to make decisions early. By the point that you get enough functionality into an Agile project to make any non-trivial decisions on projects of non-trivial scale, you're already many months in and have an architecture that changes will force you to throw away. You're going from possibly needing to throw away work due to changes to assuring it. The costs are no less, and actually tend to be higher than other forms of iterative design.
I still have more fans than freaks. WTF is wrong with you people?
THat's the same with any methodology- if they want a change you scope it out and give them a number. Agile is no better or worse at it. If anything the numbers tend to be a bit higher because of the tenet of not working on anything that isn't needed immediately, whereas when you design up front you tend to design in some flexibility for likely future changes/usecases.
I still have more fans than freaks. WTF is wrong with you people?
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
With Agile, X is 100%, and the cost tends to be fairly high because there is no design and no effort put to possible future use cases or changes up front.
Of course there is design and effort to get as much stuff as possible sorted out up front. But it doesn't have to be perfect, and it can adapt when something is missing, incomplete or wrong.
Making sure the design anticipates every possible future need costs a lot of money, and most of that will be wasted. It doesn't have to be perfect at the first try, and you don't have to spend a ton of time and money to refine it until it's perfect before you can start programming. Do what you can up front, but there's still room to adapt later on (as long as you don't postpone everything).
Companies don't want to wait for "systems engineering". It's why nobody does it in IT. You are seriously clueless.
Are agnostics skeptical of unicorns too?
That video hit way too close to home. Agile gets the small projects done really fast and delivers quality code. But when the roject owner doesn't have enough time to ever bother to run through the app and the project manager gets distracted by doing web design and sys-admin stuff. Agile turns into a disaster of never ending churn of nit-picky changes without ever getting the project out into production six months later.
it's true but people here are using these unrelated things as arguments against agile.
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.
Using a car analogy, isn't this really the difference between how Porsche upgrades the 911 series every year, and how other auto companies come out with completely new models? Doesn't Agile work best when you can make multiple deliveries, instead of doing a complete ground up design each time?
Please excuse my ignorance. My software development work ended several years ago, when I was just starting to read about Extreme. Now I drive schedules and spreadsheets.
Just another day in Paradise
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
"If you specify everything in advance, you can only start developing _after_ everything is specified."
I did not say or even imply specifying everything in advance. I only mentioned a scope of work. That has nothing at all to do with waterfall-style management. A scope of work is just a general description of what the eventual goal is, not of how to accomplish it.
But if your scope of work says "Build a website with features X, Y, and Z", then the customer at some point says "We just realized that our business objective will also require feature Q, and Y has to be changed to do Y version 2", then that's outside your scope of work and you charge more.
Agile doesn't solve problems. People do. There's your problem right there.
That is all.
You have a single point of failure, and that point of failure is the product owner.
I'm pretty sure the product owner will be a serious point of failure no matter what methodology you use. I've been on a couple Agile teams with bad product owners/managers, and felt like we succeeded despite them.
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.
Wow. That's weird. The Agile practices of teamwork, team room, pair programming, and collective ownership would seem to be very much about making a team cohesive and empowered. And retrospectives (to me the most important part of Agile) should have been a place to address such problems. If you were not using those tools, then I don't think you can blame the tool set.
Software sucks. Open Source sucks less.
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.
Not all the time, but more than half the time I've seen hardware get designed without interacting with the people who are actually going to have to write or fix the code for it. Sometimes it works out, but much of the time it is a royal pain involving not just patching firmware but having a large redesign, or downstream effects causing the entire product to be many months late. I always wonder if it is worth getting the cheaper part when there is so much extra development cost that results.
Now sometimes I think this sort of stuff happens because the hardware people think they are communicating, but they're communicating with the wrong person. Maybe they discuss things with a software manager who's not as familiar anymore about implementation details; or worse I've seen them talk to a director level person. Sometimes even the software person isn't diligent enough to realize how radically a design is going to be, or is a junior person who doesn't feel able to push back. Or they talk to the software guy who says "it's not hard" even though he's not even involved with the product.
The biggest problem I think is that often there's just a huge amount of pressure to make some changes, such as cost reduction, that it is going to happen despite any objection.
Sure it's dysfunctional to not communicate properly. But everywhere is dysfunctional, it's a fact of life.
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."
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.
It is more than the way the code is written. By having smaller deliverables that are put into production immediately instead of waiting for quarterly releases, you get immediate benefit from the deployment and immediate feedback on an individual feature. This means that the business unit can adapt to incremental change instead of biting off a huge training project and bug fixes are immediate and targeted rather than a deluge of disparate unrelated issues.
With or without agile processes, breaking changes into small deliverables, prioritizing by business impact and deploying each change as it is ready is a great way to work, when possible.
Yet another frantic debate about Agile on Slashdot where the word "testing" is only used a handful of times. :(
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)?
Eh? After 38[1] 2-week sprints developing an accounting package the bean-counting dunderheads tell you it needs to support multiple currencies. Are you saying that's early?
[1] Including 17 that were about changing the colour to get more RAM.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I couldn't tell what the funting cuck they were saying half the time, so I turned the subbies on. Try it.
I think the only bits it gets right is where the brown one is talking about getting drunk.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
If that's the first, where does getting the bastards to tell you what the problem is fit in?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
By contrast waterfall forces most decisions to be made blindly, all but ensuring they will be very wrong, and only discovered after its much, much too late to do anything about it.
They've been doing it in civil and mechanical engineering for decades. That's what plans are for. They're cheap to change before you start building something. If your clients can't discover that you are going about it wrong, then you didn't give them sufficient planning documents. Try walking into a commercial building under construction and telling the engineers you hired that -- oops -- you want 12 foot ceilings instead of 8 foot ceilings, but you didn't realize that until you actually saw the building. Without hesitation, the engineering firm will whip out the spec that you signed and say, "well, that's not what you agreed to."
All Agile does is hide the true cost of allowing design changes at arbitrary points in the process. Whether with waterfall or Agile, changes are expensive. With waterfall, when you properly manage expectations and thus don't have to deal with significant changes, you know exactly what is required throughout the project -- redundancies, opportunities for abstraction, and overall design efficiencies are evident from the beginning -- so you save on cost AND build things efficiently. With Agile, on the other hand, those extra costs are already built in and unavoidable. You're never looking at the big picture, so design efficiencies are not always evident until part of the work has been done. The iterative builds and deployments take up valuable coding time. So even you DO properly manage expectations with Agile and don't keep chasing your tail with changes, the cost will be far greater, and the efficiency much lower, when all is said and done.
Re: (Todd Knarr's comment) : "Simply put, if you're doing something that hasn't been done before you need to do a lot of exploration to figure out what the users really want and what the best way of doing it is" Right on the money ... if what you are being asked to build is "Version 2", then you have a lot to work with, but, if you are making it up as you go along, then it's better to admit (at least internally) that you are doing so, and accept the constraints.
This whole topic could have been titled "Why your users hate Development!". :-)
Before debating waterfall vs. agile, I would ask some basic project questions, on the management side:
* Is there a single business case / requirements owner who can quickly sign off on what you are building, or is this large committee-ware?
* Have initial requirements been at least sketched out?
* Is this something that has been done before (by members of this team), or is this a new application/problem domain?
* Is someone on the team taking the role of project manager, or is that unclear to the team?
* Is someone on the team taking the role of lead architect, to help assure design consistency and to look for holes?
* Has the problem been divided into manageable pieces?
* Has each developer on the project been assigned specific authority, responsibility and deliverables (even if prototyping)?
* Does the development team have "critical mass", that is, do enough people on the team possess the skills and problem domain knowledge to move forward quickly?
* Is the team the right size? Larger groups, by definition, have more communication problems and are less agile than smaller teams.
If the answers to these questions are negative, the selected methodology is unlikely to overcome such basic problems.
"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
Eh? After 38[1] 2-week sprints developing an accounting package the bean-counting dunderheads tell you it needs to support multiple currencies. Are you saying that's early?
[1] Including 17 that were about changing the colour to get more RAM.
That is neither "early" nor "late". You estimate the effort required, break down the stories into manageable small chunks, then let the dunderheads priorities the stories, and then off you go to the next sprint.
It may take 10, or 20, or 50 more sprints to have all the multi-currency requirements completed, but does it matter if it was the 3rd sprint, the 38th sprint or the 380th sprint? If it does, you are doing waterfall. For agile projects, it shouldn't matter. If the dunderheads aren't willing to pay for the additional stories, that's another problem entirely.
Yes, if they had included multi-currency at the 1st sprint, then you won't have a stories worth 10/20/50 sprints to do at the 38th sprint, but you just had those same amount of effort spread throughout you other stories, which would result in similar total effort anyway.
Or are you going to say your codebase was already a mess by the 38th sprint, when everyone was hope the project would finish so they don't have to deal with the accumulated technical debt? If you are going to say that, you already spotted the problem, and that is not with doing agile.
Oliver.
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?