A Decade of Agile Programming — Has It Delivered? 395
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."
Maybe they did it wrong... (Score:5, Interesting)
Re:Maybe they did it wrong... (Score:5, Insightful)
In the end Fred Brooks got it right decades ago: "there is no silver bullet". Software development is just hard. Anything promising massive gains in success or effectiveness is snake oil.
Re:Maybe they did it wrong... (Score:5, Insightful)
The something is possible to define and explain but is typically different in different cases.
In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.
Re:Maybe they did it wrong... (Score:5, Insightful)
In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.
This is exactly one of the key points that the Agile community keep trying to drill into us! The Agile Manifesto explicitly states "Responding to change over following a plan", which is translated into the principle "Welcome changing requirements, even late in development."
Re:Maybe they did it wrong... (Score:5, Funny)
Shhh, we're talking about Agile. Put your logic away and break out the Bib^Wmanifesto.
Re:Maybe they did it wrong... (Score:5, Insightful)
To take a car analogy - using Agile is like using a GPS: it is a methodology that tells you were you are, and can adapt if you take a wrong turn or if you change the destination. Like the GPS, if you cannot make up your mind where you are going (or do follow the indication of the GPS gives - been there, ...) you will not get anywhere.
Re: (Score:3, Interesting)
it is a methodology that tells you were you are, and can adapt if you take a wrong turn or if you change the destination
If you constantly take wrongs turns, maybe you need a better driver. If you can't decide where you want to go, nothing can give you directions on how to get there. None of this relates to the effectiveness of the GPS device.
Translating this back out of the car analogy is left as an exercise to the reader.
Re: (Score:3, Insightful)
Straining the analogy to the limits you can mitigate a changing destination if you plan your route well. Most changes will not be of the "make a legal U-turn" variety, but rather "let's go to that other shop/restaurant in the same city." If you planned your route well and stick to major roads like motorways then these changes can be incorporated without massively disrupting the journey.
In programming terms that means building in flexibility where possible, normalising your databases and so on. If you are wr
Re: (Score:2)
If using a methodology where you start off with a design which firmly sets the requirements of the software, then changing requirements is something that simply won't happen.
Granted, it's not a perfect world so new things are bound to slip through, but that's often more a case of a manager forcing it down your throat, forcing you to deviate from the methodology rather than the methodology being incorrect.
Re: (Score:2)
If using a methodology where you start off with a design which firmly sets the requirements of the software, then changing requirements is something that simply won't happen.
Considering the developers are rarely the ones setting requirements, I don't see how you can say this. Even if you ask for a specific set of requirements, the actual end users' requirements may change during the time that it takes to write the app.
For example my current job is to replace a bunch of spreadsheets with a web app to keep track of various contracts that our sales team are working on, but they have several times added in some new sections to the spreadsheets which I then have to duplicate in the
Re:Maybe they did it wrong... (Score:5, Interesting)
Re:Maybe they did it wrong... (Score:5, Insightful)
I don't know enough about Agile to make a judgment myself, but you've practically said it yourself: your first experience wasn't Agile, it was just something that someone called 'Agile'.
Re:Maybe they did it wrong... (Score:5, Insightful)
Your post reminds me of a Muslim friend who told me once (dead seriously) that Muslims didn't attack the World Trade Center. They weren't REAL Muslims, you see.
Re:Maybe they did it wrong... (Score:5, Informative)
No true Scotsman fallacy:
http://en.wikipedia.org/wiki/No_true_Scotsman
Re: (Score:3, Interesting)
Yes, but does a Brazilian saying "I'm a Scotsman" make him a Scotsman?
Re: (Score:3, Insightful)
Firstly, I think Agile has delivered. The real problem is that most companies (people) have used the term, "agile" to mean I don't really have to have discipline because I'm being so agile. In my experience, management loves the "code done in two weeks" part, but they hate that the rest of it has to be done in two week increments part. In my opinion, Agile methodologies have had the least affect on developers. Most of the rest of IT is used to a leisurely pace where they have meetings for six mont
Re:Maybe they did it wrong... (Score:4, Insightful)
Well, there's a consistency there, then.
One of the basic tenets of Agile is that you don't use inexperienced people.
Much of the agility comes from the fact that your team consists of pros who don't have to hack so much as lay down code and keep going.
If you give someone a task for which they aren't trained, you're shoving logs under the bogies of your train. The whole thing will stop, but not all at once, and the spot where it starts stopping will be the least happy about it.
Re: (Score:2)
Somehow I get a feeling that this was mainly a problem with the employer, or the way they implemented agile programming.
Re: (Score:2)
My supervisor got the brilliant idea to implement Scrum ...
The only problem is that it's not Scrum. We meet every day and justify "yesterday." If you can't come up with arbitrary numbers to say you worked on something (not just your projects, you must include the 2 hours you spent helping someone with their project) for at least 6 hours you start getting questioned about what you did yesterday in front of the "team."
Re:Maybe they did it wrong... (Score:4, Insightful)
Uh, that's not Agile. Nearly everything you mentioned there is so anti-agile I can't even start breaking it down. Slapping an Agile tag on it doesn't make it agile. No mater what most companies think.
I have seen frequently referenced that the switch to agile takes up to 18 months to produce results. And even then there have been studies that find no significant enhancement in productivity.
As far as I can see there is no actual benefit in productivity at all moving to agile. It just gives greater clarity to the current state of development and should produce software with lower levels of faults through automated testing and continuous integration.
Re: (Score:2)
I might not know much about Agile methodology, but I do know one needs an agile approach.
Re:Maybe they did it wrong... (Score:5, Informative)
Well, yes and no.
There have been some developments since Brooks wrote No Silver Bullet that have helped by attacking the accidental complexity of software development - widespread use of garbage collection, for instance. But Brooks is still absolutely correct that the complexities of software have a lot more to do with the complexities of the human mental modeling, heuristics, and decisions that software replaces than they do with the challenge of converting that to something the computer can understand.
Re: (Score:2, Interesting)
+1 yes
Verily I say unto you, Agile is the development methodology of mystics. You don't fail or succeed on this basis alone. You also have to be not an idiot, and you must not have idiot managers and idiot customers. Agile doesn't prevent anybody from being these things. Nor does waterfall turn you into these things.
"You're doing it wrong" is a phrase you hear uttered by proponents of faith healing, psychics, homeopaths, practitioners of feng shui, gingers, etc when their particular brand of woowoo fails to
Re: (Score:2, Insightful)
You also have to be not an idiot, and you must not have idiot managers and idiot customers.
Therefore, it is always doomed to failure, since at least one of those will always be true.
The most successful model will be one that assumes all of those are going to be true.
Re: (Score:3, Interesting)
The reason it looks like magic is because it requires at least one person who Truly Gets It. It's easy to get business people to buy flash, because they cannot measure substance, nor can they differentiate between skill and luck with past experience.
For Agile methods to work, you need at least one person who sees the whole big picture, and given enough time and/or other good people to work with, could implement everything from scratch. Once you have that person and a commitment to make the project work, y
Indeed, THERE IS NO SILVER BULLET (Score:5, Insightful)
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.
Re: (Score:2)
Just to make the point that while there is no silver bullet you can get slight improvements.
Higher level languages help with complex tasks but in practice the complexity of the tasks just gets scaled up to the maximum possible, picking the right language for the job can mean the difference between development hell and a merely hard project.
Good planning and good organisation with some expereienced project managers probably has even more effect.
The thing is that no matter the improvements development will r
Frameworks = bad practice? (Score:2)
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 co
Re: (Score:3, Funny)
"getting the requirements out of a user is like sucking cock"
Your users must be a lot more fun than ours.
Re:Indeed, THERE IS NO SILVER BULLET (Score:5, Interesting)
"Question: When have you EVER switched database on a web application"
Earlier this year, because expenditure needed to be kept to a minimum during the recession starting in 2008 so the initial build used MySQL with the goal of moving to MS SQL Server when profit forecasts were a lot safer and more stable, which they were (and still are!) earlier this year.
"HOW easy was it?"
Effortless, precisely because I'd used database abstraction. It was done and tested in around 20 minutes thanks to the well written unit tests accompanying our abstraction layer demonstrating that the switch worked as required.
"Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same?"
Yes, I did, for this particular project, for precisely this reason.
"Then go stand in the corner, because your code lacks any optimization."
That's a rather broad statement, there's plenty of optimisation you can do even with just standard SQL, whilst you may lose some additional DBMS specific optimisation features, you may still be able to reach suitable levels of optimisation with ease-
"Real developers optimize their code for the specific environment they are using."
What was that about magic solutions? Optimisation is something you prioritise like everything else. If your application runs at no more than 10% CPU usage and the load isn't going to increase because the userbase is fairly static and this provides plenty of room for increases your application would be expected to see then it's far better to ensure your code is maintainble, than it is to sacrifice maintainability for unnecessary and time consuming optimisation and save the company money by focussing on the priority that best suits the task at hand. "Real developers" should recognise that they simply don't need to optimise at all if in the specific case they are considering it is an unnecesary task.
To use a typical Slashdot car analogy, even the car industry gets this, this is why not every car is in a fight to be the fastest in the world, car manufacturers understand that when a lot of people are limited to a set speed limit anyway, there's no point optimising the car beyond that point and ensuring other things, like having enough room for children to sit in the back, are a priority. The speed of the car just has to be good enough to fulfil the end user's needs not be able to reach speeds which the vehicle will never ever be pushed to in practice at an unnecessary and possibly unaffordable level of cost to the end user.
I actually agree with pretty much everything else you said, but your viewpoint seems a bit contradictory- on one hand you seem to be arguing the basic principle that it's all about using the right tool for the job, but on the other you then seem to be arguing against ways of doing things that are perfectly valid in some scenarios. If you hadn't taken a pop at database abstraction and insisted that all "real programmers" optimise their code then I find little fault with everything else you said. As it stands it sounds like you're saying "You should use the best tool for the job, except in a few cases where I don't like that tool". Sometimes database abstraction has value, sometimes optimisation doesn't.
Of course, there is always the exception (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
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.
There are no silver bullets, but there are lots of wheels out there - they don't need to be reinvented for every project. Question: How smart do you think it is to hire a coder who hates to use frameworks, and loves to roll his own for every new project?
We're ALWAYS doing it wrong (Score:3, Insightful)
Reminds me of an old poster [globalnerdy.com] from my CS department. It features legendary crotchety old fart John McCarthy [wikipedia.org] angrily looking at the camera, with the caption "Programming: You're Doing It Completely Wrong."
Re:Maybe they did it wrong... (Score:5, Interesting)
I fail to understand why that failing was related to the methodology?
"Due to changing demands"
It doesn't matter which methodology you use, if your goal is constantly changing you won't get anything finished, almost "by definition". If it wasn't that bad, maybe they weren't familiar enough with the methodology?
In fact, I'd say that agile software development methodologies work best for such projects, because they are aimed at constantly changing demands.
That's why almost all startups use agile software development, because *every* startup goes through a process like (very grossly, mind you):
1. search a business model
2. execute business model
3. realize 1) wasn't realistic, change it
4. goto 1
The transition process (usually referred to as pivoting) needs to occur *rapidly* and *continuously*, hence the agile software development.
Of course, if you keep changing the initial goal, you will never get finished, doesn't matter which methodology you use.
Re:Maybe they did it wrong... (Score:5, Insightful)
Agile principle #2 (from http://agilemanifesto.org/principles.html [agilemanifesto.org]): "Welcome changing requirements, even late in
development." Other methodologies typically draw a line in the sand to recognize the costs of changing requirements late in development. They don't often forbid crossing that line, but they encourage people to honestly evaluate the trade-offs involved in changing requirements.
Re: (Score:2)
I think maybe what some people are misunderstanding is that there is cost, explained to the customer as part of the process, for such changes. You see sometimes you absolutely need to change the requirements late in the development process; otherwise you finish the project but it doesn't do what the customer needs it to. Seriously, if you have a project and right near the end the customer tells you they were purchased and by fiat need to switch the networking protocol on which the app relies to comply with
Re: (Score:3, Interesting)
It all depends on the level of change as well. Agile, by design, is supposed to have constant product demos throughout the development process. The customers should always know what is being built, and the changes should come in little bits after each demo instead of a massive turnaround near the end.
I've done nothing but proper agile for years now, and even when it's done perfectly a massive about face on a project will kill pretty much anything....agile or not.
Agile tends to avoid game-changing changes at
Re: (Score:2)
Re: (Score:3, Insightful)
Software development requires Creativity, Discipline and many more things apart from Agile, and the process goes through lot of iterations, training, discussions and confidence building among developers to motivate them to follow process in the company. Also, the process to be adapted should be close to the type of Software company is focused on and what developers are comfortable with. Many process designers/implementers forget this fact and blindly throw something at them and expect results overnight and
Re: (Score:2)
Wow, that's a little harsh. ;-)
Re: (Score:2, Interesting)
Alright, I'll bite. What do you mean that you're doing it wrong. Agile is supposed to be many things but as long as you follow a few key ideas, it'll work better than waterfall.
1) Continuous delivery. Deliver something every two weeks.
2) Quickly fail. If a problem is found in a design or a project, find it early and save tons of money.
3) Small teams. No 80-person teams here.
4) Small tasks that you should accomplish quickly helping with visibility
5) Highly visible tasks and burndowns to help with "buy in" fr
Captain Obvious (Score:4, Insightful)
And in other news, despite potential pitfalls, the pope agrees that Catholicism has benefited religion overall.
"Agile", no -- "agile", yes (Score:5, Interesting)
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:
Re:"Agile", no -- "agile", yes (Score:5, Insightful)
The original Manifesto:
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
I think it is hard to disagree with the original statement. What is frustrating now, is that "Agile" degraded to a bunch of buzzwords and processes (SCRUM, XP, TDD, BDD, etc.) which it was going against originally. Of course it is more business in selling these (by consulting companies) than the vague "do what fits you best" statement.
Also, the problem is not with particular practices, or processes but the mindless, inflexible application of them to every project and team on earth. Teams are different, software are different, why should we all use the same processes then?
Re: (Score:2)
What is frustrating now, is that "Agile" degraded to a bunch of buzzwords and processes (SCRUM, XP, TDD, BDD, etc.) which it was going against originally.
Realistically, the original authors were never against buzzwords and processes. They were against the buzzwords and processes of the time. With experience, their new approach also yielded repeatable processes that needed their own new vocabulary. And that vocabulary gets called "buzzwords" by the next generation, and the cycle repeats forever.
Words are not evil. We assign names to things so that we can clearly communicate those concepts to other people. You can't be a professional in something and not
Re: (Score:2)
I think it is hard to disagree with the original statement.
I think it's idiotic. "Working software over comprehensive documentation"? Yeah, good luck debugging your undocumented code. And I hope your help desk personnel have fun if there is no FM to R.
"Individuals and interactions over processes and tools"? Any carpenter, electrician, or anyone else who makes things would laugh their asses off at that. Software about nothing BUT processes and tools.
For a software design aspect it makes sense, but not from a
Re: (Score:3, Interesting)
If you interpret the manifesto in the original context in its own age, you will understand that documentation means there not "developer documentation" or "user documentation" but the various "project documentation" artifacts that were the holy grail of that age.
The same is true for processes. It is not about the small scale ones (source control, review processes, whatever), but the overengineered project processes prevalent in that era.
Re: (Score:3, Interesting)
A related problem is that you don't look ahead and don't see the showstoppers until it's too late to avoid them. When you do, you often end up having to rewrite large parts of the code or implement major kludges.
At least with a traditional methodology, everything is reviewed for feasibility and risks before you invest too much time driving down the wrong path. And a change in scope means a forced review of how this affects everything else too.
But there are benefits to agile too, not the least of which is
Re: (Score:2)
Just because it takes 1 woman 9 months to have a baby, doesn't mean that you can put 9 women on the project and produce a baby in one month.
Every time I hear that one, I think pipelining.
Why don't they ask (Score:4, Insightful)
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...
Re: (Score:2)
Ironically, Ive done agile in small companies with small projects, and in huge companies with multi-hundred millions projects and thousands of people involved (using Scrum of Scrums for scaling), both software and non-software project... the multi-hundred million dollar non-software projects in many cases worked better than the software ones in Agile.
Kind of counter intuitive.
Re: (Score:2)
Every day, your life is effected directly by thousands (if not hundreds of thousands) of pieces of software written during the waterfall era. So it must not have stagnated the programming field *too* much.
Personally, I always thought "agile" sounds like a dodge--suspiciously like a bunch of business doublespeak being hawked by con men who are selling managers on the bullshit idea that they can have fast, quality programming on the cheap. At the end of the day, quality work still takes time, someone still ha
Re: (Score:2)
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.
You can substitute "waterfall" with "Agile" in the above, and it still makes exactly the same amount of sense.
A good measure of success is to look at what's actually out there. Discounting meta-products (like Agile developed systems to support Agile processes), I don't see Agile-developed software gaining a lot of ground. After 10 years or so, one would think that if it really was a lot better, at least half of all products out there would be Agile-based by now?
Of course, many successful products have bee
First decade? Not likely (Score:5, Interesting)
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.
Re: (Score:2)
Mod the parent up. I'd done agile within Waterfall for about a decade before 2001.
Prove it works in terms of ROI and... (Score:2)
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).
I think.. (Score:3, Insightful)
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).
Re: (Score:3, Insightful)
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.
Documentation is like code -- it doesn't work unless you do it right. An example is kubuntu's documentation. Pages and pages about how to customise the K menu, but not a single word about how to start the editing program. I had to have someone on slashdot to tell me you left click the K menu.
We
Re: (Score:2)
There's a picture on one of our cubical walls called something like the "sine wave of test automation" (can't find an online copy ATM). You start with heaps of manual testing, automate it and become more productive. But then a small change breaks heaps of tests, you end up with an aversion to change because of all the tests that would break.
The best documentation for what the application currently does, is the source code. Of course not everyone can read it. If you find yourself answering the same question
Re: (Score:2)
Where it works and where it does not. (Score:3, Interesting)
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.
Re: (Score:2)
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.
One should note that for pair programming environments and most Agile methodologies, this should never happen because there should have been many different people that developed each part of the code. If only one guy knows how something works, you probably did not follow an Agile development method.
Scrum is *not* a replacement for good management (Score:5, Interesting)
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.
Re: (Score:2)
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 (thi
Re: (Score:2)
"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.
Agile can work ... (Score:3, Insightful)
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.
Re: (Score:2)
I've run XP projects with average teams with great success. And my best successes were with new code. In fact I wouldn't run XP on a maintenance project initially because you usually don't have good test coverage. It takes forever to build up an environment where XP's advantages are visible. If you are trying to do it with an untrained team it's a recipe for disaster.
Now, I don't really think XP is "agile" in the way most people view "agile". XP is a highly structured discipline which requires an under
hrmmm (Score:2)
Works for us (Score:3, Informative)
I work in customer support for Agile Web Solutions [agile.ws], 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 [wikipedia.org].
As compared to other programming techniques? (Score:2)
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
Agile as a manifesto is a mistake. (Score:2)
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
Agile, scrum , extreme etc , its for managers... (Score:2)
...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 s
Re: (Score:2, Informative)
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 pe
Re: (Score:2)
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.
Agile - The fad (Score:3, Insightful)
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?"
Re: (Score:2)
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".
I do some work in an Agile shop and usability is a huge concern. It is very often that we tell the customer "we don't know what this should do, schedule our usability experts to go conduct some interviews with users and find out". In some cases they do just that. In others they decide it is too expensive so they just declare what they just take a guess at what users need and we build it. But you can be sure the customer knows they're making a tradeoff and reducing quality for the reduced cost.
Predictabel Comments (Score:2)
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
Agile Misinterpretations (Score:3, Insightful)
No... (Score:2)
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-stam
Agile-speak (Score:2)
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.
Bewar
Total failure from my experience (Score:2, Insightful)
It is never strict Waterfall vs. strict Agile (Score:3, Insightful)
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.
Re:A point of view (Score:5, Insightful)
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.
Re: (Score:2)
Exactly
Some people can only function with a pile of paper apparently.
Re:A point of view (Score:4, Insightful)
"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.
Re: (Score:2)
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.
Re: (Score:3, Insightful)
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/e [ogcio.gov.hk]
Re: (Score:3, Insightful)
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
All things turn to process in wide use (Score:3, Insightful)
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, her
Re:No (Score:4, Interesting)
From languages I've seen, programming has regressed in the last decade. When Grace Hopper wrote the first compiler, her dream was an english-like language that computers and people could both understand easily with a minimum of training. She co-wrote COBOL as the second compiler.
Older languages, like the mainframe DBMS NOMAD and the PC DBMS dBase were IMO brilliant. They needed little documentation, and no curly braces or other such nonsense you find in modern languages like C or Java.
The "language" I hate most is MS Access. Convoluted and unintuitive, you don't really write anything, and what's produced is "visual basic" and the equally unreadable SQL.
I hate it. I'd rather program in assembly, so I can know what registers are being accessed, whether I pushed or popped a stack (and which stack), etc.
I hate programming in a language that doesn't let me feel the metal. Hell, I'd tale old fashioned 1980 BASIC over the newer languages; it doesn't take long to learn not to write spagetti.
Re: (Score:3, Insightful)
This is pretty much the ultimate "get off my lawn" post.
Re:No (Score:4, Funny)
Old School here too. I do what I have to, to make a living. For fun, I program in FORTH and store my source code in 1K Screens represented as 16 lines of 64 characters each.
Simplicity and elegance is what I am looking for. A new Forth definition should be about 7 to 9 words long (not including noise like + - / ). If I somehow end up in a situation where I run out of room, It means I have used 15 lines for creating my definition. Which is another way of saying "Hey! your doing it wrong".
I think programming should be taught on an emulator of a Commodore64. Once you learn the computer from one end to the other and how to take advantage of all of it and understand all of its concepts, then you can move onto programming in a more abstract environment.
Re: (Score:3, Funny)
I think programming should be taught on an emulator of a Commodore64.
No, 64k is too much memory. Teach them on a TS-1000 emulator with its 4k or RAM. You learn to write really tight and fast code when you're programming in 4k on a chip that's only 1 mHz clock speed.
You took the word from my mouth. (Score:2, Insightful)
Re: (Score:3, Insightful)
Re: (Score:2)
Iterations should be on the order of a week or two, not 3 months.
Re: (Score:2)
I don't want to pair program with you either. See, we're all happy :-)
Some people can't pair program. Sometimes they are intimidated by having someone seeing what they are doing. Sometimes they don't understand how to do it effectively and are so caught up in their preconceived notions that it is impossible to teach them. Sometimes they are just nasty people that nobody wants to work with.
When I ran teams with pair programming I never forced people to do it. But our shop had a strict policy of no code
Re: (Score:2)
Taking the first item on the list is not always a good idea as some issues require specialised knowledge, not of code as such, but of theory. That should be assigned to a person who knows the domain. Unless you are willing to allow the time for an arbitrary dev to learn it.
And you will have specialists. However others can work on the code when there is some there to work on. But the specialist should own the code. Note the small 'o' on own there it should not be their private domain.
Re: (Score:2)
I bet those programmers would typically be the ones that get their Information Analysis right from the start. This allows systems to be flexible enough to change. As a result, these same programmers would be successful regardless of the presence of agile.
Likewise, there are developers that don't know how to design data structures/databases that are flexible to c
Re: (Score:3)
The two take away message I got from that was that working at Google is awesome and that the stupid blog poster can't understand why everyone doesn't work like they are at a cash rich company developing internal research projects without external clients setting the requirements.