Skip to main content

Agile development processes

Photo credit (Creative Commons)

What is Agile Development?

Agile development describes a set of principles for building software that allow collaborative, cross-functional teams to accommodate changing user needs and requirements. Agile development alone will not help you build a good product. In fact, many agile projects fail unless they work to integrate human-centered design.

One of the great strengths of agile development is that delivery is incremental, which spreads the risk across the entire development process rather than loading all of it at the very end. When things go wrong, they’re smaller problems that can be fixed more quickly and more easily.

Agile development is based on the reality that you will discover new requirements during the development process.

In any complex system, needs change, evolve, or are discovered over time. Instead of ignoring these changing needs, or going through a painful contract amendment and renegotiation process, we embrace the concept that we will discover new user needs and constraints as we go.

To help this process, we pair identifying goals at a higher level (an “epic” in agile terminology) with an ongoing user research process. These epics describe the user need, not the solution. For example, a user story might be: “As a caseworker, I want to see all my current cases and next steps so I know what I need to do next, and when I need to do it.” We wouldn’t write: “The system shall display the next step next to each case in a grid on the main screen.” Through the user research and usability testing throughout the life of the product development, these epics are turned into a set of increasingly-specific user stories. Each story should be designed, researched, developed and tested within a single sprint. We validate each implemented story with usability testing with real end users, and use the feedback from that work to generate additional backlog user stories.

We prioritize user stories continuously and do not focus on what is in the development backlog beyond what can be done within the next month.

Agile development requires a shift in how you understand the costs of software development.

The traditional “waterfall” method of software development assumes that software can be built once for a large, one-time investment. In practice, this is untrue, because requirements can rarely be fully known and change often. The product team’s understanding of users’ needs arise through research and testing, allowing you to provide reasonable cost estimates in the short-term.

Ultimately, the state’s investment should be measured in working software, not phase documents or milestones. Only working systems are of value to real constituents. Based on that premise, teams are only able to measure the success of a waterfall project after most costs have been incurred, because that is the first time working software is delivered. This is a huge risk. Agile projects allow the state to measure success at more regular intervals, and reduce the overall risk to the state.

Starting with small projects can help build agile project management skills.

We recommend starting with a small, less important project in order to develop your team’s understanding of agile project management, then expand and incorporating a user-research practice into that development. Diving right into a large, high profile, or critical project is risky; it requires more coaching and training.

Incremental development can allow end users to start seeing benefits even before the legacy system can be fully replaced.

If a workflow is worth preserving, then portions of the old systems must be kept up until the new system is fully operational, no matter what approach is used. In a monolithic contracting approach, the end user must wait many months or years to use the new system and see any benefit — and that’s assuming there are no problems with the rollout. In an incremental approach, the end user could start seeing benefits in a shorter time-frame. Depending on the architecture of the legacy system, parts of it may even be able to be decommissioned and turned off before the full new system is in place to save money.

Agile principles recommend documentation that supports long-term maintenance.

One common misconception about agile development, which calls for just enough documentation, is that there will be no documentation. That is not true: agile prescribes documentation that is of value to the long-term team.

Like any process, agile development has risks — but they are avoidable.

In some cases, teams incorrectly using agile as justification for poor or no architecture, design, or documentation. Incomplete, incorrect, or uninformed adoption of agile techniques can lead to an ineffective process we call “agilefall.” We’ve written a blog post about how to avoid this pitfall.