4. We work in an agile way

We develop software using agile and lean methodologies. Agile software development methods have become the norm in the private sector and differ considerably from the “waterfall” software development method that is dominant in the federal government. In waterfall, agencies write documents with all of the requirements for a project and then a development team codes, tests, and delivers the full product. Agile principles value working code over documentation, iterative development based on validation with the target audience, with focused efforts that deliver value in short sprints that allow for a regular feedback loop. Well-done agile projects are outcome and goal-driven, not feature-driven. When working together, we articulate our goals in terms of outcomes for the user, and then establish a way to gauge if our project meets those goals with qualitative and quantitative assessments that we carry out in each sprint.

Throughout the project, we’ll produce prototypes and/or working code over short sprints and get it in front of users immediately in order to learn and refine our approach as soon as possible. As a team, we will iterate to a project’s state of success (for example delivering the user and business outcomes we want to see) rather than an arbitrary predetermined final state. Software delivery is continuous, so there is never a true “done” state, which is why we focus on measuring achievement of business and user outcomes—rather than completion of features—to gauge success.

Through the regular cadence of agile project meetings, we will revisit strategic project goals in order to maintain a shared understanding of the outcomes that constitute success.

What does this mean for you?

We don’t work from requirement documents. As mentioned above, we engage with problems, conduct discovery research, develop hypotheses, and co-design a potential solution with your product owner. We understand requirements documents are the typical way projects start; if you have them, we’ll look at them and use them as a starting point for a discussion — but not for development.

We build a product backlog of discrete chunks of functionality from the perspective of a user called “user stories.” During each sprint, your product owner will work with our team to prioritize user stories and estimate how much work can be done during the sprint.

We also employ principles from the Lean Startup movement, where the assumptions about how a particular piece of functionality supports a business goal or outcome are explicitly articulated and tested. How often we learn from users, and learning whether or not a feature gets us closer to our goals, are the main measures of progress for our work in a sprint.

Every project has deadlines and time constraints. Yet, one of the tradeoffs of building the right thing is that it’s not possible to know ahead of time exactly what features will be in a product by a certain date. By regularly revisiting and prioritizing the outcomes desired in the project, you can help ensure that the most important functionality can be included first.

How do you know if you’re ready to work in an agile way?

  • Are you willing to have a subset of your target audience use the product before it’s polished?
  • Are you willing to talk about the process of development with outside groups to gather feedback?
  • Are you prepared to change direction rapidly on projects as the problem and possible solutions are understood more deeply?
  • Has a specific solution already been promised to stakeholders with a deadline?
  • Have you thought about or defined desired business outcomes (such as KPIs)?
  • Is your product owner committed to participating in co-design activities, like design studios or constructive critique?