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
Showing posts with label software development. Show all posts
Showing posts with label software development. Show all posts
Thursday, June 9, 2011
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.
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.
Subscribe to:
Posts (Atom)