Context: (From a discussion on the Agile Modeling list.)
- [XP] does not [directly] address all kinds of specialized techniques. XP trusts that teams will notice that they need specialized techniques, and arrange to get them. It makes sure that they can notice, by having so much feedback so often.
- Ron, I'm interested how this works. I'm assuming by specialised techniques here you include those from the development domain as well as the problem subject matter. If so, how does feedback help a developer notice that e.g. mathematical proof might be a valid specialised technique for a project if they'd never come across it before?
Feedback is Illumination, not Solution
Feedback doesn’t provide solutions, it illuminates problems. Feedback might say “Hmm, no matter how much we test this kind of code, we still get these kinds of defects. We’re not satisfied with our results, therefore we need to do something in addition.”
Feedback tells you when your current steering isn’t keeping you on the road. It doesn’t tell you what to do next. In my quote above, I said “XP trusts that the team will notice”, and I used the word “trusts” advisedly.
Trust vs Control
To somewhat overstate my point: XP and the agile methods are about trust, the heavy methods are about imposed control. I’ll sketch a bit of detail:
XP is a minimalist kind of process, by design. It says that if you do “just these few things” things you will have enough information to be able to steer a wide range of projects.
The RUP or the CMM are exactly the reverse. They are maximalist kinds of process. They provide a complete menu of techniques, from which you are supposed to select a subset.
Again: this is an overstatement to highlight a distinction that is not so clear in the wild. But I think there’s a valid point here: Agile methods try to steer from within; heavy methods try to control from without.
XP and Technique
XP is not a degree in computer science or software engineering. If you have such a degree, you can do better than if you are a beginner. (At least those of us with such degrees hope so.) However, even a beginner using XP can tell when he’s off track. We trust that he’ll figure out what to do about it, up to and including getting help.
The XP books do, of course, describe techniques. There are a number of reasons why they do that. I’ll list a few here, in decreasing order of XP-relatedness.
- Show how simply we really mean for you to start;
- Give examples of how to vary practices within the "XP spirit";
- Give examples of how to supplant practices that may be too heavy;
- Show off how smart we are.
Specific Method or Process Framework
XP is described as if it were a specific instance, and its authors expect that you’ll customize it to make your own specific method. XP authors recommend that you start with pure XP. No one does, of course.
Scrum is scarcely described at all. Its authors are now pushing “XBreed”, a combination of Scrum planning and XP execution. Scrum itself can be described as a planning method with most everything else left open.
Alistair Cockburn’s Crystal is a more explicit process framework, dimensioning projects by size, criticality, and project priorities such as productivity or minimization of legal liability. Alistair begins the process of identifying which practices one might choose depending on where one is in the matrix.
The RUP and CMM are by design process frameworks, from which you are expected to create an instance. They list every conceivable “best practice”. You are supposed to pick the ones you need, but the process doesn’t provide feedback that will tell you if you have picked the wrong combination.
Selecting a Technique
So how do you select “mathematical proof”? Generally in these ways:
- You are told by some leader to do it, or
- You have studied the technique and at some point you decide to try it.
How do you know when to select mathematical proof? Generally in these ways:
- Motivated by fear, you rule it in to your process as a matter of course, or
- Motivated by need, you bring it in when nothing less seems to be working.
Waiting for Need is Dangerous
But hey! Isn’t it awfully risky to wait until a need is shown? Well, it could be, but I suggest that usually it might not be as dangerous as we fear. Suppose your process happens to throw off very accurate quality information without killing people in the process. Then you can use your quality measures safely and install additional techniques late in the process.
If you do not have accurate quality information coming out all the time, then you may well choose to act more “conservatively”, and use all kinds of controlling techniques to ensure that nothing goes wrong.
This last is the approach taken by those who build life-critical software, embedded medical devices, avionics, and the like. We’re all glad that they do it that way, except when we pay the bill. On those days, we might turn our minds to whether there is a way to do it that doesn’t require quite so many belts and suspenders.
The agile methods focus on bringing the team together and providing enough information feedback to enable the team to know that more powerful techniques may be needed. In general, the agile method does not formally specify what technique, or when or how to use it. Most practical writings on any given agile method will give examples of some techniques, but this is more to communicate the spirit of the process rather than to specify it tightly.
By their nature, agile process are not, and should not be, specified tightly.