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<--