The practice of simplicity (or Methodology perils)

I’ve shared some ‘perils of XP’ conversations with Michael of late, so I wanted to consider my experiences on the topic.

One thing that strikes me about software methodologies is that like many things which are written down, recorded and/or institutionalised, the reasons are often long forgotten. The early adopters are typically passionate, thoughtful, and (I believe) seeking to solve a very specific problem.

Those that come to the team later may learn the practices that the current team is using, but never understand the problem that those practices are intended to solve. Indeed, the existence of the practices may cause them to never witness the problem at all. This may then lead to the Routine behaviour that Michael describes.

I’m also thinking that while writing down our values and principles as a guide for others is helpful, it may be more helpful to explain the journey that led us to our current thinking. Of course, we are usually slow to learn from the experience of others. I’m not yet sure how we instil just enough fear and understanding into those who haven’t experienced the pains of yesterday, but it seems like an important thing to do.

Before applying any software development approach (or modifying an existing one), it might help us to ask a few questions –

– What problems are we trying to solve?
– How might all of the team members best work together to solve these problems?
– How will we know if we’re succeeding?