Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery; time boxed iterative approach and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. Wikipedia
Among the many criticisms levied against Waterfall software development is the promotion of the Big Design Up Front (BDUF) concept whereby all possible features of the final system including its design and operation are intended to be planned out in detail prior to any code being written. Proponents of the waterfall method approach each step of a project from planning to requirements then to design, development, and implementation in linear fashion. In such an approach, each step must be completed before the next step can be begun. Persons who are big proponents of planning appreciate the fact that the waterfall method plans everything explicitly along the entire lifecycle from planning to market.
Proponents of accessibility see natural locations in which to integrate accessibility into the Waterfall approach. In the planning & requirements stages, specific accessibility requirements can be included into the specification for the final product. In the design phase, the design comps and functional mockups can be evaluated for accessibility and specific implementation guidance can be given to prepare developers. In the development phase, work can be checked to ensure accessibility has been integrated. Finally, in the implementation phase, the final deliverables can be validated prior to launch. The pitfalls to this approach are the same as those for Waterfall as a whole – namely that it is impossible to know all the business and user requirements up front. More importantly it is impossible to stop a moving train. Once a waterfall project has gone a certain distance along its path, accessibility issues in the end product are likely to be irreparable. Just as with other issues in Waterfall projects, accessibility issues caused early in the project will have a lasting and often magnified effect in later phases of the project. Finally, as it relates to accessibility, stakeholders in Waterfall projects are very often not actually included in the regular work of the project. In many instances, stakeholders within the project are often separated in their own silos and only asked for their input during milestone exit meetings which only adds to the impossibility of any real change happening when accessibility problems are found. Agile software development offers much greater opportunity for an accessible end product and it does so in a number of ways.
Agile Manifesto reads, in its entirety, as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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
That is, while there is value in the items on the right, we value the items on the left more.
Wikipedia
Among the most important characteristics to observe about Agile software development is the spirit of collaboration that permeates everything the Agile practitioners do. Everything from requirements & design to development & testing is done in a collaborative environment where all persons in the team contribute to what gets done, how it gets done, and when it gets done. Agile teams have daily “stand up” meetings where the team members literally stand to discuss their progress during the previous day. During sprint planning meetings, the team responsible for doing the actual work also contributes to determining what work gets done during the sprint. Agile teams develop systems based on what are known as User Stories which are one or two sentences written in the voice of the target user that captures what that goals user would like to achieve. For instance: As an office manager, I would like to track the accumulation and usage of employees’ Paid Time Off. From such a user story the team themselves estimate the level of effort needed to complete the story, break it down into all of the tasks necessary to complete the story, and determine the resources necessary for completion. During the sprint, team members work collaboratively to ensure that all stories are complete and on time, with regularly scheduled sprint reviews where stakeholders are given a demonstration of working software at the end of each sprint. Such an environment is highly conducive to integration of accessibility, primarily due to the short iterations within Agile as well as Agile’s focus on quality.
Most obviously it is the collaborative nature of Agile software development that can be leveraged to enhance accessibility of the end product. Ideally, accessibility knowledge will exist among development team members and accessibility included during the normal development process. This does not happen often however, because knowledge of accessibility is still rare among developers, many of whom are often self-taught in their craft. Because this type of knowledge is rare among developers, it must be grown through the process of collaboration with an Accessibility Subject Matter Expert (SME). During regular Scrum activities, the team’s ScrumMaster will often communicate to the Product Owner to get clarity on features or to communicate on progress or resolve other issues. Similarly, a ScrumMaster should work closely with the Accessibility SME for guidance on ensuring accessibility requirements are met. The existence of a distinct Accessibility SME, in cases where such knowledge doesn’t exist throughout development staff, can be especially beneficial in organizations with large development teams. In such a case, the Accessibility SME can serve as a resource for each Scrum team.
While it is often said that Agile methods are not set in stone but rather inherently flexible, what is very often not flexible is that at the end of each sprint, the team must have produced potentially shippable software. This does not mean that the entire product is ready to go to market but rather that the features that have just been completed in this iteration work completely as intended. All design has been done, all coding for the story has been completed and tested and is ready to be demonstrated to any stakeholders. How each team determines when they’re at a potentially shippable state is what constitutes their Definition of Done (DoD), which is a checklist of criteria which must be met before a user story can be considered “done”. Some simple examples for DoD are:
- All tasks finished
- All tests passed
- Code checked in to version control
Or,
- All code complete
- All tests written
- All tests passed
- Peer review completed
- All documentation written
Exactly what constitutes an organization’s DoD will vary considerably depending on the business goals of the product and established processes for the team. In nearly all cases, Definition of Done will contain checks to ensure the deliverables for this sprint are tested to ensure they’re bug-free. In certain cases, such as in Test Driven Development (TDD) and Pair Programming, the tests are written at the same as the code for the final deliverable. Developing in this fashion makes it possible to prevent bugs in functionality and to prevent accessibility bugs as well. Accessibility bugs can be more easily avoided in an Agile environment when accessibility tests are included in the DoD whenever UI-related features are being developed or modified.
This model of Agile software development should be adopted by accessibility persons even in cases where the organization itself does not follow Agile. Specifically, if we are to attempt to cause a positive change in the accessibility of ICT products and services developed or procured by our organization, we should seek opportunities to work collaboratively rather than separately. Instead of operating in separate silos accessibility persons should seek to work collaboratively with developers early and often in the development lifecycle. Instead of seeking to function as the accessibility gatekeeper, the accessibility advocate should take opportunities to assist design & development staff to understand accessibility. Instead of waiting for the product to be finished before testing it, it should be tested during development. Finally, instead of attempting to test every feature in every location of an entire system, testing should be handled iteratively, much like an agile software project, in which the features and components with the highest business value (and risk exposure) are tested first. Accessibility issue remediation should then also be iteratively managed to allow rapid, incremental repair.
Proponents of Agile software development point to the flexible, collaborative, customer-centric, and end-quality aspects of agile as some of the central principles which underlie the Agile Manifesto. These principles can mesh cleanly with the goals of accessibility, allowing accessibility to be part of the process of delivering a quality end product. Even in cases where Agile is not the development methodology of choice, this collaborative and iterative approach can still be used by accessibility advocates to integrate accessibility with reduced resistance.