At 18F, we work with partners throughout federal and state government to design, build, and buy software solutions that improve the user experience of government. While much of our work is product-focused, almost all of our work involves helping our partners adopt and improve their processes, particularly around IT practices.

The mandate to be “agile” is everywhere. But agile isn’t an on-off switch. It’s a skill and a mindset that is developed over time, through dedicated work, open teams, and lots (and lots) of practice. Over the years we’ve honed our listening skills to identify areas in which we can improve our agile practices while helping our partners improve theirs. Each example is based on our real-world experience working with partners across the government and private industry. When we say “you” we also mean “us” and “we”. We’re in this together and we hope that you chuckle with us, knowing that agile is tough, you are not alone, and we’re here to help.

You’re agile now, but nothing has changed…

  • You’re told to be agile, but given requirements with inflexible deadlines
  • Everyone on the team is a manager OR your manager isn’t part of the team
  • Your software team adopted agile, but your strategy, business development, staffing, and contracting practices follow a strict waterfall approach.
  • No one has ever articulated an obstacle during a stand-up
  • Everyone does post-mortems, but nobody does regular retrospectives to identify ways to improve in the next iteration

Agile requires a mindset shift—and it takes continuous commitment at all levels to reap the maximum benefits Agile offers. Here are a few suggestions for ways to get back on track:

You go months without building anything…

  • You’re defining every requirement and use case before starting any work
  • You spend two years collecting user stories and then have a governance board vote on each of them individually
  • You can’t do anything without approval from the steering committee
  • Your team is constantly being asked to justify why it changed something

We understand. We’ve been there too! Check out our lessons learned and how we’ve overcome cultural barriers to agile development practices.

Your user research is not focused on users…

  • You interview stakeholders as proxies for users
  • Your user research resulted in a list of feature requests rather than a list of user pain points
  • Most of the stories in your product backlog are unclear or phrased in terms of benefit to the business or the engineering team
  • You’re moving to a new architecture without knowing who you’re going to build for
  • Code never makes it to an environment where actual users can use it and give you feedback

Does this sound familiar? Don’t fret! You can get lots of advice on user research right here on our blog, or for a quick guide on how to run different types of user research activities, head over to the 18F Methods.

You’re trying to “do Agile,” instead of being agile…

  • You’re doing scrum ceremonies (sprints, stand ups, retros), but not seeing any change in outcomes
  • Your planning meetings are focused on listing out specific implementation details rather than expected outcomes
  • You categorize development tasks in terms of time they will take to complete (rather than by the effort involved)
  • Your “points” or “velocity” are used to compare and contrast your team to other agile teams
  • Your product owner’s expectations don’t align with the team’s expectations
  • You’re working with a vendor and you don’t have insight into the work being planned or accomplished by them on an ongoing basis

If this sounds like you, you’re not alone. Many organizations struggle with how to effectively, yet efficiently incorporate agile ceremonies, especially in the beginning.

You’re not producing high-quality, working code…

  • Your designers have already been moved onto the next project
  • Your stories are too large to accomplish during a sprint
  • You are not following a ‘test-first’ approach
  • Developers are constantly and continuously interrupted
  • Once you release a feature, you never change it

Is your team struggling to make the progress it wants to? Take it one step at a time.

Do any of these sound familiar? If you recognize some of your own practices, you’re in good company. Agile is a muscle that needs to be exercised regularly, and self-reflection is key to continued success. We write about our experience doing agile work on this blog, have assembled an introduction to and overview of agile practices at 18F, and can work with your team to help overcome these challenges. If you’re interested in working with 18F, get in touch at inquiries18f@gsa.gov.