Summary
In an audio interview on developerWorks, Scott Ambler takes aim at several common notions about agile methodologies that he considers myths.
Advertisement
In Scott Ambler on Agile development, Scott Ambler attempts to answer objections commonly made by critics of agile methodologies. To the perception that agile developers never write any documentation, Ambler comments:
Yes, we do write documentation, but we treat it like a requirement. And we ask people to estimate the cost. We make the cost explicit. It's amazing what happens when you say, oh, you want that document? Great. It's going to cost us $50,000 of your hard earned money to produce that document. And when you say things like that, the very next question is 50,000? Are you kidding? What can I get for 10,000? And you start negotiating from there. Or they say, oh, I didn't know I actually had to pay for that. Forget it, we don't need it. So it really sort of makes things smarter. It really motivates you to write very tight and concise documentation.
One of the things that agilists do is document stable concepts and not speculative concepts. We don't write as much documentation up front because that information is going to change. Putting it down on paper isn't that good of an investment in your time. It's just sort of crazy. So we really force people to think and justify why they want the documentation. As a result we do less.
On the charge that agile development is undisciplined, Ambler replies:
Completely false. I would argue traditional development is undisciplined. There's a lot of paper pushing and bureaucracy going on in the traditional world, but that's not discipline. It requires great discipline to do test first development or to do just enough work and then to move on and do something else, and to stay focused on high-value activities. Yes, that's just false.
On the perception that iterative development means that no planning is involved, Ambler states:
...We'll do a little bit of planning up front, because you've got to identify your main milestones and the major dependencies that you have other teams because you've got to manage to that. But we do just in time planning. We also do self-organizing teams. Developers are smart people. They know how to do their jobs. They know how to organize their work. They don't need some manager to come along and produce this detailed Gantt chart thing, you know, for this four hours today you're going to be doing this—because you know what? The developers ignore that sort of stuff anyway. They do the right thing when they're allowed to.
So we recognize the fact that people can pretty much figure out how to do their own work. And as a result we do a lot less planning. We do enough planning to get the job done. That's about it.
On the charge that agile development is not predictable, Ambler says:
Well, traditional development is not predictable. Well, actually, I guess it is: I can predict you're more than likely going to be late. You're more than likely going to be over budget, and you're more than likely going to produce software that doesn't meet the real needs of your users. So if that's your goal, then, yes, do the traditional stuff. But I can predict that if you're truly doing Agile you're going to be writing high-quality software. You're going to be doing stuff that provides the greatest ROI to your stakeholders as they define it. I can predict that you're going to meet the schedule as your stakeholders choose to set it. So this is far more predictable.
Now, can I predict up front how much money you're going to spend? No. All I can do is predict you're going to spend it really wisely. Can I predict exactly what you're going to build up front? No, but I can predict you're going to build the highest-value stuff. So I think that's the level of predictability that I would prefer to have.
Lastly, on the charge that agile methodologies don't scale to large teams, or geographically dispersed teams, Ambler responds:
Yes, that's also a misnomer. Now, to be fair, a lot of the Agile literature does focus on small co-located teams. But the reality is the Eclipse project is an Agile project, and that's hundreds of developers worldwide working on a complex system. And they've been meeting their dates for years now.
What's your opinion on Ambler's responses to the agile critics?
Scott is right for the most part. Agile movement is definitely on the right track. This is not surprising - when you read Alexander's "The Timeless Way of Building", that's exactly what he's talking about (besides patterns) - agile development. However, it is my feeling that both communities (software patterns and agile development) have missed that aspect so far. Patterns and agile make sense only when applied together.
There are few points where I'd slightly disagree with Scott. I don't think the best way to communicate is to put together a bunch of people with a whiteboard. Whoever disagrees should read "Dreaming in Code" and then re-think. I personally think best when I'm alone. Joel Spolsky agrees on that:
"I can’t tell you how many times I’ve been in a meeting with even one or two other programmers, trying to figure out how something should work, and we’re just not getting anywhere. So I go off in my office and take out a piece of paper and figure it out. The very act of interacting with a second person was keeping me from concentrating enough to design the dang feature."
To me, the best way to communicate my ideas to peers is through code. Programming is design activity and programming language is design tool (Jack Reeves stated this long time ago, see http://www.developerdotstar.com/mag/articles/reeves_design_main.html ). When I write code and share that code with peers, it is at once exposed to all the constraints it should be exposed to, in order to be shaped properly: language/compiler, environment, tests (if you're doing TDD, which you should) and, last but not least, intelligent human judgment.
While I'm not sure I buy into every part of Agile, I feel that this is right on the money about traditional development:
"You're more than likely going to be over budget, and you're more than likely going to produce software that doesn't meet the real needs of your users"
In the shop I am in now, we produce more paper than code. How does one go about affecting a change like going from a bureaucracy to something more efficient. It seems to me that bureaucracy tends to feed on itself. How do you cut the legs off of it? Can you make the change in small steps or does it have to be a clean break?
"There are few points where I'd slightly disagree with Scott. I don't think the best way to communicate is to put together a bunch of people with a whiteboard."
There's a time for gathering around the whiteboard and a time for thinking alone. The whiteboard should be used as a last resort for solving a hard problem via group brainstorming or as a final step in checking the details of a solution and ensuring everyone understands.
As a general rule, meetings should always be well defined and structured. For example, if your goal is to have a prioritized list of requirements, you should start the meeting with a good list of requirements that everyone has already seen with preliminary priorities assigned and decent structure and formatting already established.
Otherwise the meeting degenerates into meaningless blathering where the most obnoxious person "wins" the discussion and dooms you to repeat it next week.
I certainly agree that documentation has a cost and that cost should be taken into consideration in the budget or proposal, but that doesn't mean that all documentation is an optional feature you can negotiate away.
Unless, of course, your model is to make everything negotiable regardless of value (e.g. you want unit testing? That's going to cost you an extra $10,000).
Clearly if you want to produce a quality product there's going to be a core set of activities that aren't going to appear as optional bullet items.
Generally, saying "I'm not anti-practice X but I make the customer pay extra for it" isn't a valid defense in my view.
It's amazing that someone can get away with allegations like documentation is "going to cost us $50,000" and "Forget it, we don't need it". Of course, good documentation costs nothing, at least for larger projects. It usually amortizes within the development project, not to speak of maintainance. Moreover, when he claims that "we do just in time planning. We also do self-organizing teams" I know I need not read any further.
"Developers are smart people. They know how to do their jobs. They know how to organize their work. They don't need some manager to come along and produce this detailed Gantt chart thing..."
We can't just assume that! Not all developers are smart people. In fact the most part is mediocre and that's a fact! And a good process is about leading this developers to produce something with quality too.
Bill Venners wrote What's your opinion on Ambler's responses to the agile critics?
Was it a response to specific comments made by particular people (agile critics) or a convenient list of strawmen?
Seems a bit like those FAQs which turn out to be a list of things the website owners want to tell you rather than a list of things you might have asked.
> Bill Venners wrote What's your opinion on Ambler's > responses to the agile critics? > > Was it a response to specific comments made by particular > people (agile critics) or a convenient list of strawmen? >
That was my sense as well.
One of the problems with discussing some of these recent methodolgies is that nobody "owns" them and there's no offical description of them. So if you question something you heard about it, you're often told "No, we don't do it that way".
This can lead to the Bob Jones/NAACP scenario where proponents can sell it to developers by telling them something they want to hear "No documentation!", but can say to critics "We're not against documentation".
Saying that you do documentation and then putting artificial barriers in the way of producing said documentation is that kind of double-talk that continues to give 'extreme' programming a bad name and hinder its general acceptance.
As to always meeting deadlines; Any fool can meet a deadline when there's no definition of what is going to be delivered. This may be fine for the likes of IBM's eclipse project - where any such deadlines are artificial anyway - but I don't recommend it as a strategy for instilling customer confidence in a commercial project where other people need to know what will be delivered and when so that they too can make plans.
> Saying that you do documentation and then putting > artificial barriers in the way of producing said > documentation is that kind of double-talk that continues > to give 'extreme' programming a bad name and hinder its > general acceptance.
What is artificial about the barrier? If he said, "This documentation you describe will require so many developers so much time" and let the customer calculate the cost, then what's the difference?
> As to always meeting deadlines; Any fool can meet a > deadline when there's no definition of what is going to be > delivered. This may be fine for the likes of IBM's > eclipse project - where any such deadlines are artificial > anyway - but I don't recommend it as a strategy for > instilling customer confidence in a commercial project > where other people need to know what will be delivered and > when so that they too can make plans.
That's true. The bottom line is that we need the ability to control the timing of development's completion, but no one knows of a process which can provide that.
> > Saying that you do documentation and then putting > > artificial barriers in the way of producing said > > documentation is that kind of double-talk that > continues > > to give 'extreme' programming a bad name and hinder its > > general acceptance. > > What is artificial about the barrier? If he said, "This > documentation you describe will require so many developers > so much time" and let the customer calculate the cost, > then what's the difference?
When evaluating a methodology the question isn't what extra work you might do to satisfy a particular customer, but what the methodology states is it's position on the matter (Note also that this is different from what Scott Ambler or Joe Agile says they personally do).
Could a developer using a traditional, non-agile approach credibly claim that although their method doesn't require writing tests before code, their not anti-TDD because they'll do it if their customer wants to pay extra for it?
Such an interpretation essentially leads one to the conclusion that all methodologies are the same so there's no point in adopting a new one.
Maybe my current situation is not common but for some of our development approaches, we produce documentation that is almost as detailed as the code itself. Combining that with the fact that it almost always needs to be changed to keep in sync with the actual code, I figure we spend more money on documentation than we do on producing tangible results. The customers did not ask for this and could care less about it. We do it for ourselves. So from my perspective the question about documentation is more about getting the most value at the least cost.
> That's true. The bottom line is that we need the ability > to control the timing of development's completion, but no > one knows of a process which can provide that.
That's easy. Set a completion date, collect the requirements and determine the resources. Then you create an arbitrary estimate that fits those constraints. But be proactive and pick out your patsies early so you won't be struggling to find someone to blame when you are put on the spot.
Flat View: This topic has 21 replies
on 2 pages
[
12
|
»
]
Previous Topic
