Roundup of my four part series on Aspergers/ASD and Agile software development

Here is the obligatory round-up post for my four part series on Aspergers/ASD and the Agile software development methodology. It may seem that I am against Agile which is not the case by far. I think that Agile helps eliminate many of the dead times I found in Waterfall projects where I sat there waiting for my section of the project to start.

Still Agile can be challenging for those on the Spectrum and requires work to make it inclusive of the population as a whole. You can check out the articles here:

Part 1 - Change

Part 2 - Customers

Part 3 - Software

Part 4 - Interactions

Aspergers/ASD and Agile software development: Part Four - Interactions

In Part four (Read Part 3 here) I conclude my series on Agile software development and Aspergers/ASD with an examination of the last item on the Agile Manifesto: valuing Individuals and Interactions over process and tools.

If you are one of the developers in an Agile environment this can work well as the work groups are generally small and the interaction focused with people you know well. If you are in one of the attendant groups such as Testing, Documentation or Support this is extraordinarily problematic with or without a diagnosis. Changes are made on the fly and poorly communicated with little documentation. Whole requirements can be reinterpreted with little outside input. For those of us on the Spectrum this sort of behavior is maddening.

If you are a developer in the flow of work then all you need to do is make sure your interactions go smoothly and take good notes for yourself. You may need to hound other developers working on shared technology if they do not tell you their latest changes and they are not readily apparent from the code.

If you are in an attendant group then you need to make clear at the outset what sort of communication you expect and-- this is not easy-- hold them to it when they violate it. Remind them that you are part of the team too and the software cannot ship (or ship successfully) without your involvement.

When interviewing ask how changes made during the coding phase are communicated. If all they say is "Someone says something at the next stand up (i.e. meeting)" consider that a red flag. They should at the very least employ an e-mail process if not recording the change in one of the Agile tools like VersionOne, Jira or Agility.  When interviewing once I asked about their defect tracking system and requirements database... the CIO said I was scaring him with all this talk about tools. That should have made me run right there. In some form or another those tools are the backbone of any quality software development process and a lack of either invites chaos and wasted cycles. To be true to the Agile methodology you should not force people to open a ticket before agreeing to work but to produce quality software and keep everyone sane (particularly the ADA protected ASD folk) you must have some process for capturing the information.

Aspergers/ASD and Agile software development: Part Three - Documentation

Part three (read Part 2 here) of my series on Aspergers/ASD and Agile Software Development addresses the Agile principle of valuing Working Software over Comprehensive Documentation. In many ways I see this principle as exposing many deficiencies in the software development process as a whole: the misuse of developers as document writers; the overblown documentation that is so pervasive in older development houses; and the antipathy of many developers to document anything (including comments in the code).

I believe that the attachment to documentation by ASD folk comes more from wanting to know what is expected of them and the software as well as the difficulties that verbal communication presents (overwhelming information; unwanted stimulation; eye contact) than a love of documentation for documentation's sake. Keeping this in mind I offer the following pieces of advice:

1. The principle stresses 'comprehensive' documentation but does not totally eliminate the need for some documentation. When interviewing ask what their opinion of 'comprehensive' is and ask for examples. If it is enough for you to get started and puts you in a position that you can learn more about the system then it is probably a good situation. If however they have no documentation or one line documentation (e.g. "add no-balance accounts to processing") run. That is bad practice in ANY development methodology.
2. Use the documentation to launch yourself into a knowledge hunt. Teasing out the information needed can be fun and rewarding in and of itself. Remind them and yourself that their chosen methodology makes this a necessity.
3. Broaden your definition of documentation. I often use server logs, the code base itself, SQL Trace functionality and watching users operate as 'documentation'. In many ways it is more honest than user manuals and product specs as they show exactly how the software operates and not how someone thinks or perceives it should work.
4. Create your own documentation. With the advent of phone based cameras, easy screen capture methods and self publishing tools you can create your own documentation for your use. Who knows, you might even be able to hand it off to a fellow Aspie and make their day.

Going to a loose methodology like Agile can be difficult but it should not keep you from working at a place as long as they follow some basic rules. There is always a need for documentation just make sure it is reasonable. I once worked in a place where I filled out a project document that was 50+ pages long... and I edited 7 pages for a total of 20 lines. Way too much boilerplate information there. On the flip side the one sentence product spec is a recipe for disaster. Find what works for you.

Aspergers/ASD and Agile software development: Part Two- Customer Collaboration

Part Two (Read Part One here) of my series on Aspergers/ASD & Agile focuses on the Agile value of Customer Collaboration over Contract Negotiation.

This sort of flexibility can be doubly hard for those on the ASD Spectrum as it involves responding to customer demands which can come in to play at any time AND devaluing the adherence to a plan which many on the Spectrum value as a method for knowing what is coming and what is required of them.

Still it does not have to be a job killer. As with the response to change issues a few simple things will help keep the ASD person sane.

First off, when considering a position, gauge what the response to a Customer request is. There are generally two forms of yes... there is "yes we will do whatever you want right now without question" and there is "Yes we can deliver that in such and such a time-frame and with this cost to already laid plans". The second method means that there is more support from the technology leadership on pushing back so it is not totally left up to you to deliver two impossible goals at the same time.

Second, keep in mind that the plan is to focus on Customer Collaboration and not the endpoint generated at the beginning. You are re-framing the concept of the plan in your mind so that you can expect the Collaboration rather than expect the original endpoint.

Third, Collaboration does not necessarily mean a bunch of face to face meetings. Set your needs/expectations up front that you work best with your chosen format (e-mail, defect/change system, etc.). If an employer is not willing to entertain that concept then they are not for you.

And fourth, like the responding to change, when the collaboration requires too many alterations to the sprint then the sprint should stop and a new round of planning done so that everyone is on the same page.

The customer collaboration certainly presents obstacles for ASD folk to overcome but they are not surmountable. Sometimes a little personal coaching will guide you through the rough spots... and other times you should just avoid the worst places altogether.

-->Part Three<--

Aspergers/ASD and Agile software development: Part One - Change

Over the past few years a new Software Development Project management practice has emerged called Agile. Agile is the latest in a list of project management philosophies trying to replace Waterfall. For deeper discussions of each see their Wikipedia articles: Agile and Waterfall

Each has their advantages and I will refrain from engaging in the Waterfall v Agile arguments that dominate many discussion boards. Instead I want to address how the agile software development process effects those on the ASD Spectrum.

At its core Agile has four principles that they value:

•     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, with the ASD tendency to value processes, in-depth documentation and planning and a reluctance or antipathy to human interaction-- to varying degrees-- Agile might seem like the exact opposite of what would work for an ASD workforce. Still with it being the flavor of the time at many workplaces there are ways to cope.

This article starts with the last bullet point, responding to change over following a plan. Some Agile shops are compared to controlled chaos shifting priorities at a whim and this is true of some shops. Those shops give Agile a very bad image too. Many adherents to Agile welcome change but stop their work and immediately re-plan their efforts allowing a chance for everyone on the team to get to the same spot; this allows the ASD person a chance to come to grips with the change. And really change is not endemic to just Agile shops. I have been in many waterfall shops where after six months a business partner enters the room and says that the whole project has to shift gears. So as an Aspie or HFA your goal should be to dig underneath the buzzwords and learn what the shop is really like. Here are things to look for:

1. Discreet ends to 'sprints' (what Agile shops call their project segments). I once accepted a job at a software shop where the leader said "Sprints go on as long as they need to". This should have been a HUGE red flag right there. Sprints need to be limited in duration (ideally 2 to 6 weeks) so if regardless of when the change occurs, you the ASD person, were expecting some sort of change anyway. While change does happen open ended sprints indicate a horrible lack of coordination or planning. Remember Agile does value some planning; just not above responding to change.
2. Defined Sprint Goals. The goal of any sprint should be defined ahead of time and done before every sprint. If forces people to focus on what they are doing. Ask to see examples of their Sprint Goals; if they cannot produce them or if they are vague consider it a warning.
3. Response to change. Minor changes (wording on a screen; an additional field that is easy to implement etc) will occur and while anxiety provoking do not signal a major shift. On the other hand major shifts (new functionality, major rewriting etc) should signal an immediate end to a sprint and a new sprint planning session. The timeline needs to change and everyone needs to reorient on the new goal. Pose a hypothetical situation to them where a business user changes a major requirement of the sprint and see how they respond. Red Flag: laughter, "we get that all the time and just have to deal with it" or negative comments to your question.

Keep in mind that change occurs in every development environment and Agile attempts to own the volatility by having small discreet releases and an adherence to stopping a Sprint and resetting when the change gets too big. Looking for the red flags I mentioned will help you avoid nightmare situations.

-->Part 2<--