Slashdot Mirror
New Analyst Report Calls Agile a Scam, Says It's An Easy Out For Lazy Devs
msmoriarty writes "We recently got a copy of a new Voke analyst report on Agile, and the firm basically blasts the movement from top to bottom. Some highlights: 'The Agile movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Agile.' 'Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance. ... Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.' So did the analysts just talk to the wrong 200 people?"
Beware of hucksters selling a system that will give you everything you dream of, and fast and cheap to boot.
And be even more wary of those who promise a way to outsource everything on the cheap without taking any hit on quality.
There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick.
SJW: Someone who has run out of real oppression, and has to fake it.
While Agile shouldn't replace good practice of project management, when working on smaller scale issues, products, features, in my (humble yet practical) experience Agile has proven very rewarding and efficient. But I can only imagine it mixed with more traditional project management tools/practices.
I'd never heard of Voke before today. What is this company? What credentials do their analysts have, that we should care what they say? (I don't mean academic credentials, I mean proven real-world success.) What are they trying to sell?
There needs to be more skepticism about statements coming from random "consultants", think tanks, etc.
It was forced on us by "hip and trendy" managers who saw it as a way to get more frequent status reports (i.e. pretty much daily) and try to get more work out of people (it's agile! Crunch time is every sprint!).
Not that I hate working that way, I like the morning meetings when they're conducted correctly, but it's not a panacea. Neither is it really anything new AFAICT, it's just waterfall with shorter iterations.
All the planning in the world can not assist with political changes in a business. Requirements are a moving target and agile is the best method formal framework available for integrating those new requirements into the workflow.
Traditional waterfall does not provide such flexibility and having to repeat analyses due to changes is both time consuming and a waste of financial resources.
I delivered some of the largest systems available using this framework and it works well. It all depends on the people involved.
Shouldn't it be the wrong 196 people?
If devs and other people that use Agile don't documents their work for future use and maintenance I think it's clear that its a failure right at the start...Anyone with a brain cell will know that.
The poll results correlate well with my experiences. I've still not seen a well-functioning agile implementation that has been working for more than three to five years. Once maintenance is required for the undocumented code, and the developers who worked on it have left, the problems with agile start snowballing.
in any field: the early adopter are intelligent, motivated people who know what they're doing and understand how the new method is supposed to work. Later adopters are mediocre hacks who don't perform well to start with, and are probably looking for a way to obfuscate their lack of skill and motivation, or, at best, don't get how the new method is supposed to work.
The Cloud - because you don't care if your apps and data are up in the air.
Is a way for managers to tell other managers that the features that no one really cares about will be delivered by a date that no one believes in.
Fugue for Aaron Swartz
Management likes to pretend that they have a plan, because it's their raison d'etre, but in reality everybody just makes it up as they go along, complete with supporting statistics. If you have no documentation, at least it isn't misleading. Agile doesn't prevent you from writing documentation though, so if you can and do write good documentation, that's not an advantage of the methodology, it's you. Certification is a way of selecting for a willingness to do what's necessary. It doesn't prove anything else.
By saying, you need experienced developers in charge to prevent the architecture from going to hell, or from changes being introduced just to close a bug without addressing the underlying issue, or introducing more issues than they fix, or thrashing between competing ideas of how the code should be implemented etc.
Yes, but if you had those guys in charge then you'd probably get good results with any methodology.
IMO agile methodologies can work phenomenally well if you have a development team where everyone is technically solid and works well with others. Take either of those factors away and it is a recipe for chaos; with an "average" development team you're probably better off with something more structured.
In my experience, agile is not about lazy developers not wanting to do the boring work, it's about the business owners and project managers wanting to force unrealistic deadlines on projects such that there is no time for those tasks because of the tight deadlines and quick release cycles. It is rare that they allow the principle that you deliver what you can by the release date, but rather they want everything they asked for and the devs need to make it happen.
Sorry. I'm just getting up to speed on "The Cloud", and Web 3.0. I haven't had time to to and understand the latest development buzzwords.
Am I supposed to know what "Agile" is before I read an article rubbishing it, or can I just skip over the concept entirely now?
May the Maths Be with you!
http://www.xtranormal.com/watch/12410618/its-agile
It's not far off - as always, it's about the implementation of the idea and not the idea itself.
Agile is just a structure. Like anything else, it's only going to be as good as the people you put in place to execute it. A properly constituted agile team will put documentation (of designs, code, deployment, whatever) up as stories/tasks that need to be accomplished right alongside working features. Documentation is an end-product just as surely as working code and unit tests are.
If the team doesn't identify those tasks and sign up for them, you hired the wrong people. Reform your recruiting process before you blame a process that delivers a working solution at the end of every sprint. And if your so-called Agile doesn't pretty much do that, then you really are being scammed.
cheers...ank
(I've been a developer for 26 years; some form of Agile has covered the most productive and enjoyable parts of my careeer)
Still hoping for Gentle Treatment...
The goal of development is to produce and deliver working software that aligns with the business objectives in a cost effective manner.
Agile is an attempt to achieve these goals and was conceived as a response to the failings percieved in waterfall. This is achieved by ensuring that, on a frequent basis, developments goals are focusing on businesses needs. Now this isn't to say that you can't screw up with agile. You can consistently deliver the wrong product or fail your iterations. But the business now knows it after a few weeks and can adjust. This compares with failing at the end of a 12 month Dev cycle. Both fail but it costs a lot less to fail with agile.
As for documentation, agile does not necessarily preclude documentation. Instead it says if it doesn't provide a net positive value don't do it.
I'm the first to agree that Agile doesn't work for every company or every situation. However, if done correctly, it's a very useful process and I've personally seen it succeed. Most people ignore some of the rules and that's where they get into problems. I've seen craziness like project owners also be team leads or have direct hire/fire power. The second someone has to worry about their job, idiocy is not pointed out as it should be. Agile lets you change course, but it's not meant to make things 2000% faster to develop. Any failure of agile or the other extreme, waterfall, is always because someone didn't follow the rules and didn't implement the process correctly. I've never seen waterfall work correctly because it requires a lot more planning up front and everyone wants to change course in the middle of the process.
Business people don't want process. They want speed. That has to change. No one cares about quality or bugs until customers are complaining and sales are lost. Business people need to learn patience. Developers need to learn to stand up for process. I used to doubt it myself until I worked at a company with a functioning process. Today, I'm working for a company with no process again and it's a nightmare.
The best thing about agile is that you have clear deadlines and actually feel like you're making progress during the programming process. If done right, it can be a real morale booster.
MidnightBSD: The BSD for Everyone
I like the morning meetings, but I have found the concept of a sprint to have killed off most of the design and planning phase, especially as a group when needed. Most of the projects I work on should have all the developers/engineers/scientists locked in a room together for two months before a single line of code is written. We should have a project manager with better than entry level knowledge in all fields and as a bonus based on recent methods should have tests for every component written before and/or after implementation.
I think extreme programming combined with project management and morning scrums would be much more suitable than Agile which tends to make me see most projects get to the 90% mark muh faster, but fails drastically at the end since the lack of proper planning made integration of components extremely impractical. I still like it best when 1-2 guys spend some time to build the base product and then a team is assembled to evolve it... It avoids too many cooks.
The survey doesn't discredit Agile. What it does is show that there is wide misunderstanding of Agile, including by those who claim to practice it. I've worked in such a shop, where Waterfall was the methodology, but it was presented as Agile. I've also seen Agile work beautifully, and I've personally implemented it successfully.
What Agile really does is take into account the fact that it's not possible to fully anticipate and visualize all necessary features before a project begins. This is no different from any other physical product development, say, designing a new gadget. Lots of planning can and should be done up front, but once a prototype is complete, it will become evident that changes need to be made. Waterfall assumes that the product can be well understood from the beginning, like building a building. If you are building software that is nothing but data entry screens, maybe Waterfall can work. But for anything novel, it falls far short.
The thing smells of trolling. I'm happy for people to 'call BS' on some of the garbage people say (by way of promoting) Agile practices, but honestly, who thinks 200 people is a wide enough sample range to denounce an entire methodlogy/ideology? Reads like a cheap shot.
This whole concept of Agile was dreamt up as a last gasp response to the offshoring of development work to inexpensive developers in India. Nothing more.
Insight into much, Influence over nothing !
I would agree there are teams who use the Agile guise to create lazy, slapped together, products with very little forethought into the lifespan of the product. However, I would also like to point out there are plenty of teams who take a very long time to put together the same garbage software with traditional methods.
My teams work every day using an Agile methodology and I would actually argue the opposite. We still do a heavy amount of "global" planning at the beginning of each product, assemble a feature outline, create a cycle map, and establish a deliverable schedule. The main difference is that it lets us adapt to real world outcomes. When we have an iteration we analyze the prototype and there are countless times where we find a feature that we spent days initially planning simply does not work in the real world; at this point we go back to the drawing board and come up with a new solution. This iterate and check methodology leads to a far superior product at the end of the day but in some cases it can drastically increase the development time of a product. The added ability of involving the client in each of these iterations to get their feedback and apply their suggestions guarantees a product which meets their needs.
I realize I might get flamed for this, but I wanted to say it anyway: I think agile is a complete waste of time. Its micro management wrapped up in a fancy, marketable term.
I've been a senior developer for about 8 years now. Never used Agile, never had a need to. Hire the right people and there is no need for agile.
Ok, my flame suit is on.
Agile was meant for producing disposable code with few people. Such as MS Access documents that tell you the amount of wood a house is going to need, or a quick and dirty C# program that reports to you on how your web-servers are doing so you don't have to spend $10,000 per server for a whatsupgold license, or....*insert "If we could do X for Z Cash that'd save me Y money" statement".
Check out this picture.
http://en.wikipedia.org/wiki/File:Agile_Software_Development_methodology.svg
Someone thought that was a GREAT way to build complex enterprise systems. Afterall, there's a lot of movement in there, and execs with high blood pressure love seeing Chinese fire drills.
The end result is burnt out developers produce a large amount of bug ridden code which gets stacked ontop of each other in a process known as fudgepacking. A Fudgepacker is someone who builds the integration layer between the pieces of fudgey goodness which usually results in Enterprise systems with operating procedures which state "If the software gives an error, that is normal, click OK", and because management pushed it, even though the numbers LOOK wrong they are actually right which leads the entire org off a cliff. After-all, no developer knew what numbers should look correct.
If caught just before going over the cliff, two things happen. First, the lemmings argue about who's got to jump off the cliff first. Second, after the appropriate blood sacrifice upon the alter, management asks to get it fixed. Problem; the fudgepack..er..integration specialist costs $250k/year and jim says it's jacks code, so they blame jack and jack is tasked with fixing it. Well....
Cost inevitably gets out of hand in such a world which leads to outsourcing as a "risk" instead of looking for an actual solution because choosing the wrong solution makes it look like you're doing work to investors and the investors know, while it's likely you'll fail, if you do, and you look like you tried hard, some other sucker may buy your work thinking it just needs a tweak.
Everyone who does software development just wants to build indisposable code; systems that are rock solid and work well for decades. This requires a lot of work, planning and a lot of research by the business to build a [i]design document[/i].
If you have a group of talented developers, all they really need to do is programming, motherfucker. (It helps if you read it in Samuel L. Jackson's voice.)
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
*Anything* that becomes the most popular 'brand' will become distorted to the point it's hard to say precisely how meaningful the application of the name in a given circumstance is. Agile and Cloud are the two terms in the computing industry the most afflicted by this phenomenon.
In fact, I would say an organization getting very picky about using every little piece of 'Agile' terminology is more likely than not in a scenario where they really aren't doing 'Agile'. Many just rename their 'product requirements' to 'user stories', 'milestones' to 'sprints', and 'status meetings' to 'scrum' without actually changing anything about the way they do things other than renaming (well, and putting the exact same project management data they had before into new software tools that advertise 'Agile').
It's just like how anything that has network connectivity now is advertised as 'cloud enabled', without regard for anything but the ability to transmit and receive IP as a qualifiaction for 'cloud'.
XML is like violence. If it doesn't solve the problem, use more.
Anti-agile services.
Some drink at the fountain of knowledge. Others just gargle.
We have to practice planning and create documentation like everyone else, we just do it on rapid iterations. Agile done right will force discipline on developers and they will hold each other accountable for deliverables.
In our company there's really no alternative to agile, because our customers never know what they want. We've tried various "waterfall" methods over and over, with the same results each time--the initial requirements are vague and/or poorly understood, leading to a lot of wasteful development and missed expectations that cause the project to be late, sometimes cancelled, or if it ships it doesn't work the way the customer wants it to.
I've been using agile, mostly based on scrum for 4 or 5 years now and it works. If documentation is listed as important put it as a task on the backlog and board remember prioritization is the business owners responsibility and their responsible for making sure we work on the tasks that will generate the most customer value.
CCP(EVE Online) uses agile development. I guess they're not successful.
From the TFA:
* Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.
- I'd like to see the number for success in waterfall.
* Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
- How is 40% overwhelming? I though overwhelming meant much larger than a simple majority. What about the other 60%?
* We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
- Having not met them, I can't vouch for the Agile leaders. However, we're using their product, not their personality.
* Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.
- Sure, it's another developer rebellion... against bad practices. Agile does not mean you get to avoid the necessary tasks like documentation. And who doesn't want to make money? If that's what they do fulltime and it's valuable they should be able to earn a living. That's the pot calling the kettle black with them pushing their $150 report.
I'm not an agile fan boy but it's a better alternative than A) bad managers thinking they're managing a project correctly or B) planning a massive project and having it shift underneath you.
This just sounds like a smear to get attention.
Just because you're fit doesn't mean you can tear up the parkour course.
If you've done agile right the code is the documentation, and it reads like documentation.
Agile is not developer centric, it's user centric. If what you are doing is developer centric, it's not agile.
The toughest thing in Agile is getting a good person in the user role. That's why it works great for consultancies where the user pays for the privilege of guiding their project every day, and not so much for the enterprise where nobody wants the responsibility. It is a better career move to wait and throw bombs at a failed project then to get involved and make decisions everyday.
It took a real world war to end the airplane's patent wars. - Fâché Rouge -
First off, I'll say that I have little to no direct experience working in this system, as I am not a developer. But as has been pointed out to me by many Agile-experienced managers and developers, what I have done -- worked at monthly, weekly, and daily newspapers and news sites -- is very similar in structure. That is, we have daily meetings about what we're working on and where that is, the editorial goals, checking in on longer-form projects, and then going off and working our asses off.
Of course any snake-oil consultant can come in, propose a "just-add-water" buzzworld-compliant solution, and screw up any endeavor. See also: metaphors about having only hammers.
But I think the key is that at least in journalism, we had an existing superstructure and larger mission, and regular content that we delivered, so that kept us on track and gave us regular learning feedback. Think of it as daily iteration based on user research.
Do software/hardware projects have that sort of thing? Is the superstructure in place, and does Agile fit into that, rather than imposing Agile because... well, it's Agile?
agile can be summarized as "just do it". it works well,in my experience, at cranking out code and a semi usable product. after a few years of bolting on enhancements you may wish you spent more time designing. however, it's easy to design something that don't work. at least with agile you get something working fast. as fast as the web changes, we really need fast solutions to current problems.
Agile does work, and it works well provided that you have cooperative managers and good developers (or at least good lead developers).
Agile fails when management dictates what the developers do, management doesn't trust the developers, the developers are clueless or the developers are lazy.
Clueless, ignorant, lazy people cause projects to fail no matter what methodology they follow.
You don't need to spend money to "do Agile." If you want the official training, you can pay for it. There has recently been a break-away movement by the originators of Agile/Scrum to go back to basics and to provide much lower cost certification.
I was trained in Scum/Agile/Design for Lean Six Sigma to the green belt level and have over 4 years experience. I went to a new job and initiated Scum in my new team. I gave a presentation to all of the engineering staff, got their buy-in and my software team started working in sprints. I was the scrum master for the first few cycles and now we're taking it in turns to get experience.
I've tried to start with the basics and to avoid it turning into a "cargo cult." It's working very well. The PHBs love it because they know what's going on at all times without many frequent boring meetings and they get a demo once a fortnight of the new "value" that we've created in line with our sprint goals.
The developers like it because the work is in bite-size chunks, management can see progress (and so we get credit and praise), interruptions and emergent work are monitored (the effect on progress can be seen) and we are delivering working incremental pieces of the product and integrating and testing them early.
Progress and quality have never been so good at this place, and the developers are enjoying being seen to be delivering and having things that work.
The engineering director is so impressed that he wants the other teams to adopt Agile/Scrum too. I'm getting moved to another team temporarily to get them started on scum.
I also use Test Driven Development to write my code and have implemented a test stub mechanism of my own. My colleagues have seen how successful it is and are starting to learn how to do it as well.
Stick Men
Yes, no methodology is going to be a magic bullet that turns a loser team into a superstar team. Agile was never intended to do so.
What agile processes attempt to address is the transient nature of requirements. Large, monolithic processes do not respond well in cases where the client doesn't know exactly what they want up front.
The reality is that clients often times add things during the process, and just as often as not, they do not realize that what they said they wanted wasn't really what they wanted. Providing continuous feedback and re-adjustment helps to mitigate this problem.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
I work in a Agile shop, but lucky for me in DevOps. All the SCRUMs, Code Sprints, developer trying to play QA is just a way to be cheap and to the "Suits" with OCD be controlling. The last big product rollout they got all their constants to come in and create code sprints and try to whip everyone up. A week in all the developers were ticked off and burnt and told the "suits" can hit the targets with all time wasted on writing test cases and not code. So the drop the Agile crap and got the rollout done. Think the "suits" would learn, no development is back to Agile suckage. Where I'm at Agile is all about control and trying to make 60 seconds of every minute work.
Anyone who has been forced to work with certified Project Management Professional project managers will understand why organizations have looked at agile. PMP is the worse of waterfall with a bunch of useless buzzwords. Agile breaks that cycle but does introduce some other problems.
The biggest problem with developing software is that any non-trivial system takes time to deliver regardless of the methodology, You can take time to properly spec out and design a bridge over a river because it'll be good for 50 years. But the world of software changes so fast that any system is obsolescent by the time it's done, and if you spend a few months specing/designing it's time for a redesign before you even start writing the code.
The developers of EVE online adore agile and have noted a dramatic uptick in productivity, reliability, and content delivery since adopting it... and even went so far as to do a presentation about the whole thing. So I guess it CAN work... it just doesn't necessarily work by default
I have yet to see a development group that says they are doing some form of agile development that actually implements the claimed methodology. What I have seen is full implementation of "agilr-speak" where agile terminology is applied to what is esentially just yet another death march development effort. Re-writes become refactorings and milestones become sprints but only the terminology changes. I don't see this as something the developers do so much as something management does since it's a way to supposedly get all three of "good, fast, cheap" without actually defining a product goal, creating a realistic project schedule and then staffing the project with enough people to accomplish the effort.
Although I have yet to actually see such a development effort, my guess is that agile really works when correctly implemented. Several other commenters say they have been part of successful agile development efforts. I've just never actually seen it done.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
I am a game developer who has worked for years doing Agile and non-Agile projects. From my experience, when done correctly Agile projects go much smoother and produce a higher quality product. They may not have the amount of features, but the overall product is better, the team moral is better, and the client is usually happier. The problem with traditional development is that in many cases scope, timeline, and resources are fixed. This is a recipe for disaster because based on the cone of uncertainty (http://en.wikipedia.org/wiki/Cone_of_Uncertainty), the original estimate could be off by as much as 100% and trying to cram the work into an unrealistic schedule forces developers to cut corners and not create a solid framework. This in turn creates more bugs and the project tends to take longer than if quality (rather than quantity) was the focus from the beginning. I have seen well functioning Agile teams. In fact, the art director in my last Agile team said that that team was the most efficient he had ever been on (he had worked with something like 27 other non-Agile teams prior). I think many people have been on poorly implemented Agile teams and therefore get a bad impression of Agile. Some of these poor implementations include very long daily stand-ups (they shouldn't take more than 15 min), zero documentation (you should do as much documentation as is needed), trying to force developers to complete every task in a sprint (team velocity should be calculated not dictated), poor negotiation of scope by management (scope should be adjusted based on the product burn-down chart), and forced overtime for more than two weeks (The average person will be less productive working long hours after two weeks than they would at a continuous 40 hours per week. The number 40 is not arbitrary. Based on multiple studies, it is produces the highest productivity for the average person. Management doesn't usually take this into account because it's hard for them to track the time it takes to fix the bugs that long hours tend to generate). If you just look at the amount of features that get completed, then yes traditional will probably look better in a study, but these studies don't take into account the time it takes to train new developers as a result of others that have quit because of poor process and they don't take into account the true quality of the product.
While initially, Agile may actually deliver a working prototype faster if you are are lucky, this prototype will be all you get, because the system will be unmaintainable and non-scalable. It will also be unreliable and insecure. If that fits your needs, fine. If not, there is no replacement for a classical approach and, more important, for competent, motivated and experienced engineers to architect, design and implement it. Unfortunately, these competent engineers are quite scarce and quite expensive. But they cannot be replaced under any circumstances. Business people often try to compensate with processes, but while that may work in the area of business (I doubt it), it is unsuitable to any technological area requiring genuine understanding and skills.
My take is that basically Agile in practice is people trying to make do with incompetent developers instead of telling management that the people available do not cut it and that competing for talent and experience (which drives cost up massively) is the only way that will cut it. Somehow business people still fail to see the blatantly obvious: Good engineers are essential to any technological undertaking and these engineers are far more important than anybody from the business side.
The founders of the agile movement seem pretty blameless though. They already knew this. After all, "People over processes" (the "including agile processes is implied") is at the top of their list. And good people will plan, document, structure well, regardless of the processes they are working with. Bad people will always be bad people, regardless of processes, management, border conditions, etc.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
TFA greeted me with "Close this Advertisement", and so I did: I closed the tab.
I have 25 years of development experience. agree with the headline completely; Agile is a "methodology" that pampers developers. It basically codifies chaos. I've been pretty happy with the classic Waterfall (with 4-to-10-month release cycles).
At the same, I have rarely seen planning and design documentation that is really useful for maintenance and tech transfer. Almost without fail, they are process-induced write-only documents that lose their relevance a few days into the project. At best, they are internal sales brochures that create an impression on the feasibility of the project even if ultimately a completely different design is implemented. Unfortunately, there never seems to be motivation to document the actual design after the release for maintenance.
What intrigues me is the pilot-copilot model proposed by the Mythical Man Month: a 10-member core team with one coder (the pilot) and a spare coder (the copilot) in case the pilot dies or quits plus eight bureaucrats to make it possible for the pilot to concentrate on his job. I believe that model would work really well, but I haven't ever seen it in practice. Does anybody else have experiences with it?
Since we did that officially at one place we worked.(Agile/Scrum to be specific) So I've ranted before how I think the second dogma is just wrong. (You don't need to encourage developers to not document, they'll do that quite happily.) There are other issues however. So for one we had an issue where our "Scrum Master" basically just took over the group and started having us report to him, giving us tasks, etc. We did complain to management but they did the whole "You're doing Agile, you manage yourselves, work it out for yourselves." Then of course there's this whole agile thing that you have to produce software every day that shows visible changes. The problem that those of us in dev have with that are 2 fold. For one depending on what you're working on it might be weeks before you can shows anything that works at all. Also some bug fixes arn't really visible. (For example I fixed a race condition that in production only happened once every 6 months. It took QA and myself basically a week to write up a "test" to get this accepted since Agile is "Visiblity-Crazy") Actually more recently i was doing agile which would have been nice since the product manager could tell me how it's supposed to work. The problem? He didn't actually know how the product is supposed to work (I mean basic functionality) so I'd work on it and put some functionality and then we'd find out oh wait, nobody asked for that and nobody wanted it.(Which was annoying since I kind of mentioned I didn't think it'd be that useful.) Of course the big bad thing about agile is since you work daily with the product manager(who is simply my manager in this case) it ends up just being an excuse to micromanage me. (So that's twice I ended up getting micromanaged under Agile.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
This just in! Agile works great for some people on some projects, and doesn't for other people on other projects! News at 11!
Sunwalker Dezco for Warchief in 2016
Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.
Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now", so yes, you will refactor, but that refactoring is an ongoing part of the process that is informed by 2 things, continuous integration and user acceptance testing.
IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process. If you actually PAY ATTENTION to the things that Agile is telling you to do (personally I find XP type process to be the most effective) then you can make it work. Everyone needs to understand the value of the parts, and as any Agile expert will tell you ALL the pieces are important. It is not at all interesting news for someone to tell me that if you fuck up and ignore half the pieces of the process that the other half don't magically just work.
No one development methodology is a panacea of course, but this report seems to be meaningless criticism based on not actually understanding how and why to use Agile.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Extreme Programming is in itself a form of Agile development (cf wikipedia). SCRUM isn't the only thing people mean when they say Agile.
In reading the comments, it's clear that many people don't know the roots of agile software development. In short, agile (note the lower case) development is basically a set of of principles laid out by a group of very talented developers in the late nineties in their agile manifesto:
http://agilemanifesto.org/
Note that the manifesto makes no mention of Extreme Programming, Scrum, or any of the other capital-A Agile methods. Instead, it focuses on observations about what made their software projects successful. Itpecifically doesn't prescribe any specific methodology, but rather encourages communication, iteration, and excellence in design and engineering. The last two points come from this section of the manifesto:
"Continuous attention to technical excellence
and good design enhances agility."
The manifesto very much allows for, and even encourages, design. It also assumes that the practitioners are already experienced developers who know how do design software and know how much design is needed before coding. Unfortunately, the most Agile methods traded experience for certified training and the 'technical excellence' portion was lost.
I've worked with many talented teams and have seen agile work time and again. Of course, all of those projects did have design, documentation, and tests. But, all those artifacts were developed using the same principles in the manifesto.
-Chris
.. that I am not even going to RTFA. *Developer* rebellion? Not a SINGLE dev I have ever met asked for Agile., it was is the PHBs who wanted to micromanage yet push more responsibility on the devs that adopted this. At our company we pushed back to get a formal design phase tacked on prior to the mandated sprint schedule so Marketing et al would have to commit to a feature set and product UI flow, otherwise all the onus was on us to read their minds.
As a dev, Agile makes life harder since we always feel pressure to give story point estimates that are under 5 days, as Agile says everything should be incremental work which is BS when you must maintain legacy code that has tight coupling and poor documentation, or write a whole new product that hasn't been given enough up-front design work to identify all components.
Seriously the entire concept that this is "lazy devs" is just brilliant flamebait.
"Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance"
Agile can't turn shitty developers into good developers.
Nowhere in anything I've read or seen about agile have I seen it said that planning and documentation wasn't necessary.
Then you stay in design until they DO know what they want.
This is news?
As a dev/dev lead/project manager over the past twenty years, I have found the sweet spot to be small-incremental deliveries instead of big-bang at the end of the project lifecycle to be a good thing.
This is the part of Agile that works, break down a big thing into smaller things, better understand those smaller things, deliver them, and work on the next work, keeping an eye on things with the client to ensure todays's need is the same as was anticipated, or if a small change in direction and focus is needed along the way to keep the project relevant.
The rest of the Agile mantra, kanban, pair-programming, xp, stand-ups, all the endless meetings, is complete and utter bollocks by those who basically want to sell their books and consulting services as "agile experts" into organisations who are dumb enough to pay for it.
The more you formalise things, the more process you add, the more likely you are to spend time on the process, rather then the end deliverable.
I am sure the client appreciates you shitcan, sorry, kanban board, but they would appreciate the time spent working with them on the end deliverable more.
Agile is not a product. It is a mindset. Each team needs to workout what that means for them. I have been in teams for two companies that used Agile methods heavily and it has worked out very well for business units (predictable deliveries), developers (predictable work hours) and customers (higher quality releases).
I am positive Agile is not a silver bullet for every project. Software engineering is still a hard problem to generalize.
Then you deliver it after one long year and it's not what they expected. Agile is just about that, frustration comes early, when it's manageable.
There is no magical developmental panacea. That being said, Agile is pretty good - for some things. It's great when you aren't sure where you are heading, when you're doing a prototype run, or when you are just building data on how interested in something people are. It's also useful for when you just need to build a small product.
Agile isn't some amazing process which should replace everything. There is no one-size-fits-all development process. Everything has it's place, and Agile's place is in prototypes, rapid development, and exploratory designs.
Indeed. People who are selling agile as the solution to your incompetent team are ruining agile's reputation for the rest of us.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I dream of such customers, usually when one is screaming "I NEEDED THAT YESTERDAY".
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Either slog away at your backbone functionality as priority one with lessons learned being used to tweak it, or recognise that you're developing a prototype and use it to find out what the final product should really look like. In the latter case work on the assumption that version 1 will be hacked considerably and use developer-nouse to make it easy to adapt.
There's nothing wrong with either of these methods but 'getting to the finish' and finding you need to make vital changes, or continuously releasing patches (especially if panic-driven) is bad.
'Right first time' is the ideal programming method -- I use it all the time in my dreams. In my nightmares I'm forced to be fire-fighting.
That is nice in theory, but I have found all to often in practice, when people see what they ask for, they realize that they didn't really want that. When you have a multi-year process, requirements change (heck I've seen it in multi-week!). Even ignoring the issues of human nature which induce this type of event, there are so many external forces that can drive a change that being able to re-evaluate is key.
My take on agile, and the "developer rebellion" is that developers got fed up with 18 different "Number 1" priorities, and wanted to force management to actually do their job and prioritize.
Ok, I give up, why you?
The whole issue is that agile isn't. Isn't what? AGILE! That word causes customers/managers to think flexible meaning "I don't have to plan anymore, I can get what I want, when I want it".
In reality Agile is extremely rigid. There is nothing in the method to deal with issues that crop up NOW and have to be fixed YESTERDAY. Instead, the manager/customer now has to plan ahead for what he wants, get it approved for inclusion in a sprint and then wait for that sprint to be finished. That could take DAYS if not weeks!
Not that a sprint itself has to take that long but before YOUR new wish is included in the next sprint might mean you have to wait your turn.
Agile needs a lot of discipline and commitment across the entire production line, from customers to managers to developers. But if you got discipline and commitment, ANY methodology will work. And if you don't. None will.
Dysfunctional companies are dysfunctional regardless of the label they put on their method for screwing up.
Agile is particularly bad since it doesn't enforce any fixes. It is often introduced as the solution itself, go Agile and all the unrealistic planning and louse development and under staffing will just fix itself.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
100% of the time I've come into a project, and said "where is the design sheet", or "where can I see documentation that someone has made that decision", or the kicker "what are the deliverables that I will get from you to start on this", the reply is "we're doing it agile", as the excuse they don't exist.
Which means, the thought process, the design, understanding and brain mapping onto the problem space _HAS NOT TAKEN PLACE_.
Read it again, as many times as it takes for it to sink in.
That is the true agile scam. HOWEVER. "todo, doing, done" is a brilliant way to track tasks, and task management is the single most important thing you need to manage a project, after _ACTUALLY UNDERSTAND WHAT THE FUCK YOU HAVE TO DO_ (AUWTFYHTD), I'll be selling seats to a A8 conf this fall! $400 and an open bar, petition your project manager TODAY!
Comment removed based on user account deletion
I hate seeing posts like this, Agile is not for lazy developers, in fact it's for developers who want to do what there name suggests, develop!. To the group who ran this study I would like to see the actual line out of the Agile guide that states "You can not plan", then show me "You can not write documentation". Some Agile developers will use Agile to skip doing documentation and planning but that's not the point of Agile. Agile is for the developer who can think on his feet and dance around in the ring, it's not for the developer who needs to sit down and draw out 50 pages of requirement before a key gets pressed.
There are pro's and con's to both development methods. Some people can work better in an Agile environment and some can't, calling Agile out as a lazy development method just means you don't understand it, you just wanted to pick up the name because it sounds cool and cutting edge. Agile developers in fact get much more work down but at the cost of harder work. At the end of an Agile project you should end up with the same results, just quicker and in most cases a better final product.
No where does Agile proclaim itself as the No Documentation king or the No Requirement king, it's lazy developers and lazy survey holders who give it that name, and in this case it's clear the surveyors had no idea what they were talking about.
They learn what they really want when they see the working system that does want the first asked for. If you make them sit in meeting rooms writing power points they will never learn what they really want.
Really? would it kill you to include a half sentence to give us an idea what your talking about?
Is it requires more discipline from people on the bottom (developers). But if they had discipline they would have been writing up detail plans and complete design documents up front, and delivering on time. The teams that are falling apart under waterfall are attracting the eye of managers that wish to experiment with Agile, but these same teams are usually the worse candidate for switching to Agile.
“Common sense is not so common.” — Voltaire
Agile or the CEO standing in front of 1/10 of the "team" asking "is it done?" "do you have it under control?". I was that 1/10 person before agile came. Now I can relax.
I'm a big fan of Agile, just not the flavor my company uses. - You can't plan R&D - You can't schedule the next big discovery - You can't hold one person accountable to the estamtes of another person - A developer should be accountable for delivering stories and quality, not tasks
Agile is a software development methodology equivalent to declaring every mile of a marathon a "sprint", and instructing runners to attack each sprint with a pace typical of a 100 yard dash.
Agile keeps programmers busy and gives them billable time at work. But it also leads to business units not putting together a proper outline of application requirements. Clients pull shitty ideas out of there ass and hours are wasted on poorly concieved ideas.
Few people realize that the waterfall method originally had feedback loops. But people (managers) being people, they took that little bit out. Agile is very often also implemented with things people want to leave out. Like with Waterfall, it is Agile's failure, not the peoples. No wait! It's the lazy devs fault! They tricked management into applying a broken process and then took advantage of it until their jobs are outsourced. Damn those lazy devs are so clever!
sed s/Agile/Analyst
'The Analyst movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Analysts.' 'Survey participants report that developers use the guise of Analyst to avoid planning...'
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Now listen here, I've Project Managed enough projects and have extensive experience with the likes of Joomla, Hadoop in both Cowboyed and hourly code reviewed modes and Cloud Waterfalling to be able to tell you that Agile with Outsourced Multiplatform Development Methodologies will make your company more productive than it has ever been before. If you're en executive who is sick and tired of having no cred whatsoever, who feels the sting of the eyeball rolls from your firm's alabaster-pedestal engineering eggheads whenever you try to push them in new directions, and who hungers for the approval of the board, you need to hire yourself a hot personal Agile consultant right away. They're easy to find. He might tell you to do some crazy things like sell every other desktop PC, have the developers pair up, buy razor scooters for everyone, and get rid of all the chairs in the conference room, but just do as he says and the software will be filling up your 4GL Cloud 2.0 servers in no time. Do it, and nobody will even be thinking about your expense forms anymore.
There are a lot of ways that going slower can allow you to use less expensive parts to produce a result that would otherwise have cost more.
"[...] Agile, which may not be appropriate for all organizations or projects"
That's fair.
They won't know what they want until they see something delivered and then realize that what they got wasn't as useful as they thought. The shorter your iterations, the sooner you can give them something that doesn't do what they need so they can realize what they actually need. Yes, good guidance can reduce the number of iterations but not the need for iterations. Big design-set-in-stone up-front is a recipe for disaster unless you are doing something that many people have done many times before like a compiler so that you can just read up on exactly how successful projects were already done - but then you aren't really doing big design up front because those other people already did many iterations on the design before it ever got to you.
I used to develop a feature, then deploy it. Typical turnaround time from request to implementation: 1 hour. I pride myself to having the lowest defect rate of our team, and the lowest open ticket count, whilst maintaining the highest number of projects.
Now that we're "agile", that has gone up to 2 weeks, at least. In all fairness, I think defect rates per feature may have dropped - slightly. However, the impact of any given defect has severely increased, because any defect is going to be around for at least 2 weeks now, instead of an hour after it's first reported. In other words, by doing "agile" the way we do, the impact of any defect has increased by a few orders of magnitude.
Releases are much harder to do now. Instead of pushing out a release for 1 feature, we're combining a multitude of features in any given release now. Because of this, chances that things break after any given release, have increased (if there's a chance of 1% that any feature has a bug and you release 50 features at once, there's a 50/50 chance that you'll break things). In addition to increased bug rates per release and increased time to roll out the next release, it's also much harder to find a bug in code that was written weeks ago, than in code that was written an hour ago.
I think we're just calling it agile. But I don't think it is agile. I think what we're doing is the opposite of agile, in the name of agile.
..if you want cheap custom software, better don't do it at all. Software development is horribly expensive and takes a lot of commitment from the "customer" to see it through development, bug fixing, QA, some crises and so on.
Better set up some manual system (which can include Excel sheets) if you want something cheap.
Hitler did an Agile War ! Agile == Nazi. Stop this discussion right NOW !
Yours
Godwin
especially "...if you can't hold a developer for five years, then you have a morale problem that will cause pain..."
never said a truer word. even difficult legacy code can be endured if the company has no systemic negative morale factors.
cheers...ank
Still hoping for Gentle Treatment...
"just" revamped your lexicon - agile is like ten years old dude. it's the only way anyone does web services, which is where people make money these days. god you're out of touch.
Hot, Smart, Sane
Pick any two.
People misunderstanding Agile and doing it wrong is no more the fault of the methodology than a drunk driver is the fault of the car. Nothing prevents you from documenting what you do.
Because Carnegie Mellon licensing CMM and taking in buttloads of dollars in CMM certifications wasnt a scam. If you reach CMM 5, you're free of software thetans.
You don't need certification or outside training to practice Agile methods. There may be some helpful training services, but they should be about learning new ideas and figuring out how to apply them to your environment (and when not to), not reaching new levels of certification or decorating resumes.
At the end of the day, a company needs to find the process that works for its developers. No process, off the shelf or otherwise, is going to make up for mediocrity or poor morale. Some places will work well with Scrum practices, some with Kanban, others with XP, and some with traditional Waterfall.
If I had to pick a generic characteristic of a development team most likely to lead to success, it would be adaptability.
Ah, yes, well said.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Iterative software development, continuous integration, test driven development etc existed before all the Agile hoopla came around. The agile movement has simply repackaged it, added useless certifications and sold you as their "invention". Quite a few of these agile "experts" originated from the C3 software project that has miserably failed. (http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System) This is a good example of why Agile is a failure: don't count on methodologies, instead go to the basics, learn the underlying good practices (like iterative development) and apply them as tools in your toolbox as needed.
Lets suppose you're a business and you want to build a manufacturing facility that will cost you say $500k. That's a pretty substantial investment. You're telling me you're just going to hand $500k to some GC and say "hey, build me an XYZ on this plot of land" and you expect to walk away and come back in 6 months and magically have something that exactly does what you want?
No, you're going to supervise, and inspect, and you're going to work with the GC and the architect, and the people installing the machinery, and the power company, and all those other people. You simply CANNOT expect a complex project to succeed without that level of constant interaction, cross checking, making sure that when the utility entrance can't be on the west side because the power company will only put the substation on the east side that things still work out. It just doesn't happen by magic.
If you think somehow that a software project isn't EVEN MORE this way than a conventional construction project then you're monumentally misinformed about how things work and frankly you should buy OTS software because anything beyond the most trivial projects WILL fail if you approach them this way. I've been doing this stuff for 30+ years, and I say this with the utmost certainty. In fact, since I have plenty of business from sensible customers, I wouldn't even do business with someone that demonstrated your attitude. You're not worth the trouble. You're a lawsuit or at least a broken project waiting to happen.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
You meet regularly to discuss the software features for the release. Everyone complains about the meeting time.
You track progress on those software features during each meeting. The Agile head honcho complains about the progress and adjustments are made.
You regularly change the feature based on feedback and the input of the designers, users and testers who complain about the lousy interface, performance or something else in the meetings.
You know when you're finished with a feature because everyone stopped complaining about that feature.
At some point, you know you've finished all the features because everyone has stopped complaining enough to bother you, and you're ready to release.
That's it. The rest is details. Now pay me $999 for my consulting advice.
Please do not read this sig. Thank you.
As we had it introduced to us... agile is what we were already doing. Build something, let people try it out, get how they wanted it to change, rebuild to be closer to what they need, repeat.
This is what we were already doing (but with less formality) as opposed to another corporate division that took months to produce ANYTHING with the waterfall method.
The fact of the matter is, waterfall takes too long and the user is never satisfied, even if you give them EXACTLY what they asked for. The user doesn't know what they want, only what's the biggest annoyance at the moment. (This is a generalization, some users DO know exactly what they want, too many keep promising "this is the last change" dozens of times over.)
There's no sense wasting huge amounts of time on what won't be the final version. The waterfall method is sold on the idea that once something is finished, that's the end of it. Anyone in programming knows that's bs.
You WILL have iteration after iteration, the question is whether you'll have agile-style short iterations, or whether each iteration will comprise the entire waterfall process. The waterfall method is pushed by those being willfully blind to this reality. (Usually from ego, thinking they can say no, only to be overridden by the other department complaining to a VP to have you drop everything and work on the Nth rebuild of a system that already works NOW.)
I have found that almost without exception the type of person who is huge on over-managing a project is usually a Type A control freak that suffers physical pain when others are allowed to make any decision without running it by them. By far the best companies in the world give many of their employees a huge amount of freedom which allows the employees to thrive and the company to keep top notch employees. Most companies are the opposite and survive despite themselves being larded down with waste products for employees.
Agile programming all comes down to costs and benefits. If you are building a billion dollar bridge much like the last billion dollar bridge with a tight timeline then plan plan plan as the few millions spent planning will probably reduce the number of billion dollar disasters. But if you are building an innovative million dollar software project which is basically bunch of smaller projects where fixing mistakes isn't costly then it is not only inefficient to over plan it but irrational as you can't actually plan research which is what most projects largely are.
What you do is set goals and repeatedly check to see if all hands are rowing toward the goal. It is very easy to watch to see if a lazy git is rowing the other way. If so you toss him overboard and keep rowing. Not that hard really.
Personally my favorite experience on an agile group project is when other programmers do something with such style and innovation that I am green with envy. This sort of behavior brings out the competitor in most people who try to meet the newly raised bar. This is an everyone wins scenario in that even the crap programmer will be encouraged to grow. Oh sorry this is an everyone wins except for the now redundant Project lead, project manager, lead architect, project manager, producer, or whatever the paper pushing position used to be called before he was let go. I am not saying that you have no management control over a project just not a more chiefs than indians situation with layer after layer of reporting structure. You basically have one or two programmers assigned to give fairly regular status reports to someone who is monitoring(not micromanaging) the project to make sure it doesn't go off course.
I never understood the benefit of Agile or why anyone would want to go there. If your working on boring small projects which only take time and a lot of typing to complete I guess Agile works. I could see this working with shops dedicated to small scale custom projects.
For anything non-trivial you really need to invest in infustructure and design or you will end up with a patchwork of shit.
Agile seeks to exert pressure away from thinking and design rewarding instead the brainless zombie which makes shit up as they go along. It also encourages use of more modern and exotic language features to cover for the underlying system being a piece of shit.
A good development process will exert no artifical pressure detremental to the overall project lifecycle. Agile fails this test in a great number of domains.
Laziness is actually a virtue the entire point should be to reward those doing the least with least amount of effort to get the job done.
The catch is laziness must be evaluated in the context of the entire lifecycle of the system. Being lazy up front and having to work 10 times harder later as a result means you suck. Being lazy up front and having to hire more people just to support your POS when the complaints come filing in means you suck. Agile encourages people to suck in my not so particularly humble opinion.
Is Agile web scale?
Is that instead of encouraging increasing efficiency, agile encourages increasingly inflated estimates.
There are certain types of projects where it makes sense, but they are few and far between.
Personally, I dislike Agile Programming. Its sloppy. There is a place for it, such as if you need to rapidly develop an app that needs to work, but doesn't need to work well. Its programming in chaos. I prefer an ordered approach to application development.
You need a working utlity as soon as possible to analyze, detect, or whatever you want it to do? Fine, use an Agile appoach. Just accept that what you produce is going to be buggy, and probably with shoddy documentation. Sure Agile can be handled in an orderly fashion, but then it loses the flexibility that makes it worthwhile.
I prefer a slow and steady approach. Its not sexy, but I want my code done well, rather than quickly.
who prays for Satan? Who in 18 centuries has had the humanity to pray for the 1 sinner that needed it most? ~Mark Twain
You're getting +Funnies, but it's a legit part of the equation.
A thundering famous example is cargo shipping stuff from China. China, as we all know, is the poster country for Non-Expensive, and just to amuse the /. crowd, I'll use the example where a businessman lost $100,000 because his shipment of Justin Bieber dolls took too long to arrive and then they had a haircut that was no longer good.
http://www.dailymail.co.uk/tvshowbiz/article-2046881/Justin-Bieber-haircut-cost-doll-company-100-000.html
The other more harmless example is US Mail's Bulk Rate shipping.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Oh, I know this one, this was how Microsoft used to do Vaporware Marketing!
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Purchase both Agile reports in this special bundle and save!
Some people say that Agile is awesome when fully implemented, but I've never seen that done. Or met anyone that seen that done. It's kind of like Big Foot.
Just like "release early, release often" Agile can work, but it has requirements.
!st, it means that you are evolving your product, not creating something completely from scratch. both 'release early-release often' and 'agile' require that the product that you have at the start actually works, and do something useful for people, from there you can evolve your way to any destination.
Linux is developed via agile methedologies. The 'sprints' are 3 months long and nobody can say before each cycle what features are going to land in that cycle.
where Agile goes wrong is when you try to say that all development must be completed in one cycle, a cycle is when the prior development is being integrated and tested. You make sure that a long-term development project doesn't go in early, breaking other things and preventing anything from being tested until it works. Instead you don't integrate the long-term development feature until it's completed, or you break it down into steps and work introduce the steps separately.
In Linux, this gradual, cycle based development has been able to make major changes over many releases that could never be completed from idea to finish in one cycle.
the other major problem that commonly happens with Agile is that people are unwilling to say that some feature isn't ready yet and just remove it for this release, they make plans on what will be completed in this sprint and those features will be in the final result, even if they don't work right.
Agile and proper DVCS usage go hand-in-hand, if you are trying to do Agile with CVS, Perforce, SVN, or any single-master version control workflow, you are not going to be successful. You need to have the features being developed independent from each other and only combine them when they are ready, and that takes using a DVCS with the correct workflow
David Lang
This is the same sort of discussion you get with c++ vs php - the question is what is the job.
basically it should be clear to all that if you design,code,test,doc,release,stop - that is the most efficient approach. say this takes an effort size 1
the trouble is that what is released is probably not what is wanted.
under agile effectively you take a small part of the job and design,code,test,doc,release,stop let the customer loose and then repeat.
repeating this process n times for each 1/n th of the project takes more than effort size 1 as even if you never even look at any part of the code previously written, the tests you are adding and running will - and the whole point of agile is that you iterate toward the true requirement so you will be re-working.
the trouble is that what is released at the end will cost more.
please flame me for stating the obvious, but if you know what you are doing, and what is needed you should use something like waterfall and if you do not know what you are doing/is needed, use agile
Like most with experience in older SDLC (Software Development Life cycle) and newer Agile, my first thought off the headline was "What kind of idiot? What questions did they ask?". As I read on, several glaring problems with the "analysis" stood out.
(1) I see no mention of comparisons with what other methodology? It's just a focused criticism of Agile, implying that other paradigms are far better. The truth is, the percentage of successful software development projects have always been terrible. It started out with something like 90% failure rates and has very slowly improved to this day. Furthermore, the metrics to measure success are apples and oranges. For SDLC, it's that requirements are met. For Agile, it's the same repeatedly until the product is acceptable. In practice, SDLC leads to marking off a checkbox for each requirement and test. Other problems to solve or improvement ideas to make are thrown by the wayside unless they were specified or contractually obligated. No software has ever been completed without the developers thinking, "We could have done it better like ..". Agile provides that opportunity. The quality is better not only in terms of more opportunity to make it better but also in that the customer flushes out all the issues that never would have come to mind otherwise, until it was too late. In other words, an SDLC "success" is a bunch of marked off features and test results on a usually crappy first generation but barely functional piece of work. In contrast, Agile "success" is a more thoroughly fleshed out understanding of the problem and a better fitted and all-round higher quality solution for what the customers wants/needs--not just his first inclination of what he imaged of the same.
(1) They are engineering / cherry-picking to create support for their conclusions. Examples follow:
(a) "Out of over 200 survey participants, we received only four detailed comments describing success with Agile." -- oh really? Just before that, they said 28% reported success with agile. For how many did they receive smiley faces at the end of detailed comments describing success with Agile? Zero?! Geez, then it was really a total flop!!
(b) "Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile." Also from my own experience, the transition to agile was extremely hard. In fact, it's hard to get people to convert from Christianity to Islam, too (or vice-versa). That in no way addresses the effectiveness of Agile over SDLC/waterfall or anything else, as they strongly imply. It suggests that people do not like moving out of their comfort zones.. people like doing things they way they always have. It's typical human nature... and consequently, they resist and prejudices arise.
(c) Ridiculous levels of outright subjective and judgmental prejudice to the exclusion of any proper measures.. and repeated in different examples of the same, rather than just tallying up the levels of negative personal feelings toward Agile.... I have to say, this sounds very much like a survey given only to managers--it's a typical manager point of view. These are just ignorant and arrogant personal insults. This is not professional at all. Examples follow:
- Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.
- We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
- Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.
I don't know all the details of the processes that are used in every place and claimed to be 'Agile', there's all types out there and some are idiots or shysters. At least when you interact with MY process there will be some meetings with the client. The exact details of the product of that can depend on the scope and degree of definition of the project. A client that has its own processes in place and has generated formal requirements is going to be easier to deal with. One that has an itch that has to be scratched and a general basic idea of what they need will require more interaction. Either way we're going to break things down into user stories, probably supplemented by additional material where complex requirements are involved. In ALL cases the customer is going to help decide what each iteration delivers. While many people may THINK they know exactly what they want, it is a surety that some details change, some things haven't been considered, and possibilities for improvements, simplifications, etc will come to light during the process.
I mean, I've put software into space, on mission critical safety of flight level equipment. Even when working with Martin, Boeing, NASA, etc where they have comprehensive SDDs and SRDs written in highly formal language things are never 100% perfectly sorted out. You can have a 1000 page spec that goes into vast detail and will be translated into 6k lines of code, and even then there is ambiguity and need for interaction with the client. There's simply no such thing as cut and dried, ever.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
+1
Agile as Written - Handed down from the ivory tower of all good development practices where the developers make the final agreement as to what will be accomplished during the sprint, where the last task in the sprint gets finished in the final minutes of the sprint
Agile as "Implemented" - Where the backlog is never frozen, where the backlog is either half full and the developers sit around for the rest of the sprint or is overfilled and items get spilled to the top of the next backlog, where priorities are usurped on a daily (if not hourly) time period.
Worked in a "Dating Model" where developers were tasked to individual project managers, also worked in the "Agile" where anybody could jump in and work any "task", also worked in the "Waterfall" model. I may be old fashioned in that once I start a project I like to finish or get to a reasonable stopping place before I switch gears.
The way I was taught is old school but has always served me much better that all these fancy new approaches...which are actually cherry picked and corrupted versions of parts of the old school...
1. Walk in their shoes. How can you hope to provide a solution for their needs unless you really understand their needs...hint, their needs are usually only part of what they tell you.
2. Know where they are going. You have to understand the direction the organization wants to go, because you have to build into your solution the flexibility to get there.
3.Know your self. Don't promise what you can't deliver. Ten years ago, someone might have said having a "Siri" interface is what they want. Some things are not timeline and budget feasible.
4.Live up to your title. Being an "Analyst" does not mean document what they are doing and automate it. Understand what they are doing and why (see #1) but then go the extra step and recognize ways to improve the business process, eliminate unnecessary steps, redirect resources to more productive goals.
5.Analysts are developers and developers are analysts. Good people can do both jobs and can do them at the same time. Monkeys are for writing novels. Every question you have about what needs to be done should be accompanied by "why" it needs to be done.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
My own experiences with Agile have been promising but flawed, and were best summed up here: http://www.halfarsedagilemanifesto.org/
Waterfall is typically employed for critical - read well paying jobs.
Typically 10 lines per day of low level code were assumed - with the following daily breakdown: 3.5 hours of meetings, 3 hours of thinking, 1/2 of coding.
Typically waterfall is reserved for key elements where the cost of a mistake could potentially include loss of life, bankruptcy, and/or embarrassment.
The rest are done in secret. Git'r done. Agile. Lean. skunkworks. I want it now (IWIN). Big boss wants it now (BB WIN). Original Outline process shortfall (OOPS). Call it what you will.
"Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow."
Yes, no doubt. Once you've been indoctrinated with the principles of Waterfall development methodology, it's really hard to shift gears into Agile. Remember the first time you saw C++, after years of programming in C? That object-oriented approach was pretty mystifying. But if you stuck with it, you eventually learned the incredible power of classes and objects.
Agile is just as different from Waterfall, just as hard to transition into, but just as rewarding for those who eventually get it.
Consider a defensive system I worked on for the DoD. The requirements had been nailed down. The design was solid. We'd passed all the simulator tests and field trials. Just as we're about to go into production, a different service ran some tests. It turns out that while we were in final testing, a new system was deployed by "the other guys". The existence of that new system put our production contract at risk, not to mention ... lives. A year and a significant redesign later we were in production. The timing worked out well for us, but even more so for a lot of our troops that didn't get shot up.
What did I take away from this? Requirements change without regard for your development schedule. Our choices are limited:
a. stick to the original requirements and lose the contract (or the next one).
b. find another game to play
c. deal with reality. embrace the fact that requirements change
I adopted scrum in my org, but only in response to a product management org that refuse to do their job. We got features masquerading as requirements, we got endless tactical "the customer wants x" requests all while upper management basically was accusing the team of being lazy for not giving them everything they wanted (and more) right away.
So we adopted agile. This let upper mgmt see we were working as hard as we could and it forced PM to decide "what do you want next? What's the minimum viable set of features? Is this more important than that?"
Yes agile isn't a cure all, but it definitely helps dev remain productive in the face of laziness and stupidity elsewhere in the org.
I've also seen a ton of fake agile (we call it "Fragile") where people adopt the buzzwords of agile without considering that good agile takes a lot of work. Fragile is adopting all the bad parts of agile without any understanding of the discipline involved to do it right (track technical debt, and pay it off as you go. Sprints are no excuse to not do long-term planning / grooming of the backlog. Daily stand-ups, where you track impediments are crucial. etc,)
Success with agile only comes if you understand when it's useful (where there's a large amount of uncertainty/stupidity, somewhere in the org)
It helps mask underlying problems (the uncertainty) while still maintaining productivity. But I wouldn't fly in a plane that was designed with agile principles. Uncertainty in a "mission critical" engineering problem kills people.
Corollary to Hanlon's razor: Any significantly advanced stupidity is indistinguishable from malice.
1) Agile isn't a methodoly, it's a set of prinicples, and there are methodologies that embrace those principles.
2) If you take a particular methodology that embraces Agile principles, such as Scrum, the major benefit you get over something like Waterfall is a clear understanding of how far along a project you are, and the ability to inject changing priorities... In Scrum, you wind up how poor your initial guesses on schedule/length of project are.
What that means is that the vast majority of people who purport to use agile, both as developers and as clients don't understand what their responsibilities are, or what the technique is supposed to achieve. Lots of developers think that agile is about not planning and not having deadlines and clients think that agile is about being able to change their minds with no consequences. Neither of which is even remotely true.
The reason that waterfall fails is that people don't actually know what they want, not because it's a bad system, if you knew your requirements exactly up front as a client, and the developers understood what those requirements meant for them well enough to give decent estimates, waterfall would work perfectly. Unfortunately neither of those things are ever true. Agile when done well lets people plan on scales they can actually manage and allows change and unexpected issues to be caught as early as possible and priced in properly. You want your shiny new feature X and it's going to take 3 days to do, then you either have to extend your project out 3 days or you need cut three days worth of something else. You anticipated feature Y was going to take 3 days and it's now looking like 10, well you know that pretty quickly and the client can decide to go ahead or scrap feature Y.
In essence the fundamental idea of Agile is that when you hit your project deadline, you probably won't be finished anymore than you would have been in waterfall, but if everyone has done their job properly and the project deadline wasn't ridiculous to start with, you should have the most important features so that your client can walk away with something that meets their primary requirements.
It often fails because people don't do it well(clients don't prioritize well, developers don't stick to the priorities, or everyone's estimates and expectations are way out of whack), but in those circumstances your project will fail regardless of your methodology.
If you have a client who uses agile as a way to change requirements every sprint, then know your project is going to fail, if as a client your developers are using agile as an excuse to not stick to deadlines or plan anything then know your project is going to fail, if a consultant is promising that agile will fix all your problems, know they're a fraud.
The great big secret of Agile is the same as the great big secret of most of these methodologies, common sense. You run an agile project for someone else the way you'd run any project for yourself, you set priorities and stick to them, this gets better software out the door quicker the same way it does when you're working on something for yourself.
I've spent years thinking about Agile and development in general. I'm no apologist for the methodology: see my post from just this morning: http://deathrayresearch.tumblr.com/post/27257008711/when-agile-jumped-the-shark. Some aspects of Agile are better than others, but overall, the methodology is based on sound principles. Most notably, there are many short feedback loops (unit testing, continuous integration, short cycles, customers on the team) that decrease the opportunity for hidden problems. This is extremely powerful. That it's used to sell services is undeniable, and their are aspects that strike me as wrong, but this is a good methodology overall.
any model, whether agile, cascading waterfall, spiral -- it does not matter, when used to get all it's developers to do things the same way in the same order is inefficient. most software is a literary work of art and most people do not write in a systematic way. software is not hardware and is not a recipe for making an 8 course meal. software is closer to an artist that paints. yet try and find any tools, processes or environments that support that behavior. now what is even harder is try and get a bunch of artist together to work on the same painting. it does not work. what to do? stop forcing square pegs into round holes, back up and observe individuals working in their preferred environment and their preferred workflow. observe, understand, talk and it might lead you to this conclusion. there are phases within in a software life cycle that become more predictable and thats when the traditional models work their best. thats when standardization of processes, steps, systematic ways of producing results become appropriate. it might also become apparent that not all members of a software team should be involved in the execution end-to-end, they would be involved as stakeholders, but not execution. some folks are better suited for the end of a life cycle, some better in the middle and other better at the very beginning, conceptual. the way people work most efficiently at the conceptual and early phases of a software project is a world apart from the end of a life cycle -- so why force end-of-life-cycle methodology, tools, process, environments where they do not belong? what this means is one model fits all, even for the same organization, will result in lowering the overall team performance. what is required are multiple models, multiple environments that are tailored the the teams and phases of the life cycle. these environment must be highly malleable. and lastly, everyone that really wants to understand agile, just has to go and read Deming, that is where most of this originated from and then was later applied to software, incorrectly.
No, I'm not slapping down money to read their report. I don't have to. I see it work, every day.
I work for Litle & Co. We are, among other things, an award-winning credit card processor, which means that we run on a 24/7 basis with 99.999% uptime. We have a team of over 40 developers, and we run a modified agile environment based on Extreme Programming--it has to be modified to scale up to our size. We deploy new software on a monthly basis, again with five nines of uptime.
Not only do we use agile methodology (pair programming, unit tests up the wazoo, iterative development, continuous refactoring), but we do so with a big, database-heavy service in a heavily regulated space, answering both to the Federal government and the credit card agencies. To make this work, Agile isn't enough; we also hire the best people we can find, and have an HR department that works hard to keep employee retention up.
So yes, if you hire good people and if you apply agile methodologies, you can work wonders in software. But you need good people, and they (the developers, their managers, and their customers) have to be willing to really try it. If you have below-average developers, it's not worth doing anything but getting better developers, either by hiring or training. If you've got good developers, and they're either going in all directions because you have no methodology, or they're stuck jumping through hoops rather than building your software, Agile can make them a better team.
If you're not documenting your code and providing adequate documentation on your feature then you're a lazy programmer regardless of the process your team uses.
Actually is the opposite, since you have short sprints you can see more easily who is the lazy on the team
Brought back from the 15th and 16th centuries and have no value to software engineering.
The good devs know that most of their work consists of non-dev related work. They need to accomplish most of their productive tasks during their free time (unpaid). These include code cleanups etc. which are usually not approved by their senior managers. The good devs can give their identity and soul to the project, not just raise paychecks.
the Project Management Software is the most important thing, not reading a 200 page book or taking a class in agile programming. My PMS programming methodology demonstrates this.
Yes I cover that in my blog post http://jordanbortz.wordpress.com/2011/11/23/is-scrum-just-a-series-of-mini-waterfalls/