Slashdot Mirror
A Decade of Agile Programming — Has It Delivered?
snydeq writes "InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, 'heavyweight' software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban — a trend some see benefiting software development overall."
No
A team in my the company I worked for was designing a new set of software and were utilizing Agile development. Well, seems they spent so much time going back and changing the software due to the changing demands that they never got anything finished to demonstrate so they wiped out the project team.
As a developer I find it to be a pain in the ass. Maybe in wasn't done correctly in the projects I worked, but this is my view.
And scrum is really offending to people that actually have a tad of self respect: I mean, really, pigs and chickens ?!
Quoth TFA: "Despite potential pitfalls, experts in the agile space agree that implementation of agile practices has benefited software development overall."
And in other news, despite potential pitfalls, the pope agrees that Catholicism has benefited religion overall.
I've been working in the sofwtare industry since 2007 in a small team (individual projects ranging from 1 to 10 persons). We've always used scrum. Mind you, not by the book but heavily modified to fit our style. Seems to work if all participants are even a bit motivated and not totally clueless about the tasks at hand.
I've worked in 100% waterfall, and in good agile environments, and I've found the key is to keep things small-a "agile", not to concentrate on capital-a Agile. Some places embrace Agile as a process, and fill binders with process documentation around their Agile process - at which point it's no better than any other.
I think the key to success is summed up in this line from T3FA:
I remember when we wrote video games for Atari and Amiga. and we just hacked away with quickly agreeing on things we had to achieve and who had to to what while we went along. So we were very agile without knowing the term. but this is over 20 years ago. and here we are again.... the full circle.
if waterfall has delivered?!
It seems most projects work in spite of waterfall, not because of it.
I'm not saying it doesn't work. That is for small/medium projects with a very tight scope it does.
What's the name of that FBI project again?! Virtual case file?! Oh well...
how long until
I work for a company that uses the scrum variant. It's been working for a while now and the company hasn't stopped growing because of it. The trick is to know when to say no to a change request for the current version of your software. You can always develop a functionnality for the next version, which in Agile is always in a short time. (We work with four iterations per year). All in all it works great for the time being.
In my experience, software development methodologies are more of a way of describing how teams already work. Sure you can put a name to it, polish it a bit, and other people can work toward that name, but there were tons of "Agile" projects and "Agile" groups before the manifesto. Maybe "Software companies" didn't do it before 2001 I don't know... but "software departments" of other companies have pretty much doing this since I have been around, which is a lot more than a decade.
The truth is that electronic delivery created agile development, at least for software companies. Internal departments have had the connectiviety for 2+ decades to deploy new releases often, but it wasn't till the late 1990s or early 2000s that a "boxed" software company could provide regular working releases to their customers (who wants to mail a CD or a stack of floppies every 3 weeks, and what customer would actually apply them?) Web-based apps and self-updating software just brought dedicated software development in line with corporate development practices, and then it was given a name.
only then will I take it seriously. It's different from waterfall, but the results don't look different to me, and I have yet to see a decently designed independent study comparing the two (If you have some, please send links).
Please do not read this sig. Thank you.
Bits and pieces of agile are good. I think if you take the spirit of agile.. that is doing things because it's a good idea, not because you have a compulsive need to fill binders with documentation.. it can work well.
I like unit tests for regression testing (that is, verifying that the software still does what it used to).. but I think test driven development is more hassle and riskier than it's worth (now instead of just changing code when the requirements do a 180, you have to change code _and_ unit tests, ($cost + $time) * 2).
I like eliminating "because we need documentation" documentation.. but I think there is great value in documenting stuff that is complicated or weird. Having a binder full of "the UserAccount class represents a user account. It is comprised of a username representing.." is useless. The same goes with diagrams.
The worst is when agile is implemented as a buzzword. "We are agile! We have a binder full of documentation describing the rigid agile process we follow!" (not saying agile or processes in general shouldn't be documented, but in my opinion the whole point of agile is to be flexible).
Wait.
Please do not read this sig. Thank you.
Did Al Gore invent Agile as well or something?
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
I'll usually pass on any job asking for agile, scrum, xp, etc. Any company asking for those 'skillz' is sure to be a nightmare to actually work in. I've been a consultant for over 20 years and every single project I've seen where they emphasize this mode of working has delivered extremely sub-standard results and I've worked in everything from banks to startups.
Mod the parent up. I'd done agile within Waterfall for about a decade before 2001.
Art is the mathematics of emotion
Sweet, more supposed justification for the cargo-cult bullshit that passes itself off as modern software engineering practices. "Yes, someone said that every morning we must huddle and Scrum and the Scrum must take place like this or it won't work right! If you let someone sit down it won't work right !! Now make sure you don't do anything until you've jumped up and down together and given a handy to the dude to your left or it won't work right !!!"
2. It at least notionally asks the management to consider resources while committing to features.
3. It allows some kinds of software project to managed better. Things like merging products when companies merge, or when porting software to a new platform etc.
4. It works when the project has a large number of people with identical or largely similar skill sets. If the project has large number of specialists (like "Frank here is the only one who can even touch the turbulence modeling code") development will be slow, agile or not. At least the management should know not to commit to too many turbulence modeling features.
5. Rally proponents broad brush all skeptics as "people not willing to change".
6 Too many Rally concepts come from manufacturing and some of the examples and analogies don't even translate correctly. Take the famous, "burnt toast" example. A company decides to burn all the slices, and then scrape off the charred crumbs to get the color desired by each customer. Supposedly Rally will toast them right in the first try saving all the efforts that go into scraping off charred crumbs. Well, in software it does not cost me any money to char a toast and scrape the crumbs. Often times it is perfectly ok to render all the pixels of each body, even if another body is going to come back and override a lot or most the pixel later. You waste time trying to predict the final pixel value to render it just once.
7 Some times it is funny to see the Rally proponents not using Rally methods to develop their presentations, not using Rally for their own internal websites! Too many of them recite from a text book or a holy book instead of using actual code/project examples.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
"Agile Programming", is a trick to get programmers satisfy management lies in schedule.
Once schedule is satisfied, they look good; they move on to the next lie.
Whatever happens after that (bugs, code reuse, maintenance, adherence to standards, scalability, interoperability) is not their problem.
I appreciate good management. I can live with no management, but I can't handle bad management.
SCRUM has sort of become a device for a manager to avoid managing. The human in the picture is replaced with a sprint chart and backlog tracker. It lets bad managers get by, while good managers are really thrown out of the picture.
I hated scrum in my old job. But the new job just throws out a list of features to implement, ranks it and throws it at one of us. There are no punishments for missing a day, no tracker to guilt-trip you and most importantly, the stand-up meetings are just before lunch. And mostly, serves to keep our communication channels open across the team.
I hated the time-keeping TPS report style scrum, but I'm cool with the new approach. I love the idea of sprints and taking a week out of a month to hammer something out. But this system only works with motivated teams with a fair scrum-master.
But I repeat, it is not a replacement for good management. It is as good as a way of letting me manage my tasks,but please (for the love of God, please) do not use it to manage me.
Quidquid latine dictum sit, altum videtur
They all existed before the agile manifesto was written.
Scrum was described and named like this in a 1995 (https://secure.wikimedia.org/wikipedia/en/wiki/Scrum_%28development%29).
Books on Extreme Programming were written in 1999 (https://secure.wikimedia.org/wikipedia/en/wiki/Extreme_programming).
Kanban was used in the 1950s (https://secure.wikimedia.org/wikipedia/en/wiki/Kanban).
Get your history straight.
I post anonymously for a reason. But the next person that decides they want to sit down and "pair program" with me might just get stabbed. Yay almost 1/2 the productivity!!! 1 person sitting the other thinking:
- You smell.
- God I can't type while someone watches.
- Fucking sip that coffee one more time bitch!!
- I have to fart.
- I don't want to hear about your kids.
and the biggest..
- Touch my screen one more time!!! daaare you. :-(
I swear, the ones that are the most interested in this programming paradigm feature are the ones that can't code and want to feel part of the process while still acting in their typical ineffective fashion all the while flying under the radar.
In my experience, Agile works for two things:
1) Maintennance and support development
2) Extremely strong engineering teams
Formal processes with more up-front planning and review like waterfall allow you to turn out high quality product with average teams. You can't use the typical Agile processes with average teams and do substantial new development, but I've seen it work well enough for incremental development or support engineering/bug fixing.
A good manager will know his or her team and use the methods appropriate for success with that team, and not chase buzzwords.
In my experience, though, these days there are a LOT of bad managers.
What model is it when people tell you they want something, you say "I can sorta do that" a while later you give them something, they say "I guess that'll work" and you're done? Cause that's the environment I'm in. Occasionally people come to my desk to say stuff and I just yell "SCOPE CREEP" really loudly and they walk away.
I work in customer support for Agile Web Solutions, the makers of 1Password (a password management system) for Mac, Windows, iOS and Android. Agile development seems to work well for us.
I think that there are two reasons why this has worked well for us while not for others.
There are drawbacks, of course. What we like to think of as "surprising and delighting" and delighting our customers usually works, but sometimes we have to take steps back from something visible which we've tried. I think that over all this still is a "win" for us and our customers, but it can sometimes be disappointing.
A perceived (but imaginary) drawback is "wasted effort". We put a great deal of effort into getting data syncing among machines and devices to work via webDAV (and in particular, MobileMe). For a variety of reasons we had to abandon that approach and go with Dropbox (with which we are very very happy). To some this might seem like wasted effort, switching to a different approach after a great deal of effort has gone into the first one. But in fact, agile principles in this case simply mean that we don't fall victim to the sunk cost bias.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
i find that agile is used alot as an excuse to just go ahead and code. real agile, and test driven development is hard so most agile teams i have worked with have just used the word agile to skip the stuff they dont like (documentation) and go strait to coding. this leaves you with out important pieces that you are going to need later a year down the road when you want to add features, but everyone forgot were they left off. real requirements and documentation are important, but time consuming. there is reason why they have survived for this long and people still use them today.
How much did Object Oriented Programming deliver on its first decade? How pervasive it is now?
If nothing else, just considering the promotion of good practices like unit tests and refactoring - look at JUnit and all the refactoring functions in Eclipse, I would say Agile Programming has already delivered a lot of value to programming.
It probably won't be replacing waterfall for a long long while, but considering that almost no development house really follows waterfall (anyone really has a complete set of requirements before they start development?), that's not really a meaningful metric.
Oliver.
Agile programming works when performed by agile minds. Not all programmers are able to adapt to constantly changing requirements, but some are and they are the ones who succeed with agile programming.
Agile / XP worked great for the last project I was on for a few years. Before that I was on a few different ones using something approximating waterfall (small company, no named processes) but then I quit there and got on an XP project, with half the team in the U.K. and half in India (I was in India).
Overall, we developed software better and faster than anything I'd done before. I think the key to the agility was the whole team bought into it, with the business analysts doing their part to break requirements down into small enough chunks that the developers could develop them top to bottom in a single iteration. That gave them a good idea how the project was progressing and whether we, as a team, were creating software that would be usable by the end users. It was quick to change things if something was developed that ended up not being very usable (i.e. looked good with static screen designs, but sucked when actually used).
In general it worked best when the team was weighted with more senior developers than junior developers, as the senior ones had a lot more "let's get it done" attitude instead of "tell me how to do it" and "tell me what to do next".
Pair programming? Unit testing? Stand-ups? They all helped contribute, but I didn't see them as the core parts of what made the team function well. That was basically breaking down requirements into small chunks for easy changes.
Sure, it wasn't perfect, but it was a hell of a lot better than any other project I worked on before that.
you will not attain it?
The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy's cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him.
— Miyamoto Musashi (The Book of Five Rings)
IT, or at least some people in IT suffer from what I call the "Oprah" syndrome. No, not the weight issue. The idea that a problem is just one problem and that it can be solved with a single solution. Or the silver bullet that will solve all your problems at once.
Software development is bloody hard, partly because it doesn't deal with a real product and testing a software product is extremely abstract.
If I design a better brake pad, I can test this fairly simply AND thorougly. We know exactly what it is supposed to do, how it does it and how we can compare performance. There is no magic, if the brakepad reaches 198 degrees on a sunday, the trunk will pop open. Also nobody will ask a brake pad engineer to add a christmas special to it, on the 25th of december, at 8 in the evening.
Web development especially suffers from the idea that if only we implement magic method number #45324521, all the hassle of web development will go away. Writing specs is long boring and not very sexy. So lets do agile and not write them anymore. Problem solved... eh no because spec writing is long boring and not very sexy because getting the requirements out of a user is like sucking cock. The user might enjoy it but you are just left with a bad taste in your mouth and a desire to throw up over the user. Or maybe that is just my dates.
"But if you do agile right", but if you do documentation driven development right! Any method, done right will most likely work. That is the definition of doing it right. Why is it so hard to do agile right? Why are there so many variants already?
I see a lot of "magic" solutions in web development.
Database abstraction, so we can magically switch database!!!
Question: When have you EVER switched database on a web application and HOW easy was it? Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same? Then go stand in the corner, because your code lacks any optimization. Real developers optimize their code for the specific environment they are using. This includes making use of database specific features. Don't use Mysql auto-increment and PDO and think you are database independent.
Frameworks take all the hardship out of writing code!!!
Question: How smart do you think it is to hire a coder who hates to code? It is like hating a singer who hates to sing, a spokeperson who doesn't like talking.
This is where a lot of the silver bullets come from, from people that don't actually want to be a developer but just cash the paycheck. You don't hire a cook who only knows how to nuke frozen meals do you? If you go to the supermarket and buy a microwave meal thinking wow, this makes cooking easy, then here is a hint: IT AIN'T COOKING. It is heating up food.
I see time after time some framework or tool promosing a complete working website without writing a line of code... EEK! That is my JOB! Luckily they are all wrong because what at most they do is create a straight CMS for your database, which is rarely what the customer wants. After all, there are already plenty of tools to graphically maintain your database content.
No, Agile hasn't delivered... for those looking for a silver bullet to the problems of development. For others, it is a valid method with its own problems that puts it along side more traditional models, not ahead of them.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Reminds me of an old poster from my CS department. It features legendary crotchety old fart John McCarthy angrily looking at the camera, with the caption "Programming: You're Doing It Completely Wrong."
SJW: Someone who has run out of real oppression, and has to fake it.
I work for a very large video game company, and agile works for us. My team has a twin-team, one that uses 3 week iterations while ours has adapted to 1 week iterations and it works great. We release often and early thanks to various automated processes we employ, making life easier for everyone. Managers stay happy since they can actually see progress and measure team velocity which results in an actual accurate sprint/accurate planning. Planning for our iterations doesn't take that long also with smaller iteration cycles. I am happy with it.
Tired of my customary (Score:1)
I was a beta tester for Multi-Ad Services in 1988/89, when they were first developing Multi-Ad Creator. I had a telephone number that I could call that let me talk directly to one of the engineers. Our Ad department was running this on Mac II's, under MacOS 6.x. We'd find repeatable ways of crashing things, or think of a nifty feature that we wanted, make a phone call, and usually would have a disk in the mail within a few *days* with the changes available for testing. There were a ton of features put into that product based on the direct recommendation of our small group, and we could almost immediately try out the changes and give feedback. Years later, I was at another location where they were using Ad Creator (an ancient version by this time), and they were having an issue that would only be addressable by adding a feature in the software. I called the number on the back of the box, on a whim. The person on the phone could not answer my question about whether newer versions had the feature I needed. I eventually got transferred to an engineering manager, described the feature, and was told that it did not exist, but he thought it was a great idea. He asked for contact information, and in a couple of weeks we had a set of disks with a beta version of the newest software, complete with the new feature. They gave me a new license and everything (the existing software was like 8 years old). The feature worked great.
Frame Technologies was very much the same sort of company, before Adobe consumed them, and I had similar experiences with them. I have two full versions of Frame that were sent to me in order to answer questions that their tech support didn't know how to answer, and their demo would not allow me to find out.
This ability was always there, for teams willing to pursue it. I could never say enough good things about working with those guys. Looks like the Ad Creator guys are still at it, you can download betas and provide feedback right from their web page.
I like agile when people use it to learn the how and why of managing software projects. It can provide a great platform to debate, discuss, and learn.
I hate agile when people use it as a manifesto or religion, assuming it works best in all aspects of all projects at all stages and with all people. And like religion, they use it as a means to gain power over those who would use reason and logic instead.
And dude, this is wrong on so many levels:
"One of my guys keeps telling me that he would like to have more specified requirements. I keep telling him we're going faster because we don't have specified requirements," Weston says. A hardcore requirements document is a "waste of time," he adds.
Still not quite SCRUM (and I have done a scrum-masters course).
The goal of agile is to deliver the greatest benefit to the customer. Their representative in your team is the product owner. They don't just "throw the requirements at you". They should be making a backlog of implementable features (user stories) initially ranked by priority. You are then supposed to be estimating the complexity of those in order for the product owner to decide which is the most important given the resources and difficulty (this is a periodic backlog grooming session).
At the start of each sprint you select some stories and once you have estimated the tasks and effort for those stories you, as a team, commit to delivering those features. The daily standup meetings are for you to share you progress with each other (and update the burn-down chart). Peer pressure among the team is what gives the guilt-trip if you miss a day. The burn-down chart is what gives the product owner the state of the current sprint.
SCRUM has a very strict process. It is very light, but it still has rules and roles to follow. Anyone who tells you otherwise doesn't know what they are doing.
And there is no such thing as a "fair scrum master". The scrum masters role is just to assist the team to organize itself and keep the wolves away. They are not your boss.
...not coders. Any coder who needs one of these silly methodology to help them work properly is probably in the wrong career.
In the time I've spend in stand-ups and other waste of time situations like that - that only exist so project managers can look like
they're doing something when the directors come calling - I could have fixed half a dozen bugs.
And the idiotic names don't help as well. "Extreme" programming? Give a frigging break. Extreme programming would be trying
to fix the code to a nuclear power station when you've got 2 minutes before it goes critical, not just making frequent code
releases for customer review. Agile? Whats that, programming while holding onto a rope upside down and typing with one
hand? Scrum? Are all the coders expected to line up and push against each other out in a field?
FFS , talk about making the profession look like a load of wannabe's who don't actually do anything macho but like to
pretend they do by giving bog standard office work names from the 101-kool-adjectives book.
In my experience plenty of teams "do Agile" without understanding what it's supposed to achieve. People just cherry-pick and adopt well known bits of some Agile methodology or other (for example the stand-up meeting) but then don't do it properly or miss the feed-in practices that are necessary to make it work.
It's all about "Being Agile" (i.e. fashionable) instead of "Having a way of developing software that can consistently cope with fast-changing requirements minimizing wastage, chaos and cross-team overhead".
Just as an example, in the last 7 or 8 years since Agile became fashionable, having been in and out of multiple teams/companies that use Agile to a smaller or greater degree (I'm a freelancer), I have yet to see a proper Use Case which describes in a consistent and well defined way a feature that the system being designed must provide, including handling of error conditions. In fact, 9 out of 10 times, people forget to account for errors (even user errors). Use Cases are the basis for each development cycle, the point of communications with those defining the requirements and the basis for prioritization of work and yet most teams can't even get those right.
Then there's the flaws in analysing the requirements to do make sure the system has all the data that it needs (if for example one Use Case says "The user will select one value out of a list of options for field X" you need to have those options coming from somewhere, potentially ending up with a whole bunch of other Use Cases dealing with maintaining those options).
Agile doesn't solve the essential problem in IT which is a lack of understanding of the software development process, lack of preparation and lack of method - it just provides cover for those developers which do everything in an ad-hoc, reactive way and will then excuse themselves as being "Agile".
There are simply not enough people around that try to understand the process by which people create a software system or application from a "not so well defined set of needs from the users" but lots of people focusing on the quasi-aestetic details of some language or other - too many people asking "How?" not enough asking "Why?"
I actually refuse to work on Agile/Scrum projects.
Why?
In my experience, and hey, maybe it's just me, but I never would work harder at producing less at worse quality then when on an Agile/Scrum project.
The problem is not Agile versus Waterfall, Its the lack of documentation early in the process and knowing the business needs during the project. It should be that management approves the project, business analysts get the business needs and create requirements, and IT reviews the requirements and builds the software. The reality is that management used to be IT, so they *KNOW* what the issue is and writes the requirements, system analysts are used in place of business analysts to write the requirements, and IT just has to "get er done!". By the way most companies aren't software houses, so why the hard deadlines? Oh yea bonuses are attached to the projects. As I deliver my project on time I get my bonus. It doesn't matter that is a feature starved,half-assed implementation that make everyones job just that more difficult.
"Ones and zeros were everywhere. I even think I saw a two!" - Bender
Someone will say agile methodologies are just a collection of best practices organised together in a cohesive whole and they don't see the value in that.
Someone will say they did XP and didn't see what was so revolutionary about it, in response to questions it will turn out they didn't do the planning game, didn't do TDD and didn't pair program
Someone will obsess about a detail of an agile methodology, say stand up meetings, and use it as a strawman to attack all agile process, they'll also completely miss the point of what that detail is trying to achieve.
etc.
Puzzle Daze is now my job
Agile has had the misfortune of being a buzzword that anybody can write about and sell books for. Lots of places then use it as the buzzword process that they are following when in reality the only thing that has changed is what they are calling it.
Other places genuinely try to implement it and find that by getting some things slightly wrong they cause themselves more problems than by sticking with what is familiar to them. This naturally sours everybody involved to agile.
TDD and XP are hard to get right.
However, TDD - Test Driven Development - is something that if your not doing then you probably should looking at implementing it. It raises the very valid question that if you don't know how your going to test something then how are you going to know when you've got it working. It encourages modular code, well factored code because otherwise writing the tests is going to be a pain the ass. Hint - if your finding writing your tests difficult then it probably has something to do with the design of your code, and that is why writing the test first works to improve design.
XP is even harder because it's a superset of TDD. Not only do you need to be getting TDD right but now the process also covers project management and client interaction.
In my mind, the most important part of agile, the part that makes it agile is not any of the above. XP and TDD may be good things but the essential part of Agile is the weekly retrospective where the team sits down and spends an hour on discussing what's going well, going badly or is just worrying and then comes up with ideas for how to improve what they are doing at that point in time.
The idea that the process that your team is working by is not fixed but is evolving is the most important idea of agile.
The biggest difference I notice with agile projects is the improvements in testing. Testing works so much better when its happening continuously rather than only at the end. Its far easier to fix things that testers find in code you wrote yesterday then code you wrote months ago.
You almost got it right, though electronic delivery is not a requirement of Agile. The Agile manifesto was created by successful software developers that did not want to sit around creating reams of documents. The Rational, six sigma, and other process folks were getting out of hand, and companies were starting to impose heavyweight processes on people who didn't need training wheels. Solution? Call what you're doing a process, sell it to management, go home.
I think that you spent your time in a wrong kind of stand-ups.
You see, if you have up to 10 people on your team, and each one gives precise answers to those three scrum questions, you are gonna spend no more than 15 minutes in that meeting. After that, you know what all other people are busy with, so should any issue pop up, you know who to ask. This is less time to spend than if each one were asking another one by one.
Scrum done wrong: 1) a half an hour stand up; 2) scrum done in teams with more than 10 people; 3) off-topic discussions during the stand ups.
If you are saying you can fix half a dozen bugs in 15 minutes, then what the heck were you doing yesterday? Pushing trivial to fix bugs so that you can overclock your bugfixing karma the next day? Doesn't look like competent, anyway.
http://infoworld.com/print/142761
No "next page" needed.
^[:wq!
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html - Steve Yegge
remove NOT from email.
The original manifesto's key message was "people over processes" which I still agree with.
This is I think, a totally key point.
Agile is supposed to describe a way in which people can work together to improve productivity. If you think about it, what it's really doing is attempting to document how a successful team (or one kind of successful team) interacts, like Goodall studying mountain gorillas.
So then other companies want to have successful teams too, and study what was done. But instead of saying, here's an approach, everyone read this and lets try something similar, instead of that companies all over have managers reading agile books and then using that as a template into which they cram all the developers they have, ignoring the differences in the way a given group interacts with each other.
And that's because it's easy to do one thing, but very hard indeed to adapt something for the individuals doing it. The payoff is enormous if you can get individual tailoring right, but it's so hard to get right I don't know that you can even try except to try and recognize signs of success in groups and encourage them (which in turn leads to cliques if you are not careful).
It's something that happens to any methodology, in short order it will ossify into rigid methodology because the communication of how something works spreads to most people in the form of text that looks to managers like a template for how to arrange "resources".
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Absolutely not. Never before have I experienced a method of programming that can be more aggressively mismanaged than agile. Many developers think agile is a means to produce better code, faster, and with better specs. Most management sees it as an excuse to provide no specs, to change their minds on what they want every 5 minutes, and call all of that "agile" development. These things ruin the name of agile development and provide such a bad experience for anyone stuck working with it, that it simply can't have managed to do anything but fail utterly to deliver. People have been fired over misinterpretations of what agile is. Others have left because of a misinterpretation that was shoved down their throats by management. And that's just all where I work... Perhaps it's better in other places, but I've never heard a story of it going well.
Big successful projects are not developed with any rigid methodology. The secret for a successful software project is having good developers.
Who is a good developer you ask? The ones that are interested in both the big picture and the small details. The ones that are motivated and capable of tackling the core problems and are not afraid to get their hands dirty with solving also minor problems. They do what needs to be done. They live to serve and they enjoy developing stuff.
Who is not a good developer? The ones who endlessly hunt for that silver bullet, who avoid getting their hands dirty with code and so they forget how to solve problems and they forget what it takes to deliver actual working solutions.
Though in theory the agile model benefits good developers in practice agile development nowadays is pushed by the exactly same proponents who were responsible for the heavyweight development methods before. These consultants who preached waterfall, RUP etc. now preach agile and impose the same heavyweight structure that was the problem with the other methods.
Issues around software development are, in my experience, about the people, not about the process so much.
Give a group any process and it will be contorted in whatever way required to make it act the way they want, but with new buzzword compliance. Frequently with misguided attempts to adopt one hard line rule or another without really appreciating the meaning of it and just ending up with arbitrary stupid things.
The best projects I've seen are ones that didn't fret overmuch about being able to rubber-stamp their process with one of the 'big names' (the only big name in style currently being 'Agile'). However well intentioned the people writing these processes may be, they simply cannot significantly impact the nature of the people actually trying to implement them.
I think Agile would've been less vomit-inducing with any other name. Naming your process Agile just invites every project manager to jump on it based on the name alone, even if they will do everything wrong and end up with a rigid process they will still declare 'Agile', which is always good.
XML is like violence. If it doesn't solve the problem, use more.
Anyone who works in a team of less than about 20 people already knows what the other team members are doing generally , and they'll know specifically if they work with them on a day to day basis. You don't need a meeting every day to find this information out.
"This is less time to spend than if each one were asking another one by one."
Or you could just ask the team in one go. I don't know where you work but where I work I sit within 20 foot of my entire team.
Interesting, I did SCRUM in a previous job and thought it was the worst thing ever invented. Current job does it too (in fact, my interview for the job mentioned this, and made me worried). However SCRUM in the new job seems almost natural and the right way to it here. That being said, I like my management here (fairly competent and good to work with) compared with the last job with SCRUM (bunch of morons).
My experience is that quite a few software development organizations cover up a what is essentially a "death march" by using agile terminology. They don't follow any recognized agile development methodology nor is the effort a proper waterfall development. There is just enough agile terminology to make it sound like an agile development. The effort usually fails and of course management would rather blame the methodology or the developers rather than admit they couldn't do what they said they would.
Beware of agile-speak when job hunting.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Is it me or is Agile just another way of formalizing being informal?
I reckon if you can establish a good working relationship with your client then you're probably doing some form of Agile Development without knowing it.
If you can't establish a good working relationship, then no methodology will ever help.
Having worked under the Agile whip for the past year, I have to say the methodology is horrible. The planning is ridiculously costly, and the constant pressure makes people manic about their work. Ultimately, people stop caring about the sprint deadline and just resort to letting tasks go undone.
No; I do - let's say try to do Agile and I'm a CSM, since its inception and on different locations and cultures; in the last 5 years, when I did it mostly in North America I never seen it succeeding; mostly the reason was hijacking the Agile and masquerading waterfall or chaotic processes under the Agile terminology/dictionary. As always, human greed and immorality overtook the basics of the Agile manifesto and lead to disastrous mini-waterfalling with dire consequences as accumulation of huge technical debt, broken estimations missed deliveries and developers psychological burn out and collapse. Of course, the poor slaves pushed to work crazy overtime and crunching tasks where always at fault. The core problem I always pointed at in the Agile communities I had the chance to talk about, is that there are no *Agile Certified Organization* certification criteria and accreditation auditing processes and trained, certified and experienced auditors. This leads to a gazillion of organization declaring themselves as Agile by saying that they do or try to do Agile but without *being Agile* in reality. Until we will have this accreditation mostly we will see failures and this will lead also to Agile going to the garbage bin of the various trials in doing better software development and having a decent profession - not one well known and renowned for all possible worker abuse and wrong doings. At the end, maybe there is no method to do better software development because of the nature of the people and the context of being a no regulated profession - this opens the door to everything and in this libertarian approach always the winner will be the one owning more power - in this case the positioning in the monetary interest stack of the project. This is nothing else than feudalistic primitivism which in time will destroy the whole industry as the older ones will pursue different career options - and I know lots of them who already did it, and the young ones will not step into this industry anymore. Wherever I have the chance to participate at interviews I see mostly immature kids and not only, some are close to their 30s, but their professional and social skills are so low that many years ago these people wouldn't have gone even over the phone screening phase.
In a training document I'm writing, I have a footnote along the lines of: "using any sort of automatically generated code is bad practice". You get mediocre results - maybe better than what a poor programmer would create on his/her own. However, the good programmers write all their own code. In the end, the bit of time they would save using a framework would be more than lost fighting with and fixing the results. And most likely they use abstraction, so that they can easily re-use large portions of their code in later projects.
Enjoy life! This is not a dress rehearsal.
"SCRUM has sort of become a device for a manager to avoid managing."
Bingo. Yet another buzzword system to allow marginally competent middle managers to report something to marginally competent upper-middle managers. For good teams, with good managers, you will succeed with - or without - SCRUM. For poor teams and/or poor managers, it doesn't keep your project from sinking, but does give you the good of moving the deck chairs around.
Enjoy life! This is not a dress rehearsal.
Yes, anyone adhereing to a strict waterfall model today is probably being silly.
If you are doing internal-only development you can get away with constant change. When there are real outside users there is real, external documentation and marketing materials. There is a real date for a product launch, and things have to be stable for it.
Marketing materials need to be prepared and printed. If they take a bunch of screen shots and sent stuff to the printer Marketing will not be happy with the announcement that those are the "old" screens and the "new" ones are much better now.
An really funny scenario is some marketing type is going to give a demo of the product to some big customers (prospects, really) and no longer understands how the "new" product works after the latest round of changes.
Yes, I have seen that happen. The result is there are some new developers working on the product and the launch is delayed. Sometimes for a year. Sometimes the original developers have a hard time finding a new job.
Change is good, stability is good. The intersection of these two is really great. Anything that is too far away from the intersection tends to be bad, especially at the outer edges of either.
Steve Yegge laid it down very well years ago. It's a long read, it's worth the time, but if you don't have the time to read it all, here's a quote:
"When I was a teenager, my dad and my brother Mike decided to make homemade chili. I'd never seen it made before, and I watched with keen interest as they added beef, beans, some veggies and spices, and other ingredients. Dad would taste it, add some more ingredients, wait a bit, taste it again. My dad has some pretty good recipes. So you can imagine my puzzlement when he opened the cupboard, pulled out 2 cans of Hormel chili, opened them and dumped them in.
I waited a respectful moment or two before asking him why he was adding canned chili to his chili. They both said it tasted terrible, but, as my dad now-famously observed: "You can start with dog shit, and if you add enough chili, you get chili.
Similarly, if you start with an Agile Methodology, and you add enough hard work, you get a bunch of work done. Go figure."
End of quote.
Name one world class product (in terms of features and commercial success) that was created with Agile.
While you have a valid example of why database abstraction CAN be useful, you have not actually proven that it must be done every time just in case you might switch sometime in the future.
Seen to many developments throw speed out of the door for a migration that will never happen.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
... if used properly and in the right environment, it works great.
It still amazes me how often folks in this field still try to make a one-size-fits-all tool, be it a programming language, OS or development methodology...
Check your premises.
Agile got ruined by people who wrote books and taught classes on it. I like the PMS Programming model based on Agile better.
Both my current employer and my previous employer claim to use the Agile process. What this means to both development teams is that the developers didn't have to document ANYTHING so they could just pump out code. I work in the testing group, so we never had any requirements or other documents describing the functionality that we were supposed to test. At best we got a handful of very basic use cases. Agile is just a word to throw around to mean whatever they want it to mean.
I have practiced, and been an advocate of the "spiral model" since its first publication by the very famous Barry Boehm in 1986. See: Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986.
He advocated a model of short iterative cycles of refinement - the very essence of Agile (with less of the dogma). So we should really proclaim: almost 25 years of Agile (but ten years after the re-branding).
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
YADW - Pronounced , Yad-Wha or, "Yet Another Buzz Word"
This is perceived by a great many people to simply give the marketing idiots an excuse to simply just keep changing everything continuously while spewing forth to the customer "We Are Agile we can get those changes in no problem, have em for ya next week."
It has lead to unsound programming practices, unsound design methods and has given the term "Code Bloat" a whole new meaning.
The marketing idiot walks in and wants feature X added like yesterday since he will be doing a demo day after tomorrow and it simply has to be there because he saw it on a competitors product. Programming Manager fearing for his job desperately Googles like a madman looking for feature X and finds it in a 100,000 line framework and tells the troops to "Put it in" since even if they dropped EVERYTHING and ALL the programmers immediately started trying to implements feature X it would take a month to do it right. In doing so, they implement feature X and introduce 30 more critical bugs which now have to be tracked down in code that no one in the shop is familiar with and have bloated their code base by 50% because they are "Agile".
The ability to rapidly change the code is not something to take lightly or use in a reckless manner but sales & marketing idiots never have and never will understand this and that includes former coders that are now sales & marketing idiots because once the sales & marketing mind set removes from your brain any semblance of intelligence it is just over.
I was once in a meeting in Silicon Valley of a startup with the Sales & marketing idiot, the CEO and the VP of Development. The S & M idiot starting spouting about how they needed to add that feature and this feature and do this and do that and the other. The CEO listened patiently then when he had a belly full of this idiot he stopped the meeting and said these simple words" "You are here to sell the product we build, so sell it or I will find someone who can.".
Hey KID! Yeah you, get the fuck off my lawn!
I love how the article asks "has agile succeeded", and the agile folks answer "yes it has changed the industry". My response to that is, so what? The industry has changed sure, but is it for the better? Where are the observable facts, the empirical studies, etc, that agile has improved software development? This is just like the OO fiasco -- no measurements to say whether it works or not, just a load of hot air and waffle advocating the benefits of the approach. The software industry never changes ....
Results from last Expansion:
-Major feature of the patch (basically the only new one) got castrated from all but the bare minimum functionality because they couldnt meet time limits. ...
-they introduced ~5 new, and reintroduced another ~5 old bugs
-instead of fixing new/reintroduced bugs they decide to release PATCH version 1.1 with MORE new functionality/code rewrite cos that was in the schedule, and schedule is more important than quality
-1.1 broke so much people couldnt play at all
-after 1.1 they released SIX hotfixes that didnt fix anything or broke even more
-after that they decide to stop embarrassing themselves and released 1.2 instead of hotfix number seven, AGAIN instead of fixing bugs 1.2 introduces even more invisible to the player code rewrites
New expansion was on a test server before release, bugs were reported but AGILE forced timelimits meant NO ONE read bug reports :-)
From that experience what Agile means for me is TOTAL lack of Q&A.
Who logs in to gdm? Not I, said the duck.
Any discussion of Agile and its value calls for a mention of Orson Scott Card's How Software Companies Die. Card makes the very valid point that good software developers abhor deep and thorough control of the "process" by which they make software. Typically, the developers I've known to like Agile are the mediocre ones.
Agile won't make a bad team good, and it will make a good team a bit slower, with sprint synchronization, a meeting-heavy culture, and commoditization of development resources. The only big win that I see for Agile is the ability to more quickly call the failure shot. There's value to this, but every single Agile group that I've encountered, worked in, and heard of has eventually moved to valuing the process over the practice of developing software.
Believe that being able to measure the process is critical to producing good software? You're a manager who has read too many crappy management books and spent too little time in software development. Believe that being able to measure the process is more important than what comes out of it? You should take a look at Agile.
A team of nine women will deliver a baby in one month. Through four iterations per week. In each iterator one body part will be produced and delivered.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
pretty much basically any software development under the megacorporation level is now being done through agile methods, or close relatives. noone is preparing huge docs, and then going over those docs through a cumbersome development process over years.
medium to small businesses are practically having their everything built as such. minus the vendor locked ones, of course. you can gleam a lot from examining the ebb and flow of such small to medium scale contracting work in sites like elance.com
and, on the megacorporation level, things have turned more agile with passing days. companies like google started to turn out software fast, and then add up increasing functionality over time, and this undid a lot of other, traditional companies, like microsoft. they had to adopt similar policies to cope up too. it was inevitable - while you are loitering over the project of an idea for 2-3 years, some others pop up a minimum but increasing functionality version and get ahead in the market. it was 'join them if you cant beat them'.
Read radical news here
I learned Extreme Programming in 1999. The article that started Scrum was published in the 80s. So... what? Insanely wrong articles aren't anything new in /., but in this case I don't even know what it's supposed to mean. Maybe it was submitted from an alternate reality.
Developers that blame changing requirements are fools. The requirements document is alway the most volatile document of any project.
Do your developers understand abstraction, the principles of design patterns and separation of concerns? Do they have any understanding of commonality and variability analysis? Do they deliver packages that can be tested in isolation?
Or do they write concrete implementations with tons of dependencies that are impossible to test unless whole system is integrated?
If you know that requirements change and you create designs that are intolerant to change no PM model can save you from yourself.
Leveraging agile principles only helps when the software team knows how design.
You couldn't ask for help??
Team work is to me the most important part of agile.
In a real agile project, you would at the very least have been working in a pair and figuring this out together with your partner.
I think for working on small custom projects as some sort of custom software house these kinds of processes where you are more or less mindlessly churning out code to a specification blissfully lacking in any domain knowledge then these methods work fine.
However for everyone else the iterative (release often) approach seems to assert people are not smart enough to work complex problems over larger time scales and that they should not even try. Agile seems to assume the hit to even trying to arrive at a globally optimal solution is not worth taking. I disagree with this premise even in a general sense.
The problem for me is that features and quality exist in what might as well be an infinite well where it is impossible to ever get anything approaching everything that needs to get done done.
If you are not willing to invest the time and effort to design intelligent infustructure to deal with reality that you are fucked no matter what decision you make -- you are then left in an infinite reaction mode with crappy infustructure which at the end of the day is not globally optimal, boaring and likely to lead to crappy outcomes including code sprawl.
At my company, in my group, Agile is completely screwing us. The developers use the Sprint method, and each spring they invariably de-prioritize our small, simple feature so that they can work on bigger things. End result: our changes which require maybe 2-4 hours in actual work* get postponed for 8, 10, 12, or even more weeks. We miss deadlines for our clients, basically we get royally screwed.
Their "solution" to this problem was to split their team into multiple smaller teams, so now they have 3 Sprints instead of one. The reality is that our pending task is looked at by one single sprint, and they still de-prioritize it every two weeks like clockwork. (I mean, obviously-- it's the same people as before.) It didn't fix anything.
*) Before you gripe, I used to work in the exact dev group I'm talking about, and I *know* the tasks take 2-4 hours. I'm not pulling numbers out of my ass.
Comment of the year
Just right - and it will work "Being" Agile vs. "Doing" Agile We need to get rid of *The False Agile(r)* and *The False CSM(r)* mutant species. Otherwise, Agile will go to the trash bin together with other IT massive failures. Peace,
"Being" Agile vs. "Doing" Agile All we need is a organization certification strategy so that Agile can't be missued anymore. Otherwise - will die.
Then you're not doing Scrum.
The developers don't get to de-prioritise backlog items; they implement in the priority order defined by the product owner. That's the person they're creating the software for, so that's who decides what gets implemented. Of course, the developers can feed back that a particular item won't fit in a given sprint, but then it should only be delayed at most one sprint (assuming the user story is ready to implement (i.e. requirement-complete)).
Tell your product owner to do their job.
Then you should be programming in inline C++ templates. It gives you all the advantages of a near-metal-C-like programming with the harness/automation/coverage of an object-oriented language.
This is why WTL is superior over MFC in speed and size for the same API, as well as Boost, and why I write everything I can in meta-template programming and optimize the syntax to generate optimal assembly.
I've done a fixed class as so (and OpenGL/ES wrappers) and it runs optimally across x86, ARM, MIPS; exactly as I would have hand-coded it; and I get all the automatic optimization from being at the level where an optimizer also exists.
Then you aren't breaking the tasks down into small enough parts.
How do you incrementally rewrite a VM system?
-- Terry
The reason I imagine Agile is such a hit at the moment is that the managers are avocating its use, not the developers (at least at my work) purely because it is in the manager's interests to apply Agile methodology, and they are the ones who make the rules.
The idea is that managers get to satisfy the customer's whim with requirement changes throughout the process, and they get daily feedback with respect to progress in development. If things go bad, they blame the development team. Purely about managers looking good.
I think Agile only works within a team of crack developers that have the ability and discipline to design and write production ready code on the fly. For the average developer, the time pressures and changing requirements of each sprint tend to produce a piece of software that is cumbersome, messy, and difficult to maintain, as quick fixes and workarounds take precedence to redesign in order to satisfy the sprint deadline.
I believe this is typical of the short-sighted goal oriented corporations of today where they think it is good they will save 400 man-hours in this quarter by employing Agile to meet a delivery deadline, but don't realise they will end up paying significantly more over the longer term maintenance of the software due to the software's lack of a coherent design and implementation.
bill gates sold MSDOS to IBM before he even knew what MSDOS would be? or something like that. then he kept churning out all sorts of shit, windows 2.0, as long as it was 'good enough' , and fixing the problems later? im leaving out the parts about unethical business practices, which can be argued also helped a lot. but can one deny microsofts heritage, as a 'quick and dirty' company?
Yay! A fellow dBASE/xBase fan. Sure, the language had some ugly constructs, but there was something magical between the app language and table language integration: it was close and tight; the Batman and Robin of small-to-medium custom business apps and batch processing. SQL and app languages tend to have a wall between them in many "in" languages that makes them fairly verbose and cluttered.
Microsoft's LINQ and similar sub-languages have half-captured some of that magic, but in the rush to make everything OOP in the early 90's, the good lessons of native table-orientation got lost.
Microsoft Access makes a lot of things easy, at least up front, but meta programming and code re-use are difficult to do with mouse-centric techniques; and VBA + SQL has the same "wall" problem mentioned above.
Table-ized A.I.
Yay! A fellow dBASE/xBase fan. Sure, the language had some ugly constructs, but there was something magical between the app language and table language integration: it was close and tight; the Batman and Robin of small-to-medium custom business apps and batch processing. SQL and app languages tend to have a wall between them in many "in" languages that makes them fairly verbose and cluttered.
Microsoft's LINQ and similar sub-languages have half-captured some of that magic, but in the rush to make everything OOP in the early 90's, the good lessons of native table-orientation got lost.
Microsoft Access makes a lot of things easy, at least up front, but meta programming and code re-use are difficult to do with mouse-centric techniques; and VBA + SQL has the same "wall" problem mentioned above.
(I apologize if this shows up twice. Slashdot is acting up on me of late.)
Table-ized A.I.
How do you incrementally rewrite a VM system?
Start writing the virtual machine for the processor's predecessor, which will probably have a more limited set of instructions. Granted, the VM system its value per incremental release will probably not be that big. But it's still possible to go from working system to working system.
8 of 13 people found this answer helpful. Did you?
Having been involved in software from specification to coding to commissioning for 25 years, I can safely say that from the code quality perspective I've seen more crap code from self-styled agile developers than from any other source. It's not that agile is an inherently bad idea for certain areas of development - it's great for user interfaces where the client is unsure of their detailed requirements up front. But there are two major issues with it.
First, due to the lack of integrated up-front documentation, it's very hard to fulfil overarching requirements such as application security - one has to fall back on the expertise of individuals.
Second, and probably most importantly, the adoption of "agile" has been a way for thousands of deeply disorganised low-grade code monkeys to graduate into a development marketplace they could never have touched were systems analysis and documented requirements still an expected part of the package. So standards have gone down, not because the agile concept is fundamentally flawed, but because we use it where it's not the best approach and to do agile well you have to be a much better developer - and there aren't enough much better developers to go round.
If you want to create a maintainable design, you need to think of the likely changes the software will under go and the also the aspects that don't change.
Example: a car will a have brake, but the type of the brake is likely to change as technology evolves.
If you plan for the likely changes , you could hide every likely change behind an interface as implementation detail. The interface will only expose those details that are unlikely to change. So when the change does come along, this will results in one module implementation change.
By not planning for changes, Agile results in fragile architecture (a small change can have ripple effects ). And hence costly. We end up tweaking the architecture for every iteration?
yes I have also worked on hybrids where there was a traditional design phase and we did a rad style development phase in 8-10 weeks - with 2 developers new to the platform (oracle forms) and a good Oracle consultant who was the tech lead and mentor to me and the other developer.
Agile is just a buzzword made up by the business end to try to convince the programming end that hitting a moving target is efficient and better. That's the way the business end works; promise to satisfy whatever the client wants in whatever time frame nets the contract. There is no substitute for knowing exactly what you're trying to do before you start and no substitute for knowledgeable IT personnel in the contract process so that expectations and timeframes are reasonable.
Our move to agile development methodologies included firing all Business Analysts. We are now essentially defect-driven development. Thanks guys!