In the Yahoo group supporting Cem Kaner’s Black Box Software Testing course, Anil Soni has been describing experiences organising and leading internal training, using the BBST course materials. One point in particular caught my attention:

> The major challenge is to have all the testers together in the same time
> needed for the group interaction.

In a recent role, I had trouble getting all of my testers together for study sessions. Often, the testers felt uncomfortable stopping work to come to a study session. At times, work was a genuine priority. At other times, the things testers were working on could wait an hour or two, but it was difficult for the tester to make that decision.

Sometimes I would have to make the decision for them. That is, tell them “This is more important than the work you are doing right now”. I could do this because I had management support for creating a learning environment.

Organisationally though, we were sending mixed messages. The project manager expressed the opinion “We’re not running a school here”. The development manager countered with “We absolutely are”. These two statements captured the tension between getting today’s job done now, and ensuring that tomorrow’s work can be done better or more efficiently. In one statement, is the view that employees should always be working on something that directly contributes business value. In the other statement, the view that it is vital that time be set aside during work hours expressly for improving the skills of staff and for reflection on past experience.

At this point, I don’t really want to enter into the philosophical debate around whether organisations should be learning organisations are not. However, if you’ve decided that it is important that your staff learn and improve here are a few things that I would consider.

• Make it clear how much time you expect employees to be spending on improving their skills.
• Check that they are spending the necessary time. If not, find out why.
• Keep groups small if possible. This allows scheduling to be more flexible.
• Get a clear statement (or statements) from whoever is in authority that study time is important for the organisation.
• Establish and communicate principles for when work should take priority.
• If participants are having difficulty deciding what is more important, help them.
• If you are going with a less structured informal learning approach, how will you know whether team members are using their study time for study? That is, what feedback mechanisms will you have to help understand and support your team’s learning needs?

On this last point, in one team, a thousand dollar self-education budget was available to each employee per year. They were free to spend this on anything that they wished. However, in a year and a half, almost none of the team had made use of that budget. That’s one example of a feedback mechanism, triggered by the question “Why haven’t you used your training budget?” Regular team meetings, where each team member presented some recent learning were another.

The dominant work culture is about appearing to be busy, and doing ‘real work’. Despite support at the highest level, if other management levels don’t support the company’s learning objectives, employees will be quite nervous about spending time on tasks that their close managers may consider trivialities. This is a significant cultural change, and the forces of history will be working powerfully against you.

I’ve recently come across the Informal Learning blog, and hope to write more on this subject in the future.

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?

- that you’re going to get it right first time.
- that nobody knows better than you do.
- that it is going to be faster if you do it all at once (tightly coupled to the first point).

Another possibility might be that you’re afraid of negative feedback, which, in the context of working on a software team, is delaying the inevitable.

I’m sure there are more possibilities.

Problems with our assumptions

That you’re going to get it right first time

How might we behave if we assume that we are not going to get it right?

That nobody knows better than you do

How might we behave if we assume that everyone might know something we don’t?

That it is going to be faster if you do it all at once

How do we know that ‘faster for me’ is necessarily faster for the project overall?

Jon Eaves was blogging about problems related to development goals not aligning with business objectives and it resounded with some thoughts I had been having on company values.

In addition to goal alignment, I’m thinking at the moment that alignment of values is equally important, or at the very least it helps when the true values of the company are clearly stated. Goals tell us where we want to go. Values help us make decisions along the way.

While individual values may vary from the company’s, by being conscious of our own goals and that of our employer’s, we can discuss the differences, or at least see just how wide the gap is between one’s own values and one’s employer. I think this is a good starting point.