Our very own Steve Eichert recently posted on the skeptics' view of agile. It has taken a while, but I have compiled responses to each of the original concerns, in order.
Too disorganized
I’ve always been a little leery about using XP to manage projects. To me, XP is much more of a development-focused methodology. Scrum, on the other hand, is well-suited to handling the business side of things. There is even an XP @ Scrum (Scrum with XP) methodology that uses Scrum for management and XP for development. If you present Scrum to business managers, it is very clear, consistent, and well-organized. It also requires significant discipline on the part of everyone, so that should dispel any doubts about disorganization.
How does the customer really make out any better?
I must defer to Ron Jeffries’ excellent article Take a Card, Any Card. This excerpt should explain how the customer does make out better.
Pick up a deck of playing cards. Value the Aces low, at one point, and the Kings high, at 13. Now lets do some project management.
Think of the 52 cards as representing the 52 features you want in your next project. And suppose that, like most projects, you want the product in six months, but your programmers can only do about one feature a week. There are 364 points of value in your project, and the project is going to take a year to get all those points.
What will happen at six months? Well, if your programmers work as many do, there won't be anything useful implemented in six months. Even if they could ship something in six months, it will probably only have half the value, or about 180 points. That's not very good. We need a better deal.
What if you didn't have to ship randomly? What if you could ship any 26 cards: what's your possible score then? It's 266! That's right, you can ship 266 points out of 364 in the first six months!
What if software development could be like that? Almost three-fourths of the value in half the time? Well, software development can be like that.
Won’t it cost the customer more? How can we really control and manage changes in this environment? Won't we just be going back over and over to change what we've already done?
If you look at the card example, the same amount of stuff (the value of the cards) is completed in the same amount of time (1 year). That doesn’t cost the customer any more, and in fact allows them to start using the most useful parts of the application (the higher value cards) first.
The way to control and manage change is through discipline. Most people think agile means little or no discipline, but to be able to pull off things like daily builds and 100 percent automated unit test code coverage take a lot of discipline. There will have to be a configuration management/change control process in place and it will have to be followed. If a decent process is in place, then things will work. Otherwise, they won’t.
Perhaps the last complaint, about redoing stuff, is the real issue. As both part of Scrum and XP, during the planning stages the developers estimate how long each story or feature or whatever will take. This estimating is not done with the tasks isolated. There is always the opportunity to do things several ways. Say feature X is estimated at 3 days and feature Y is estimated at 2 days. The customer wants to do X, but X would be much easier to do if Y was done. So the developer would change the estimate to do features X and Y in 4 days, instead of 5. The customer can then make an informed decision on whether the extra effort (1 day) is worth it to get both X and Y. The key to the whole process is that the user, who has the most information about the value to the business, makes the decision given as much information as possible.
Will the developers go back in and change things? Perhaps. But wouldn’t the business user prefer to wait until they are sure they need to go back in and change things before actually committing to do it?
Do you need to have Attention Deficit Disorder (ADD) to be a fit with agile?
No.
It's too difficult to sell that type of process to clients.
This sort of objection is pulled out when other objections fail. It is kind of like telling someone not to do something because it is “unprofessional.” All you are really saying is that you have not tried yet.
Our clients won't want to have that level of responsibility, they just want to hand us a document describing what they want and have us come back in 3 months with a finished “product”. Our clients our too busy with other things, they won't be able to give us the time and energy needed.
Some customers may decide to go the agile approach, others may not. It is really up to the customer to decide. If the customer does decide to try an agile approach, they must abide by the rights and responsibilities. Either way, the development team can still use it internally. Or, if you are sufficiently well off, you can turn down the work.
So what happens to our QA staff?
Brian Marick has written an excellent series of articles on agile testing. Read his weblog and some of his writing to see where he is taking the idea of testers/QA staff.
I think that there will still be testers available to help the programmers and the business customers write good, accurate tests.
So if a client has the ability to end a project after an iteration, how do we schedule resources and forecast revenues? Doesn't that add a lot of risk and uncertainty?
Technically, you cannot schedule/forecast with 100 percent certainty. The problem is that scheduling and forecasting will no longer have the “crutch” of fixed-scope fixed-length contracts. This is a standard staffing problem, and seasonal jobs offer some interesting possibilities. Another possible response is to make sure that there is sufficient work in the “hopper” so that there is always more work. And if there is a regular sizable backlog of work in the hopper, then it is time to hire more people.
Short iterations work against a lot of current management practices. For example, discounting initial work to get a customer could result in that customer getting a bunch of quality work done for cheap, and then taking their business to the next low bidder. The easiest way to avoid this is to avoid making the initial discount. I think, and a small amount of experience has proven me right so far (I am not making any definitive claims yet), is that this type of arrangement will self-select customers that want a relationship. According to Crossing the Chasm, the pragmatists want a single supplier anyway, so once you have proven you worth, they will stick around. And these are the kinds of customers with money that you want (compared to the visionaries).
Certainly there is some risk and uncertainty. I believe the risk is nullified by the elimination of fixed-price contracts that go over budget and leave the development organization eating the cost. The customer also wins by avoiding situations where the fixed-price contract covered 2 weeks worth of work that was finished in 2 days! This can go a long way toward crossing the divide between the business people and the technical people.
See The Predictability Paradox, by Mary Poppendieck.
Sounds too risky? Waterfall is much more conservative and stable, I like stability.
You are trying to equate stability with a desire not to change. Waterfall may seem to be conservative and stable, but in reality it fails to meet the customer’s needs the majority of the time. You can run and hide behind your contract, saying that the customer signed off on it and you built it exactly according to spec. I know where the customer is going to tell you to put that spec. And in the long run, customers will eventually gravitate toward those companies that deliver results faster.
It all depends on the nature of the project. If the requirements are going to change very little between the beginning of the requirements definition phase and final delivery (including bug fixes), then sure, waterfall is great. But if not, which is usually the case, then sorry but it ain’t gonna cut it.
Don't resources need to be able to do everything? Isn't it hard to find people like that?
First of all, people are not resources. They are people. You cannot substitute one person for another in software development. Joel Spolsky notes, “Programmers are not interchangeable. It takes seven times longer for John to fix Rita's bug than for Rita to fix Rita's bug. And if you try to put your UI programmer on a WinSock problem, she'll stall and waste a week getting up to speed on WinSock programming.” And yes, they need to understand a little bit about a broad range of things, and know a few things in extreme depth. Today’s business world is moving toward generalizing specialists.
Second, yes it is hard to find people like that. There are not many good developers out there. So if you want to hire mediocre people paid a decent US wage and hope to compete with good offshore developers paid a small US wage, good luck. Please email me your company’s stock ticker so I can short it. Also, agile development has only been proven to work with good developers. Do not try it if you are staffed with average developers. That is what a heavy methodology is for (bringing all projects to the same level of underperformance). Only try agile if you want good-to-great performance and are willing to pay for it with hard work, discipline, and giving your developers room to work.
How do you know when you’re done?
When the customer says you are done. However, according to the Secrets of Consulting, there will always be a #2 problem that you should promote immediately after you fix the #1 problem. It all depends on how good you are at marketing.
How do you handle changes in scope? I know it’s embraced but how do you actually manage all the changes?
In Scrum, the customer is not allowed to change the work for the current sprint. The same for XP. The customer can make small changes, clarifying current requirements, but no big ones. The reason is since you are delivering in a couple of weeks to a month at most (Scrum sprints are 30 days), then the customer can wait that long. This rule also prevents the “requirement of the day” syndrome, where someone gets a brilliant idea that just HAS to be in the product. Two weeks later at the beginning of the next iteration, the idea will still be around if it is good (or if the idea’s sponsor is tenacious) or will have quietly faded away if it was bad.
Technically you could allow the customer to make a 180-degree turn. You just get yourself to a stable code state and then end the iteration. This is like slamming on the brakes while going 55 mph (88 km/hr). The customer is going to pay for it since it will take a while to get back up to speed. This is not recommended except for extenuating circumstances.
Customers will want more documentation.
Customers usually ask for documentation because they’ve been left holding the bag before. Politely tell the customer that you need very little documentation to support development and there are too many problems with documentation. If the customer wants more documentation, make it an XP user story or use case, and let the customer decide how to prioritize it. After all, it’s their money.
Concluding Remarks
One of the best overviews of agile methodologies, especially suited to business managers, is Martin Fowler’s The New Methodology. You probably know most of this stuff already, but Martin brings up important customer and management points which will help you sell agile.