I feel very ‘tech’ now. I’ve uploaded an edited audio version of the last MAST meeting, where we (Erik Petersen, Kristan Vingrys and me) attempt to answer John Gallagher’s questions about testing in agile projects.

Find it at http://www.quinert.com/mp3/mast200709a.mp3

Enjoy!

The three beeps protect the innocent. The first is a service provider, the second and third are internal departments of one of John’s past employers.

After an email exchange with Matt Heusser, Matt has posted my comments on how our work tools sometimes influence our behaviour on projects. That’s because these work tools are based on models of how someone believe software should be developed. Perhaps more importantly, the tools that I’ve seen are usually designed to ensure that the team conforms to a process, not to ensure that the right things have been done.

The tool that I feel most strongly influenced the agile process in a former employer, is the workflow tool. Workflow tools are typically linear flow tools. I believe that the use of these kinds of tools (in our case, JIRA, but you can substitute most bug tracking tools if you like,) strongly reinforced a linear model of software development. I’m not aware of any tools that don’t model software development this way, but am quite happy to be shown to be incorrect.

If you don’t want your team throwing their work “over the wall”, check that your tools model development the way you think it should be done.

One more word on XP as methodology (well, a few more actually).

Any methodology seems to me to be a snapshot of a solution to a particular problem that somebody solved at some point, with a particular set of people and skills in a specific context. There are occasional statements flying around the agile-testing group which suggest to me that the intial applications of XP were either in similar contexts or recreated the important aspects of the original context.

One of the things that strikes me about the thoughtful practitioners Michael describes (and that I’ve been able to observe) is that they are actively seeking to solve a problem. They evaluate a development approach that they hope will solve the presenting problems they have, optimised for the skills that the team possesses and the organisational context. Then they attempt to solve their problems through the application of the designed approach.

My snapshot of some of the important attributes of XP’s context is this -

- Poor or non-existent testers and business analysts.
- Developers who were quite good at testing their own code and focusing on the business domain.
- Knowledge residing in customers’ (or analysts’) heads struggling to be free.

I’m convinced that there are many applying XP who have never really given thought to the problems it is designed to solve, the skills that are required to apply it successfully, the people required to make it work, how it might affect those who don’t fall within the XP developer circle and whether it is suited to their organisation and its culture.

We may then witness some of the following -

- Alienation of those who are not developers while the developers ‘do XP’ (by the book).
- Sub-optimal use of the skills of non-developers.
- Disappearance of team members who get less than two paragraphs of description in the XP book.
- Practices not solving the problems they were designed to when the underlying values or principles are not present.

It’s hard work to tweak XP to fit a team that isn’t just customers and developers.
So think about it. What skills do you have in your team? In whose hands do they lie? How will you work with the people around you to get the most out of your project, not just the developers?

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?