I’m currently the coach of an ‘Agile’ team at work.
I say ‘Agile’ because we haven’t managed to adopt the full set of practices recommended by XP, which I was originally striving for. I use the scare-quotes also because we aren’t really aiming for agility; none of the involved parties have any particular desire to be able to adapt to change.
Rather, we are just trying to find a dignified way of running our software projects, and many of the ideas associated with Agile Software Development seem to make life easier for us.
The team is not exactly fired up and burning on the gasoline of Agile. We’ve had our fair share of discussions around things like short iterations, done-done and test-driven development. But I’ve done my best to explain why I think the practices will help us, what problem they are meant to solve, and I think the team agrees with me for the most part.
It strikes me as this is progressing — we’ve been doing it rigorously for about 6 months — that what makes the improvement isn’t so much what we do, but the fact that we’re hyperaware of what we do.
I can’t help but wonder whether we’ve found a nugget of gold: process and practices may not matter so much, compared to a team taking an active interest in their way of working, with the self-awareness and authority to say: ”This shit is not working. Let’s try this other thing instead”.
This element of self-improvement is often listed as a practice in Agile methods (Retrospectives), but I don’t think it needs to be exclusive to Agile methods.
If a ‘traditional’ project was composed of team members hell-bent on self-improvement, I believe the process could be tuned to some kind of optimum, toward a pragmatic, well-oiled code of conduct. I don’t think the result would be Agile, but I’m pretty sure it would help the team deliver.