Michael Bolton says it well:
Well, I for one am shocked, shocked to hear that someone didn’t get exactly
what they wanted the first time they tried something.
Why do we call this work development? It isn’t just about writing programs;
it’s about developing projects, and developing people, and developing
skills, and developing models, and developing understanding. Development of
anything is rarely linear and often unpredictable. When you learn
something, you greatly increase the value of any failure that you might
Some people even confuse development with typing, and I think that’s mostly why it’s so difficult to gain mutual respect between the business and development camps.
Maybe exchange programs would be interesting; I walk a mile in your shoes, you walk a mile in mine. We could call it development.
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.