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?"
"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....
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.
Agile taken to an extreme can be a PITA. If a customer orders a car, they want what comes out of the factory to have four wheels and a steering wheel. Agile development means that who knows what the end product will be... will it be a bicycle, will it be a lorry, will it be a motorcycle, or perhaps it might be a unicycle. The only person who knows is the one with the loudest voice.
This isn't to say that waterfall is the best dev model, but there should be a balance, so one at least has a vision of what the end product will look like.
He says it quite nicely:
http://martinfowler.com/bliki/FlaccidScrum.html
Of course that was in 2009. Nothing has changed, and I've long past the point of being fed up with the non-technical fuck-tards that think they can sprinkle Scrum-dust on a mountain of technical debt and it'll go away. This is usually done in the presence of a stable of bad developers who lack the discipline to do the actual hard work of the XP practices that deliver good products in the first place.
The parent article author can STFU already. It just reeks of, "Wah! My agile hurts me because I won't do the hard stuff".
Oh, and while your at it agile wimps: stop fucking trying to do "distributed agile" with fucking China and fucking India in order to save 30% on what's already a crap-pile due to communication problems. It's not going to help one bit.
Also, get off my lawn...
*** Sigs are a stupid waste of bandwidth.
The customer thinks they are ordering a building, metaphorically speaking. They can walk around it in their heads, see the color of the drapes, measure the windows, there are quantifiable costs. You don't build things using agile techniques however. "Well, we'll put this skyscraper about here. Start digging and we'll see how she goes."
"The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"
How? Don't even talk about agile to the customer. Can you imagine a surgeon... "Well we'll just start cutting and figure it from there" no no, talk about outcome, not process. Agile talk is for the operating room, not the waiting room.
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
Because, as every good manager knows, all problems can be fixed by making them more agile!
Is your well oiled development team on schedule, and the producers are twiddling their thumbs with little to do? You need to be more agile!
Have recent changes to the way your dev team works caused an on track project to go off the rails? You need to be more agile!
Have your senior developers got so fed up with the piss poor management team behind your project, that they've all just quit? You need to be more agile!
Has your company just gone bankrupt due to a lack of developers, and a lack a product? Have you considered becoming an agile consultant?
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.
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.
If you're not doing Xtreme Agile, you're not doing Agile right.
Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.
"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.
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?
Easy ...
Developers hate Agile because it, when combined with incomplete/inadequate specifications, is quicksand for developers.
Management loves it because it allows them to commit to anything. The mindset management has is the developers can throw together an "Agile" solution without management having to do their part of the job.
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.
"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.
You can't build a chicken coop properly, much less a modern house, much less a skyscraper without *really detailed* specs, the bigger the project, the more detail. And everyone buying the building or building it is supposed to realize that any changes are really expensive. How can you tell the client what even a simple structure will cost without knowing a whole lot about what's being built? Even then, with literally thousands of years of practice, construction often has cost overruns or worse, structural problems.
But for software, we almost always pull numbers/timelines from our backsides and almost all software projects just flail on until it's good enough or collapses. Just making shit up as you go and calling it a methodology is sad.
Peace is easy to achieve, just surrender. Liberty is much harder get/keep.
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
If anyone thinks that there is complete, 100%, nailed down design for a 75-story skyscraper before any digging starts, and that the design for the 69th floor is similarly nailed down before the 3rd floor is finished, they need to spend some time on a construction site. The overall shape of the building, the structural design, the very bottom and top floors, and the allowable parameters for design of the later floors, sure. But the exact design of floors 50-72? No. Plan for what happens when the selected elevator supplier goes bankrupt, the ship carrying a key delivery of structural steel sinks, the developer finally signs a tenant for 68-70 and he wants an internal staircase and private elevator for his offices? No. Look up "fast-track" in a construction dictionary.
sPh
If you're not doing Xtreme Agile, you're not doing Agile right.
That is correct comrade. Failure is always caused by insufficient ideological zeal and purity.
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.
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.
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.
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.
False analogy. Designing and creating a car is much easier to manage as a "waterfall" since it is so much harder to change and the problem domain is often in less "flux". The sheer energy and expense to design a car; which consists of market research, basic R&D e.g. engine and tire materials, the design of the car, the design of the factory, the design and construction of the manufacturing equipment, the training of workers, etc., is so huge that upfront design makes sense.
In software the problem domain is often in flux, e.g. financial reporting regulations, and the cost of changes in software are lower. So software must be soft or lose relevance AND the fact that it is soft creates the danger of too many changes. We cannot think of software as no different than a factory, that is the original sin of software development.
putting the 'B' in LGBTQ+
Users don't hate agile. They want a system that is usable, delivered quickly and that works. When done correctly Agile does work and gives users what they want. but it does have its drawbacks especially in dealing with larger teams and larger problems. Users are also a subset typically of stakeholders. Stakeholders come in various categories but the more important the stakeholder, the more influence and stopping power they can have for their project. It's up to your Scrum Master or PM to keep them happy and if they're not, you'll be out on the streets in no time regardless of the methodology. To keep key stakeholders and keepers of the PMP flame, there are techniques and methods to reign things in but also not to make it draconian as to prohibit actual productivity. On the other hand those who hate agile are the ones who usually have invested a lot of time in "process." While agile has it's processes, they are considered anti-patterns by those who have defined things like structure and status reports and 'check the box here, did you check it? I'm still waiting for you to check the box. I haven't seen you check that box yet, were you going to check it? You have to check the box.' It reminds me of this.
What bothers me more and more is the FUD that's generated around any process change that instantly creates this knee jerk reaction against any changes to Software Development practices and techniques. Shit, if we all stuck our heads in the sand, we'd still be writing COBOL on Mainframes with POS facilities like TPF/ISPF. Anybody for punch card compilation? How about decolated listings?, that tablet thing is just a fad and you need to use pencils on 5 part form paper the all the nice carbon paper stains on it. No Fucking way do you need visual tools... Those are bad and promote bad habits we can just program everything with the switches on the front panel of the computers, yeah, bring back front panels and switches and blinky lights. That way we can troubleshoot bad instructions by looking at the registers...
Shit, when RUP came out everybody bitched that it took a special set of software to do those funny use case diagrams but guess what they didn't realize that it was the modeling that was key, not the tool but that point was missed and everybody wrote it off. Use Case driven development? It will never work I heard, shit that was what 15, 16 + years ago and people still bitch.
For those who don't like Agile, I suggest really trying to get involved with it, try it you may like it if not don't work with it and certainly don't work on an agile project if you're against the methodology; all you'll do is fuck it up. For those Agile folks who claim all the other processes are bad and don't produce anything, you also have to realize that businesses are defined by their policies and processes, for Agile to work you have to be able to live within that structure and not all software is done in an incubator setting with you and your fellow software developers being bunk-mates all living on Top Ramen. There are processes in the world, requirements and not all of them can be told as simple stories and for those who don't like architects, too bad, they help keep the orchestration together on those bigger projects and yes all systems have "qualities" that nobody likes to talk about when you start talking about scaling and all the other non functional requirements that won't show up on your story board.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
I second the advice of not exposing external customers to internal processes. If developers want to use an agile process internally, fine, but talking about agile processes like Scrum to clients is bound to make them uncomfortable. I'm not surprised at all that users hate agile.
Customers don't want to hear that their feature request will need to be made into a Story and put in the Icebox, and that afterwards you'll play Planning Poker and put it in the next Sprint. It's really just elaborate way of saying "OK we'll write it down and do it later", and doesn't really give anyone any assurance that 1) you know what you're doing from a technical POV or 2) that they will have what they need by the time they need it.
Non-committal is a big issue for agile. If you want, do all that Scrum shit internally with your team, but just tell the clients in plain English that you need to figure out how much work is involved, and that you'll give them a timeline and will stick to that deadline.
Another part of the problem is stupid terminology like "epics", "planning poker" and "ScrumMaster" (TM). Personally I find it embarassing to our profession - real engineers use technical jargon to describe the systems they are building and how they operate. But software engineers are completely obsessed with process and methodology - and are only able to talk about these things. It's amazing how we understand so little about the businesses we automate.
This attitude explains why software still sucks so badly - people making exactly the same mistakes they were making forty years ago. Mistakes which could have been avoided had they spent a day reading "The Mythical Man Month".
I don't know where you learned your Software Engineering, but at my university, the SE courses included lots of case studies as well as studying the various methodologies. Our professors had a very good understanding why some large project failed, yet again. So be dismissive of the Ivory Tower if you want, but don't fool yourself into thinking they know nothing.
I'll grant there's lot of things to get right, but can we at least learn from previous failures and stop repeating the same mistakes again and again?
Plan My Week for iPhone
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.
...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.
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 a problem.
You seem to fail to understand that there is no difference between designing a car and designing a software product.
All the things that go into designing a car should go into designing software. The fact that you don't do it that way shows the failure is you.
Chasing the current fad is for those without the ability to produce something of quality. They don't provide actual benefit, just waste resources.
The reason that software 'developers' get by with it and engineers don't is because most software can't result in someones death, where as an engineering failure on a car can.
You've tried to compare apples to oranges ... but only because you don't realize your oranges are really just another apple.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
"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.
Uhh. One simple example of how they are vastly different.
Cost of recalling 5 million mufflers due to tiny flaw in production == HUGE
Cost of minor bug fix for (almost all) software == not so huge
This single difference drives all sorts of different optimizations for process.
Agile processes deliver useful working software at frequent intervals -
I love that definition... If you failed you weren't doing Agile..
Just because you've produced something working at frequent intervals, doesn't mean the user won't see it as "disorganized and never-ending"
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.
False analogy, yes. But not for that reason. The real analogy would be: I ordered a car and working with the engineering team I slowly discover I needed a camper van. That's what I get home with and end up much happier because I got the right product. Obviously that analogy applies to custom designed software and is seldom appropriate with cars. If I buy something off the shelf, think about a car or about Word, I usually know what I need because I already used it. But Word as seen from inside MS is custom designed software. I don't know if they use Agile to build it but they could.
In a project I've been working on for part of the last year the general direction didn't change much but we made many discoveries along the way. We started with some high level documents and some more detailed ones. The only ones that survived the first three months of development were the high level ones, which we kept adapting as they provide a good orientation map to the project. The detailed ones were superseded by what we wrote as the development team worked on the code. We could have spared us the trouble (and time and costs) of writing them. Lesson learned for the next time.
Of course there's a big difference. Software is essentially the most malleable and fungible thing humans have ever devised. The big problem in software engineering that doesn't arise in automotive engineering is that in software engineering, the requirements are frequently in flux. If you can fix your requirements as precisely as the requirements for a car, than yes, there is no difference. But in general this isn't true. Unless you're writing software for NASA or something similar, most such requirements often can't be so easily nailed down. You get a giant spec, build the thing, and then realise that the process the software is designed to integrate into doesn't quite work the way the spec says it should. I've been in the software business for close to 20 years and except for a brief stint in embedded systems this has always been the case in my entire professional career. We build something and halfway through the design we find it doesn't quite work the way they customer wants it, even though yesterday they said that was what they wanted it. Are you going to tell the customer: "fuck you, you said it should work that way and that's the way we're going to build it!"? That is not the way to treat any customer, most especially when you can, with some additional effort for which you should be duly compensated, accomodate their desires. Defective brake pads can cost a car company billions in recall and replacement. Similar bugs in software can be fixed almost painlessly by comparison. Software can also be far more complex than cars. A typical car probably has a few thousand distinct parts. Software like the Linux kernel has distinct parts in the billions. Try to tell me again how there is no difference between designing cars and designing software.
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!
I've worked in lots of places that claimed to do Agile, but few really did. Often it meant doing daily standups (or even sit-downs in one case!) and not having any good specs. Right now I'm working at my first contract that really is Agile, and it's fantastic. It is chaotic, but not because of us; it's the reality we're facing. We're doing several projects at once, the designs had to be sent back several times because they were wrong, business isn't really sure what they want, and we're being productive in spite of that.
We tell business what we need from them in order to do our work, instead of the other way around. We don't accept issues that don't meet our standards, and as a result, more and more issues do meet our standard. When we uncover a misunderstanding, we can change direction on a moment's notice, and because business, admin and others show up at our standups and our sprint demo, we discover these misunderstandings pretty quickly.
Not all is perfect. Not everybody around us really gets Agile, and particularly our tester would be much more at home in a Waterfall setting, but for me personally, it's working very, very well.
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.
Speaking as an Agilista. Just because you're doing Agile doesn't mean the project won't fail it just means you spot it going south earlier and thus save money by pulling the plug before you do six months additional work. Of course even in Agile you can have bad management which can make a project fail.
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
You seem to fail to understand that there is no difference between designing a car and designing a software product.
I beg to differ. Cars have a fixed design: body, chassis, steering wheel, gears, seats, engine, tranny, suspension, fuel tank, exhaust, etc. Car manufacturers only change the spec of each of these components. Once you've manufactured cars for a few years, you know how much time and effort is required to make small changes for the next version.
The same does not apply for designing new software. Software design's scope is several orders of magnitude bigger than car design's because the former can do much more than the latter. Sure you may know how to write the GUI and program the database. But there are still many other pieces of the software you have not built before. These new components are brand new. So they can't be planned like you can plan a car component or a construction building. That's because you are building it for the first time whereas these car components and building structures have been built and perfected for decades or hundreds of years.
If you're not doing Xtreme Agile, you're not doing Agile right.
Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.
well.. there's a difference between doing agile where you're supposed to and in making the user a part of the testing team..
why would the user care how the sw is developed? they don't. but if the fucking sw they have in active deployment changes where buttons are weekly as the developer is doing reactive development, that is going to suck balls.
world was created 5 seconds before this post as it is.
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'!"
I almost thought this was a troll it's so crazy. Of course there is a huge difference between designing a car and designing software. Manufacturing a car requires the assembly of thousands of physically pieces in a precise three-dimensional structure. The design process needs to analyse all the forces, internal and external, the car has to cope with, the flow of various fluids, electricity, changing conditions of temperature and humidity etc etc etc If a user suddenly wanted an extra window or a periscope or larger rims half-way through the process then it's not going to be possible. With software development changes like this to an application should be easy.
I really beg to differ there - you see the design that goes into a car and you'd understand that software is pathetically simplistic in comparison. There's a reason a new car takes years from inception to delivery, and why my car doesn't have a USB media, or Android or iPhone interaction - when it was designed, these components were too new for inclusion in car specs. Your argument that software is always new, while it has some merit in that our industry does too much re-engineering of stuff that should be stable, doesn't compare to car designs that have to utilize new stuff too.
Still, it doesn't take away from the fact that cars are designed well, and software is hacked together on a sloppy basis. No matter what unit tests or "best practices" or methodology you use, the comparison is still that software is cobbled together.
Now software used to be well designed, (and I don't mean where that means a huge requirements specification that can never be fulfilled), but designed as software. When I started out we were taught to write software by first laying out on paper how it would work and how it would interact with all of its components. Nobody does that today, and its probably why the software of yesteryear are still running your banks systems compared to how Microsoft cannot produce software that requires service pack after service pack, or a framework that they won't scrap and replace with something else after 2 years!
If we want our industry to be mature and well-respected, and for our software to keep running for decades, then we have to move away from the continual reinvention of the same old shit. We have to put up with moving goalposts all the time - thanks to the suppliers like Microsoft that keep on changing the OS or OS components so they can sell us new versions. We don;t help ourselves by chasing new languages and frameworks all the time too though. If we could fix this, we could start writing software that did whatever it was designed to, and didn't need replacing.
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.
It's not that agile encourages laziness from the client... it's more that agile realizes that many (most?) clients don't really know what they want up front.
I find mention of the car design up above particularly useful, as you may have a client go through a lot of trouble to explain that they want a car and work with you to design a beautiful station wagon. You produce that station wagon perfectly to spec, and the user grudgingly accepts the station wagon but is never fully satisfied with it because what he/she *really* wanted was a sports car, but the user was unable to fully realize it until you handed over the station wagon.
Now that the process is over, though, the user is stuck with the station wagon unless he/she is willing to start the process again and throw more money at it (and at least in my contrived example, they got a working car).
The underlying goal of agile is to get the user to realize he/she wanted the sports car at a point early enough in the process to either change course and make the sports car with minimal extra overhead or realize the end product is simply going to be a station wagon and live with it or cancel the project early.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
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?
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.
Errm, that's exactly what waterfall is. You have a big upfront specification phase (essentially your user manual from your example) followed by a design phase followed by development etc.
The problem is that users truly don't know exactly what they need, and even if they did, those requirements will change over time in response to the market changing. So by the time that you've spent months writing a spec, 50% of what you specified will not be what is actually required. Worse you've now spent months writing out of date documentation and have NO software to show for it and opportunity to start getting back any of your investment - paper specifications are not a business asset. Then you spend still more months writing code against that spec, meanwhile another 50% of the remaining correct spec is now out of date meaning that by the end of development you've actually only delivered 25% of what the customer really wants and 75% of what you've developed is wrong. And you've still not got any software into production to be returning on the investment you've made.
That's why people looked at other ways of developing software and why agile gained traction.
It's not a perfect approach, but IMHO it's the least bad approach that we've tried so far.
The problem is that even the client can't be sure what they want. I finished a roughly 2 year project last year and when you're working on a project of that scale 2 years is long enough that the client's business requirements wont necessarily be the same at the start of the project as when they finish. You can't blame the client for that, and it's something you have to deal with.
The clients have to deal with changing markets, they have to respond to competition, and so forth - that's just a reality of business for them. In the example of this 2 year project I'm talking about, tablets weren't even really much of a consideration when the client was first building their requirements but support for them became a necessity 18 months into the project - these are the sorts of things you just cannot predict ahead of time.
That's a flawed analogy. The compiler does an excellent job of building the software many times a day given very detailed specs: the code. The code is the design. The "construction" phase is completely automated. The correct analogy is that the architect can't produce a design that will satisfy the customer if the customer doesn't provide all the requirements. Yep, that's true. In construction, the architect cost is a small fraction of the cost of the total project. If the customer changes their mind 100 times, as long as they do it before construction starts, it doesn't make much difference. You can take the design, cost it, and build it reasonably accurately and to spec and cost. If they change their mind after that, well that's like changing your mind after you press Build in your IDE. In software development, the design is the main cost. Don't tell me that architects and designers in the constructions industry don't have the same problems and cost overruns that software developers have - my sister is a designer, so I know. If we could automate construction of a building to the extent we've done with software, that industry would have the same problems.
"I have never let my schooling interfere with my education." - Mark Twain
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?
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.