The Agile manifesto, Asperger's syndrome & high functioning autism

Since January my son has been going under an evaluation for autism. This has been a lot to come to terms with, but I'm on the road to acceptance. Right now we don't know where on the autism spectrum he is, but whatever happens he's going to struggle through school and the work place.

During a home visit our health coordinator made a comment that caused me to sit up and think. She said that there are a higher number than average of people with high functioning autistic (HFA) or Asperger's syndrome in IT jobs. These are generally highly technical jobs where they don't have to interact with others too much.

This got me wondering about how people with an ASD would view the Agile Manifesto. I can see how three of the principals could cause extreme anxiety.

If you aren't familiar with HFA or Asperger's syndrome, here's a high-level overview http://www.webmd.com/brain/autism/high-functioning-autism.  From here on I'll be referring to both of these as Autism Spectrum Disorders (ASD).

People with ASD’s are characterized by a triad of impairments in the following areas:

• Impairments in social interaction, including difficulties relating, sharing and forming relationships with others.
• Impairment in social communication, including difficulties interpreting and expressing verbal and non-verbal communication.
• Impairments in imagination and social understanding, including difficulties with imaginative play, pretending, planning ahead and tendency toward detail focus at expense of global understanding

The above description is from http://www.grampianautisticsociety.co.uk/about.html

Now here are the main principals of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As you can see there's a bit of a mismatch between the 1st and the 3rd principals of the manifesto and the triad of impairments.

It seems to me that a common sentiment within the agile community is that, people who can't collaborate within a team really shouldn't be part of a high-performing agile team. I had this view myself until recently. These people are generally talked about as crusty old programmers, with poor hygiene, who just want to sit in a basement developing software and don't want to interact with other team members.

People with ASD are generally average or above average intelligence. So my question is, as part of creating a better way of developing software have we inadvertently shunned people who aren't neuro-typical? ASD is only one disorder that could affect the functioning of a team another that comes to mind is ADHD.

I'd love to hear from your thoughts. Also if you've had a team mate or perhaps you have an ASD or ADHD yourself, I'd love to hear about your experiences.

Anyway I'm still learning about this confusing world, so feel free to correct me where I'm wrong.

Don't just review at the end

One essential part of Scrum, that few practitioners argue about, is the end of sprint review. This is a great place to showcase the work completed within the that sprint to any interested parties, but in some teams this is also the first time the product owner gets to see the completed stories.

What happens if a feature isn't quite right, or if we've misunderstood what was wanted? We run the risk of features not being accepted.
Even on a 1 week sprint, waiting until the end to review is too long.

Instead of waiting, collaborate with the product owner throughout development through a series of informal reviews. The earlier you start these the better. By doing this we get feedback earlier, so if something needs to change you haven't gone too far down the wrong path.

Even if you've created mockups its not until the feature starts to become real that we find out if everything is practical or possible.

Frequent informal reviews can this lead to optimizing the created value within the story by producing a better end result. It can also lead to a happier product owner.

Please let me know what you think.

Our move to pair testing

Three sprints ago the team decided that the way were handling testing wasn't working well. There were a number of issues that I'm not going to get into right now, but suffice it to say that we needed to do something differently. I also want to point out that this was nothing to do with the quality of the testing that was being done.

An action item that came out of that sprint's retrospective was as follows:

When a developer has finished coding they should try to pair test if our only tester was available to do so.
This action item was the top most voted for item with regards to how much energy each member had for making this change.

Over the following sprint there wasn't really a wholesale up take with the new idea until the last few days of the sprint. There were a couple sessions that happened before that, but something changed in the last few days that would altered how we viewed pair testing.

Before I move on I'll briefly describe what we consider pair testing.

To us pair testing is performed with the developer, who has written the code for the story to be tester, and our tester. During this session any bugs that are found and are related to the story being tested are fixed and tested again immediately. When the pair feels that the story is good enough to release then they stop. Any bugs that are found that are unrelated are noted down to be added to our bug wall later.

Anyway back to my story.

Unbeknownst to me our tester was in training for two days, three days before the end of the sprint. On finding out, which was the first day he was out, I asked the team how they wanted to handle this situation.

At this time we had a good number of stories that needed to be tested and there was no way we would have made our sprint commitment if we didn't do something.

The unanimous decision was that the developers would pair test themselves.

What happened then was a series of pair testing sessions with two developers. As one of my team mates put it, having two developers test kept them both honest. Also as bugs were being fixed as they were found, we shortened our feedback loop. With two developers testing we probably weren't as effective as pairing with our tester, but when each pair finished they were happy that the result was releaseable. Testing and bugfixing was no-longer taking days, but taking hours. There was little or no miscommunication and if there was it was cleared up immediately.

In addition, an observation I made about my own code was that I wanted few bugs to be found so I made sure it was really ready to test before exploratory testing.

All of this really seemed to bring home the value of testing as a pair to everyone, as well as removing a bottleneck that had been a problem for us. As it happens our tester was ill on the last day of the sprint so we couldn't have waited anyway.

At the next retrospective the team decided that we should pair test on every story and agreed to add it to our team working agreements.

During this last sprint our tester was back and everything is going well.  We still had at least one developer pair testing sessions to alleviate a bottleneck, but that's fine.

Overall I feel that this has been one of the largest improvements, if not the largest, the team has made. That is from a performance and a team cohesiveness level.

I'd fully encourage other teams to try this for themselves especially if there's a lot of to and fro between developers and testers or if testing is a bottleneck.