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.
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.
The original manifesto's key message was "people over processes" which I still agree with. On the other hand the word "Agile" now means just as many processes as waterfall or RUP meant in the past. Shame.
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:
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).
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
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
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.
Exactly
Some people can only function with a pile of paper apparently.
how long until
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
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)
"People over process" is an important tenet in more ways than one, and not only in IT. Often, this message is taken to mean that teams and individuals are given more freedom to organise their own work, and are managed on outcome rather than activities. This is true in some ways, but it's more than that.
"People over process" to me also means acknowledging the value of each individual's skills and abilities. That starts with resourcing: instead of posting jobs for "2 junior programmers, 1 senior programmer, 1 encryption specialist (part time) and 1 PM", one would think "Together, Alice and Bob are up to the task of writing this module, Alice knows enough about encryption to cover that part of the job, and Bob is a good team lead". No two people are alike, and if you value people, that means that you account for their differences as well. Yes, it also means that if Alice calls in sick, you have a problem on your hand, but it's by no means an insurmountable problem.
And it goes beyond that. "People over process" to me also means that you let people do what they are good at beyond the call of their assignment. (as long as it benefits the company). As an individual, it means that you sometimes take responsibility for stuff that is not strictly your job. If someone contacts me with a problem I can solve, I do not answer with "Contact the helpdesk"... if it's likely the problem will get kicked down 3 layers, taking 2 weeks to come up with a non-answer. Instead I will take an hour off my regular work to provide a helpful answer (of course with the suggestion that they contact the helpdesk, and copying in support as well). This helps everyone, including the company.
Yes, accounting for individual differences makes budgeting, resourcing, managing continuity, and people management a lot harder. That's why managers hate "people over process" and why Agile IT gets loaded down with more process: resources are so much easier to manage than people.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
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.
The original manifesto's key message was "people over processes" which I still agree with.
I read the summary's links and never saw anything concrete, just marketing buzzwords. But "people over processes?" That makes no sense at all on the programming end; in the end it's all processes.
"People over process" makes sense from a design point of view, but not the nuts and bolts of programming itself, any more than "people over processes" makes sence when engineering an automobile engine.
Free Martian Whores!
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?"
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.
If you read the original manifesto, it is very carefully worded. It does not say "abandon processes", it says that the priority should be on the developers as creative individuals, instead of mechanized drones.
Also, it is not against "processes" (with small "p"). A build system is itself a process, a source control software also enforces a process. The manifesto is against Process with a capital P. It is hard to explain, but easy to give an example what I mean about this:
http://www.ogcio.gov.hk/eng/prodev/es3.htm
The above link is about the SSADM Process. Read it and you will immediately understand what I mean.
Also, lot of people misunderstand "Working code over documentation" and think that documentation is not important. In fact, it should be read primarily as "project documentation", the things that most old fashioned processes mandate. Again, look how many and what kind of docs SSADM needs.
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.
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
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.
Also, it is not against "processes" (with small "p"). A build system is itself a process, a source control software also enforces a process. The manifesto is against Process with a capital P. It is hard to explain
I don't think its really hard to explain, though I think the best explanations I've seen are in books that focus on "lean" methods rather than "agile" ones (which, really, aren't all that different; the principles are largely similar, though "lean" seems to focus on an enterprise wide approach that lean software development applies to software development, while "agile" seems to focus on software development with applications to the broader enterprise particularly the interface between software development and business):
It is important to have clear processes that people follow, because otherwise you have wasteful churn as extra effort is spent doing everything ad hoc. But you have to respect the people doing the work to the point where they are expected, on encountering a problem with the existing process, to call a halt, propose and test an alternative, and then that alternative, if it is an improvement, is adopted as the new process.
That is, just as software being developed needs to be developed in small increments and able to respond to emergent discovery of requirements, so the processes used in software development (and, really, throughout the enterprise) need to be able to be adapted rapidly in response to emergent requirements. And, to do that, the people that do the work have to own the processes by which the work is done.
This is opposed to devotion to enshrined Processes that are treated as received wisdom and not subject to question or revision by the people actually involved in doing the work.
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!
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.
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.
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.
A very astute set of observations, showing that the poster of the above actually understands this aspect of agile development. However, you are incorrect about one thing: That's why managers hate "people over process" and why Agile IT gets loaded down with more process: resources are so much easier to manage than people.
As a manager, I disagree - this mindset might be true among some managers, but not all of us. I find people a lot easier to manage if you treat them as people and not as resources. In fact, assuming you've done your hiring and training correctly, most teams end up being "self managing" after a while with the only thing you need to deal with are occasional corrections and helping to set priorities (and, of course, managing your team's face to the rest of the organization, getting physical resources, etc.). That's a lot easier than having to go over a bunch of paper each day making sure that every "i" is dotted and every "t" is crossed for some arbitrary process. However, it does make it more critical to hire the right people - look for flexibility and intelligence rather than for a code monkey and you'll be on the right track. And, I'll almost always take a generalist over a specialist. That being said, I wouldn't pass on process in some places - but, thankfully, most of us are not working in avionics, health care devices, or nuclear power station control systems (to name a few).
That is all.
Agreed but... you should be able to:
- Plan for fairly frequent milestones where you can build a release (that runs with bugs but it has something to show of how the system will work when completed).
- Be able to test new and old functionality by being consistent in building useful unit tests.
- Be able to say what you will be doing in the next couple weeks (or months even) and somehow you are able to deliver on that.
In essence having a loop where you at least touch with some new code most of the functional areas of the system.
Otherwise you might say "the database layer is complete but I can't show you until the business layer is done and that will be probably done in six months..."
Management will go nuts trying to figure out what to tell their bosses while still justifying the expenditure with nothing to show for in months and months!
OO fiasco? So go back to procedural code?
Well, you are the manager I haven't meet in years and I wonder - are you for real, or just a developer who's wish is his manager would be this way :-) LOL ?!
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
Sure it does. It's simply an acknowledgment that we don't know how to define "the process" well enough to actually accomplish any of those tasks procedurally (if you disagree, code it up and let the computer design the engine by itself!)
Having acknowledged that, we can either use procedure where it helps (and there are such places) as determined by people (that is, "people over process") or we can let it prevent the achievement of the objective.
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?
well the agile development seeks to drop the dirty part and keep on with the quick one.
Read radical news here
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?
Without processes your people have nothing useful to do and your entire business model is suspect. Processes MUST come first. People can be inserted or removed as needed.
---- Booth was a patriot ----
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.