Monday, June 6, 2011

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


  1. It is interesting (perhaps sad too) that a field that is potentially so autism-friendly is being taken over in a way that makes it harder to work in it.

    I'm an independent developer and autistic, and I've remained true to what is annoyingly called "waterfall" BECAUSE it is fast, and actually can be more agile than Agile if you do enough documentation. Saying "we do Agile" can be just making an excuse for having no plan. Companies I work for who don't work from a waterfall-like plan end up not knowing what goes in cust_account.Flag6 (or whatever) and then they are slowed down by ignorance, whereas I can make definitional changes and propagate them through a large system, and can do that quickly because it was planned in detail in advance and rigorously documented.

    I recently had a customer want to spend more money and do things slower, even if they got a worse result, just so certain managers who were otherwise not really qualified could be "involved". In the extreme this "agile" philosphy means kicking out all the autistic oriented people and others who are really good at details, and putting salespeople in charge.. a war of egos.. "let's not put engineers in charge of engineering projects". OK I'm bitter about that. I guess my point is the decision about whether to have long or short cycles and how ready a team is to accomodate change really have nothing to do with the management philosophy issues. You could have an autistic-friendly environment in both development paradigms.

  2. I think many companies use Agile as a replacement for 'no processes' and were just as bad in Waterfall as they are in Agile. Some people just do not want to check into the software development process regardless of methodology.

  3. Interesting article. It highlights some issues we are exeperiencing right now. We employed 10 adults, with an ASD, to do software testing. I am not convinced that Agile works for most, however, making some adaptations (such as collaboration using the excellent Zoho Projects)seem to be helping. It's is too early to say but as our company's sole reason for existing is to employ adults with autism we WILL find the answer.

  4. I am glad to see you making adjustments. I think Agile has many things that make it a good choice for software development but there are some holes in it too (as with all paradigms). Do you mind me asking where you work?


  5. I like your suggestions they are really helpful. Thank you so much for sharing this post.

    Scrum Methodology