Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 8 down vote favorite
1

Why go agile? This is the first question that comes to my mind when I think of going agile. What are the possible financial benefits one can achieve from going agile?

Most of us certainly like to think of customers and clients as someone who doesn't know what they wants. So why help them at all? Why not suck their money being a parasitic company and make them stupider by the day. Traditional software development isn't bad and are probably (mostly as far as I have seen) a lot easier environment to work in rather than agile projects.

So why go agile at all? What can agile give extra (I mean financially) that traditional software development can't?

share|improve this question
1  
+1 This is a good question. Agile proponents emphasize studies that agile is more efficient. It is taken for granted that people want to improve as professionals. But what if you don't care about that: what if you just want to make money? Is agile any good for that? – Joonas Pulakka Mar 8 '12 at 11:59
13  
You seem jaded like somebody who worked in an Agile-fall company, experienced the extreme dysfunction and then was told that was Agile. Most of us think we understand when we are starting out, and then we have more experienced people tell us the way it should be done. We were told this, but we never experienced why. Waterfall has a tendency for failure where true Agile has a tendency for success and until we experience both the failure of one and the success of the other we will never truly know. If you are thinking financial benefits then you already prove you that you misunderstand. – maple_shaft♦ Mar 8 '12 at 12:06
4  
Having Agile experience on your resume may provide monetary benefits to you. – jfrankcarr Mar 8 '12 at 14:49
3  
The problem is customers aren't stupid, and if you try to be parasitic, they'll eventually get to a point where they don't want to work with you anymore. And it won't be as long as you like. You want to be more efficent because you can bid lower than your competitor, which will get you more business. – Andy Mar 8 '12 at 16:07
1  
Somewhat Related Question: programmers.stackexchange.com/questions/125429/… – Chad Mar 8 '12 at 17:17
show 2 more comments

closed as not constructive by Jarrod Roberson, Yannis Rizos♦ Mar 9 '12 at 5:46

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

8 Answers

up vote 16 down vote accepted

Agile produces better results (closer to what the customer needs, not necessarily what he initially says he wants), in less time = money (or at least with more reliable estimates). It's simply a better way of conducting projects (compared to "waterfall"). Customers are happier. Programmers are happier. Projects are better. Communication is true and transparent. Life is good. What's not to like, in professional sense?

If you have good salesmen, you may be able to sell crap to your customers and charge them more. Financially, this makes sense. The reality is way more complicated than the gullible view "if you make customers happy, your sales will increase; if you disappoint them, your sales will decrease". The world is not a fair place. You can make a good living as an asshole parasite. Many do. It's your choice whether you want to be one. If you are, I won't play with you.

It's no trick to make a lot of money, if all you want to do is make a lot of money. ~ "Everett Sloane" in Citizen Kane

Also:

enter image description here

share|improve this answer
4  
+1 for the comic. I should send it to my boss. – Owe Jessen Mar 8 '12 at 13:12
4  
-1 I do not think that I agree with any of your first paragraph as a blanket statement. If you have crappy project and crappy management switching to an agile process is not going to suddenly make the team happy, the project great, or customers appreciate your efforts. – Chad Mar 8 '12 at 17:24
2  
Well, yeah, changing processes in the middle of a poorly-managed project might not make a difference for that project. Changing processes as a long-term strategy to better overall performance does. – DaveE Mar 8 '12 at 17:52
1  
-1: First I can't work out if the first paragraph is selling snake oil or silver bullets. It's about time this industry grew up and stopped this kind of crap. I do believe Agile is a better approach to software development than Waterfall, just not that much better. – mattnz Mar 8 '12 at 20:49
2  
mattnz - If you have well defined, well scoped requirements waterfall works perfectly. Agile works better in the real world at adjusting to scope creep and changing requirements. Sometimes a hammer works and other times a screwdriver is better. – Chad Mar 8 '12 at 21:19
show 3 more comments
up vote 8 down vote

I suspect that by "traditional" you mean some kind of waterfall workflow.

The monetary benefits are many. The man-hours required for an extra feature to be implemented is the main thing. You can't stop the process once you start it, hence, if the client is not happy with what they get (and being 'stupid' the client only cares to get his job done, so if your software doesn't do that job properly you will lose the client).

Another one is the guarantee of satisfaction of the client, which also leads to more sales and more happy clients (and we want that from a business perspective).

Having the ability to feedback the development cycle also means that you can adapt to technological improvements (for example asp.NET mvc 4 that is coming right now) which also save a lot of time. Having set a strict spec for the project you can't upgrade to a newer/better technology/library/asset that would also potentially save time.

Time is money.

share|improve this answer
1  
+1 for quicker feedback loop – maple_shaft♦ Mar 8 '12 at 12:00
i like your closing statement. +1 – Andrei G Mar 8 '12 at 13:03
2  
In my experience there is no absolute guarantee of client satisfaction. They sometimes want the impossible and will be unhappy nomatter how close you deliver. Also, they often fail to understand the gap between what they want and what they actually need. However, sequential development techniques are no better than agile in solving that problem. They are just better in defining in legal language up-front what you are going to deliver, and leave no room for the truly pathological client to weasel out of payment. – MadKeithV Mar 8 '12 at 13:20
2  
Haha yes the client will always want more, that's true. I do believe though that by constantly getting confirmation of things going in the right direction, the end product will at least be worth it's money. Then if the client needs more features etc, since he agreed that the product was ok (at the time) you can justify additional development costs. – Mihalis Bagos Mar 8 '12 at 13:54
My research leads me to believe that the time savings on feature implementation are actually lower. Its the getting to the RIGHT solution that is faster. – Chad Mar 8 '12 at 21:23
up vote 6 down vote

There is a demonstration I saw that is a pretty good analogy of the benefits of Agile over more traditional methods. It's based on the game Battleship. You and the other player sit down to the normal Battleship grid. You both have 20 shots, each costing $5,000 for a total initial expense of 100,000. Here's the catch; you have to plan ALL your shots before firing a single one. Your opponent will fire his shots "normally"; take a shot, see what happens, take another shot.

At the end of 20 shots, guess who scored more hits?

The analogy translates to Agile vs Waterfall pretty cleanly; In Agile, you are able to take the sum total of everything you have already done into account when planning what you're going to do next. You will have some basic idea of the areas that will be difficult and the areas that will be easy based on difficulties or lack of difficulty you have already experienced. You also have gotten feedback from your client in smaller chunks, stating that they liked this or didn't like that, and are able to incorporate that knowledge quickly, without having built a lot of additional code on top of something the client says is wrong.

In traditional Waterfall methodologies, the entire system and the development schedule is planned out before coding ever begins. This is the "plan all shots before firing one" approach; you may be able to deliver exactly what the client asked for, but they could take a look at it and say "that's not what we need". Yeah, you get your money because you delivered according to the terms of the contract, but your developers have wasted their time, your client has wasted their money, and neither are happy with the result. Agile is designed to help with this, by allowing the requirements of the project to change while development is underway. Anything you haven't done yet is open to change; anything you HAVE already done can also change, by adding additional stories to the backlog incorporating the amendments to the current product.

Also, because the client gets to decide what you work on first, and with you delivering small chunks of completed work more often, the client could conceivably have a system they can use sooner. That's visible ROI to your client, which usually makes the client more willing to buy in to this more involved development process.

share|improve this answer
Your analogy is quite flawed. To make the agile approach more analogous to Battleship, you would have to allow for your opponent to change the location of the ships after each iteration. Then your analogy would be more appropriate. – Dunk Mar 8 '12 at 22:43
Where did this myth come from that customers of waterfall developers are always unhappy and agile would have solved that problem? Sounds like too many people are drinking the kool-aid. – Dunk Mar 8 '12 at 22:45
Wasn't my analogy, and the idea is that even given a plan for what the client says they want, being able to reliably "hit" what they really want without feedback along the way is always going to be harder (and more expensive, as both the Agile and Waterfall guy will be expected to hit all their targets, but Waterfall will need more money for more rounds of development). – KeithS Mar 8 '12 at 22:48
Dunk, you and I have gone round the mulberry bush on Agile before. You don't like it. You don't think it works. There are many who would disagree, but the reality is that if you don't like Agile, feel free to continue with Waterfall. I guarantee you that you will end up adopting some of the ideas that Agile promotes (such as rapid customer feedback and what the customer wants done first) no matter what SDLC methodology you pick. – KeithS Mar 8 '12 at 22:52
I never said Agile doesn't work. However, it only works well for certain kinds of projects. And that is my objection. To an agilist, agile is the silver bullet. there is no such thing as failure to an agilist as long as you have one release. It doesn't matter if it doesn't meet the customer needs. As far as adopting some of the ideas that Agile promotes, that has already been done by successfull waterfall practicioners long before Agile was even conceived. So don't give agile credit for concepts that agile stole from the very processes that they then turn around and criticize. – Dunk Mar 16 '12 at 13:24
up vote 4 down vote

For me the benefit comes when doing fixed bid contracts. I've been able to win fix bid contracts and make an effective hourly rate that I would be ashamed to even speak by using agile methods. But it also requires a talented team that has gelled together to make it worthwhile.

You're right, it is easier to do a piss poor job, billing all along. Having worked in the industry for 16 years, I've seen my fair share of scandal. Especially during the dot-com boom. It's even possible to run the same scam, repeatedly getting away with it. But the same thing is possible in any industry. I've been scammed by car repair shops. Even the supposedly "reputable" ones. You hear stories practically every day about accountants embezzling from their clients, preachers stealing from their church, politicians taking bribes from big companies. And those are all classified as "white collar" crimes as if it makes it better. Oh they stole millions of dollars from their shareholders but it was a white collar crime.

There's nothing to stop you from taking advantage of people's trust and expectations. Personally, it's a matter of pride. I'd prefer to go to bed knowing that I exceeded the expectations of those I work with/for.

share|improve this answer
I gave you a +1 even though I'm not clear what you wrote. I think you said that the benefit of waterfall is for fixed bid contracts. Which is exactly my point. If I'm a customer, I want to know exactly what my money is buying. I don't want to pay millions and end up with half of what I need. As a customer, I would call that a failure. As an agilist, that would be called a success because they have a half-working program. Regardless of the fact that it is fairly useless to the customer in that state. – Dunk Mar 8 '12 at 22:49
Actually, I use agile for fixed-bid contracts. You get a good picture up front of what the client wants and plan out the project. Then use rapid iteration and delivery to get the feedback loop going. In the end if you do it right, you end up delivering more than what the client expected. – Mike Brown Mar 9 '12 at 13:53
Or you run out of money long before you give the customer the product that they need. You might have some important features, but that doesn't help much without the entire package. As I've said before, planes that can take-off but not land are not very useful. However, an agilist would call that a success. – Dunk Mar 15 '12 at 22:24
I would never call a project that results in an incomplete product success. – Mike Brown Mar 16 '12 at 13:59
up vote 2 down vote

Agile tackles the problem of how to "deliver" quality software with:

a) Changing requirements - even when the problem space is very clear, non-functional requirements like performance, security, compliance, etc can change core functionality.

b) Short delivery time frames - time to market is extremely critical so decisions have to be made on what is finished, and customers can expect to receive.

c) Fast changing technologies - changes in technology are so fast that it is difficult for projects to keep up.

d) Enhancements and Changing Market conditions - solutions have to evolve quickly evolve to meet changing market conditions, and add features to compete with other products.

share|improve this answer
1  
+! I think this is the best way to look at agile. As a tool in the box to deal with these issues. – Chad Mar 8 '12 at 17:19
up vote 1 down vote

Well, Agile is aimed at getting a finished product by an exact date.

Traditional waterfall if supposed to do the same, but often suffers due to scope creep not being managed properly.

Agile is supposed to better manage this into guiding the "business" into helping drive important features to be given higher priority and delivered first. The priority of items can change through the project as new information becomes available.

The benefit is that you deliver something more useful instead of being stuck continually missing deadlines.

share|improve this answer
As long as your customer doesn't mind getting a half finished product then your points are valid. – Dunk Mar 8 '12 at 22:51
@Dunk well yeah, that's the negative view. I view it from a "glass half full" point of view. They get the correct features first, with ability to change easily built in. – Ozz Mar 9 '12 at 9:10
As an engineer, it is my job to analyze all the risks and look at the big picture, not to bury my head in the sand and only look at the immediate task at hand and assume all that other stuff will work out just fine. That is not the negative view, that is a professional's view. If half a working system will meet the customer's needs then fine, agile might be the best approach, but for the kind of projects I work on that has never been the case. I also totally object with your "ability to change easily built in" comment since the ability to create software like that takes skill. – Dunk Mar 16 '12 at 13:31
@Dunk - oh right, you're professional and I'm not, whatever dude. Nowhere did I say the approach buries it's head in the sand. I'm not even an agile zealot, note the "supposed" in italics in my answer. Traditional Waterfall suffers exactly the same issues, either half finished, or ludicrously over budget. Both processes can work, both processes can fail, I've seen all happen. I was merely trying to answer the original question of how it "can" save money. Agile is NOT a golden bullet, nor a guarentee of success. – Ozz Mar 16 '12 at 14:33
@Dunk - I see your comments on other points. I agree there are many Agile zealots who see it as a silver bullet. I am not one of them, but I do think Agile has it's merits when done correctly with a mature team, and an engaged customer. I don't think the "plane" anology works well however. To build a plane, ALL reqs needs to be known up front. I don't think Agile would work well in that scenario. But for a lot of apps, maybe more commonly business apps where the customer has a wooly idea of what they want/need, and this changes over time, Agile works very well. – Ozz Mar 16 '12 at 14:35
show 1 more comment
up vote 0 down vote

That's a bit like asking what are the monetary benefits of eating breakfast or using source control. There are no direct benefits other than the fact you might be happier, more productive, able to deliver a better working product on time, or at least have more visibility into why you are not.

share|improve this answer
-1 While this may not be incorrect it does not help the OP. This could have been a comment – Chad Mar 8 '12 at 17:16
up vote 0 down vote

If creating better software doesn't make you more money, you have a business problem and not a development methodology problem.

Why not suck his money being a parasitic company and make him stupider by the day.

Why not provide an actual benefit to the company where they make the connection from your services to their profitability?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.