I was pleased to read this. I'm always puzzled when people talk about discipline as a good thing in itself. I would consider it a positive attribute of a process that it required less, rather than more, discipline.One of the things I've learned over the years is that, while habit is a powerful mechanism, processes that require people to pay close attention to details and to do everything just so are almost always destined to fail for the majority of us. It doesn't matter if the process is a diet, a fitness regimen, or a software methodology. People eventually stop doing them. They may say that they are still following the process, but they aren't, and that may be worse than just stopping. Folks often start the new discipline with great energy, psyched to turn over a new leaf. But unless they can adapt their thinking and lifestyle, they eventually tire of having to follow the rules and backslide. Alistair Cockburn has written a good agile software book that starts with the premise that any process must build on the way that human minds really work. Later in the thread, Robert notes that -- contrary to what many folks who haven't tried XP for very long think -- XP tolerates a lower level of discipline than other methodologies:
For example, as a developer, I like talking to the customer lots; and as a customer I like talking to developers. That takes way less discipline for me than working with complex specs.He also points out that the boundary between high discipline and low discipline probably varies from person to person. A methodology (or diet, or training regimen) capable of succeeding within a varied population must hit close to the population's typical threshold and be flexible enough that folks who lie away from that threshold have a chance find a personal fit. As methodology, XP requires us to change how we think, but it places remarkably few picayune demands on our behavior. A supportive culture can go a long toward helping well-intended newbies give it a fair shake. And I don't think it is as fragile in its demands as the Atkins Diet or many detailed running plans for beginners. Accelerating Experience In a different thread, folks were discussing how much experience one needs in order to evaluate a new methodology fairly, which turned to the bigger question of how much project experience one can realistically obtain. Projects that last 6 months or 2 years place something of an upper bound on our experience. I like Laurent Bossavit's response:My general point is that it makes sense for processes and tools to work with human behaviour, supporting and protecting us where we are weak, and empowering us where we are strong.
> It takes a lot of time to get experienced.Short cycles let you make mistakes faster, more often. They let us succeed faster. They let us learn faster. A post later in this thread by someone else pointed out that XP and other agile approaches change the definition of a software project. Rather than thinking in terms of a big many-month or multi-year project, we think in terms of 2- or 3-week releases. These releases embody a full cycle from requirements through delivery, which means that we might think of each release as a "whole" project. We can do short retrospectives, we can adapt our practices, we can shift direction in response to feedback. Connections... This reminds me of an old post from Laurent's blog that I cited in an old post of my own. If you want to increase your success rate, double your failure rate; if you want to double your failure rate, all you have to do is halve your project length. Ideas keep swirling around. -----
> How many software development projects can you
> experience in a life-time? How many can you
> experience with three years of work experience?
Quite a lot, provided they're small enough.