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.

Matt Heusser has continued discussion of tester-developer relations, where Jonathan Kohl describes the flipside of testers telling developer’s that their automation code sucks.

Actually there are many scenarios, derived from at least a few properties -

- Does the person doing the automation know/not know that their code sucks.
- Is the code ’suckage’ pointed out by a third party, or the person writing it.
- Is the automation being done by a tester or a developer?

You can plot these out as a truth table and see where you fit. I tend to be automating, saying “I would love some help with this”, but can’t get help or chances to pair with developers. I’ve also observed testers wanting to pair with developers, but developers not wanting to come down to the tester’s skill level or work with their tools (as well as the case I mentioned in my previous post).

I’m sure situations also exist where the testers aren’t interested in working with the developers and learning.

So we have a model that contains -

- the feedback
- the source of the feedback
- awareness of the current state
- receptiveness to feedback
- desire or ability of one of the parties to change the situation.

Has anyone experienced any of the other permutations of these properties?

Matt Heusser’s recent blog entry on Tester/Developer communications prompted me to comment on the dreams of agile projects and tester heaven.

Now, I’ve been tempted to have that conversation, but the conversations I have had instead are much more along these lines:

Me: “Hey dev guy, here’s 20 years of accumulated knowledge describing why the testing approach you are about to take is not going to solve your problem, cost a lot of money, and waste a lot of time”.
Developer: “That’s nice, but we’re going to do it anyway”.

Two months later:

Me: “So, how’d that test approach work for you?”
Developer: “Oh, it completely sucked and was unmaintainable”.

Now, these developers are not stupid people, but it’s difficult for me to understand how things get to this point.

Or at least, it was until recently. Most agile development projects are much like Toyotism (or Lean, if you prefer). Better than how things were in the past, but not fundamentally changing the nature of work. Just as work in manufacturing is still hard, repetitive and largely about lines, so we easily fall into our old factory-style patterns. I believe this is at the heart of Brian Marick’s statement on the current state of Agile project experiences: ‘Whereas the number of people new to Agile who describe their project as “the best project I’ve ever worked on” seems to be declining, and we believe work should be joyful.’

Parallel lines of software development, with variable development and testing tasks performed serially end up being just as unpleasant as the old ways. Except now the moment your testing task takes longer than the development task in the queue behind you, someone’s screaming about the tester backlog.

Of course, it doesn’t have to be this way, but there’s very little incentive for the guy with the upstream work to contribute to solving it. They’re not the ones feeling the pressure. And once those pesky testers are gone, the whole thing actually appears to work much more smoothly. After all, what’s smoother than an assembly line with a single step?

Hint: The last line *is* the answer. But the devil is in the details of what comprises a ’step’. And what Matt describes is a step toward the solution as well.

Stay tuned.

There seems to be a flurry of post-agile activity on blogs right now. If you haven’t noticed, you can look at an example here. There is more elsewhere, and Jonathan Kohl tells me there is more coming. What this amounts to is a growing number of people who, for a variety of reasons, have a problem associating themself with the word “Agile”.

I still talk about “Agile”. I don’t make assumptions about what others mean when they say “Agile”. I ask. In conversation, I clarify what I mean when I use the word. I suspect this is a habit many testers pick up over time, due to the endless definitions applied to a small set of words in our field.

But I do see a problem with the name. If we look at the top of the agile manifesto, we see “We are uncovering better ways of developing software by doing it and helping others do it”. That doesn’t seem any different to what people trying to re-badge Agile propose, but I do see that Agile might not be the right word for “uncovering better ways of developing software”.

Perhaps it would be better to figure out what it should have been called in the first place. But how often is the name of a movement, phase or era bestowed by the movement itself? My limited knowledge of such things tells me that those who come later that get naming rights.

I can see why some still cling to the name. I can see why others seek a better name. The principles and values of “Agility” as defined in the manifesto are principles of a healthy working environment. The term Agile helped to distinguish a group of approaches from the dominant thinking of the day. Now that Agile approaches have entered the mainstream, the challenge is not necessarily to be more agile, even for Agile projects.

I’m not comfortable with the proposed alternative term ‘Pliant’. I think it creates a judgement in people’s mind, a tool for people to make divisions. Just as people may be derided for not being “Agile”, so might they be derided for not being ‘Pliant’. Perhaps the biggest problem with Agile (and Pliant) is that it’s not about a particular set of practices, or aspect of an organisation, but a word that threatens to encompass the whole organisation. Perhaps we should just get back to words like software development, systems thinking, management, testing…

I’m more comfortable with “Post-agilism”. It’s less confronting. It’s a reference to a time, not a relative property of a development approach. But if we accept that the purpose of the Agile manifesto was to encourage us to figure out better ways of developing software, the post-agile and Pliant thinkers are still doing exactly that. There is a parallel in that some people see post-modernism as simply “late modernism”. Maybe we are in “late agilism”. But history may decide that software development is simply progressing, and the Agile manifesto was just a kick in the pants in a period of stagnation.

“Agile” is not a problem. In some ways though, the name is. It’s a name that captures a reaction, not its more important goals of continual improving of the craft through practice. It served its purpose. It opened up discussion and suggested ways in which things might be different. It was a banner to rally under, for people presenting an alternate vision to the common practice of the day. It wasn’t an absolute, procedural description of how to achieve ‘Agility’. The manifesto is evidence of that. But many see the right hand side of the Agile values gaining dominance over the left.

It’s time to move on, and not get stuck in the process-driven ruts Agile was trying to get us out of. Maybe we can do it without a label this time, and look back on the words of the Agile manifesto as a reminder to keep looking for better ways.

If we can’t, we could do much worse than to label our ideas “post-agilism” or “late agilism”. It’s bound to be renamed by someone else one day anyway.

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.

Developing personas is a well-described technique (see Alan Cooper’s ‘The Inmates are Running the Asylum’ and Mike Cohn’s ‘User Stories Applied’) for considering the different kinds of users of the system we are developing. On a recent project, we began considering the different users who might want to user our product. In the process, I was able to connect it to another recently acquired trick and gain further insight into the user of our system.

The initial features added to our system seemed to be really only considering one type of user. Most of the team felt strongly that there were other important users who were being ignored, as many of the features didn’t seem to work the way we expected them to. They made sense for the targetted user, but made little sense when we thought about how *we* would want to use the system.

This suggested to us two user types – The bargain hunter and the traveller. We imagined the traveller to be someone planning a future trip. They were looking for discounted goods or services that would be available for them to use on holiday, some time in the not-immediate future. We also imagined a bargain hunter, someone for discounted goods and services, with a sense of urgency. This is the kind of shopper who hates to miss out on a bargain. Our system forced us to consider this kind of user as the primary customer.

It seemed that the two had some common objectives, but different needs. We tried to model this -

This begged the question -

What about these customers? Who might they be? We wondered if we could give them a name, and if they were worth considering?

We named them. They were important customer types whose needs had to be taken into account.

The Special Occasioner - A person who is looking for a good deal, but is prepared to take time to find it. Perhaps for a wedding anniversary, or someone who is planning a holiday, but hasn’t firmly decided.
The Last minuter – A person who leaves things to the last minute, has to unexpectedly travel, or just acts on the spur of the moment.

It was at this point that I flashed back to my recent reading of Howard Becker’s ‘Tricks of the trade‘, and his writing on ‘Substruction’. He describes substruction as -

‘…the logical converse of reduction. Reduction puts combinations together for the sake of simplicity. Substruction takes them apart, in the interest of discovery.’

As it turns out, this is exactly what we had just been doing. From analysis of our initial two personas, we were able to derive two more, and on further analysis we expanded this even further.

Here’s the process -

1. Determine the important attributes of a persona. In our case, we started with two, but you may have more.
2. Write down all the combinations of presence and absence of the attributes. This may be a truth table, but Becker’s book provides examples for non-binary attributes.
3. Work out which combinations of present or absent attributes correspond to the personas you have already thought of.
4. See which combinations don’t have a name. Try to name them.

Personas are a great tool. Enhancing the approach with the techniques of substruction gave us a much richer model of our system and the kinds of people who may have an interest in using it, and points to possibilities we may not have considered. Howard Becker’s book, though targetted at sociologists, is a great read for anyone looking to improve their thinking.

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?