Back in late August, an unnamed federal agency visited our office. They came from the far western edges of the District of Columbia, crossing quadrants and security checkpoints to the International Broadcasting Bureau boardroom for the sole purpose of solving the mystery … how do you do agile in the federal government?

It’s no mystery for us, the Office of Digital and Design Innovation. We’ve been running agile scrum teams for the past two years. By now our project teams’ velocities have become more empirically predictable, our delivery of Done has the consistency that’s now more well done than medium well.

These things didn’t appear automagically. As a scrum master, I can recall more than a few bumps and bruises on the agile playing field. We adjusted, adapted to what worked well for our teams and as an office. “So what’s in your secret sauce?” they asked.  The answer: there is no secret!

And that’s when we dropped some agile knowledge.

This agency, who prefers to remain nameless, revealed that they build and maintain the CMS that powers the many websites for their external communities. They have development goals and the need to maintain and enhance existing systems.

We went around the conference table asking the visitors to state the burning topic related to agile management that they wanted to address.

Here’s what they mentioned:

  • Agile and government contracting
  • the culture of Agile
  • collaboration with non-co-located team members
  • the agile process
  • issues of privacy and security
  • managing new development work alongside DevOps

Did we have #packitinaboxandtieaprettybowonit answer for each of these concerns? No way! But we did try our best to de-mystify practicing agile scrum. Using recent projects completed by our office, we walked through the process and shared firsthand accounts of the process. While we’re no experts to agile, we’ve managed to deliver value in our products, products that work!

The scrum masters and product owners led the majority of the discussions. It seemed as if the majority of Agency X’s attendees were program managers. My scrum master colleague, Ashok, led the way with a discussion on how they might migrate from program manager to that of product owner.

To do so, he had to start with the basics and explained what product owners do in an agile scrum team. Will, ODDI’s Director of Mobile, talked about the daily scrum, who attends, what they discuss. When my turn came, I tried to give them a bird’s eye view of how to plan a new project. I used time as a common standard of measure and shared realistic timelines for mapping a product’s development lifespan.

When it comes to planning for a project from scratch, I shared with Agency X these big takeaways from my experience working with our agile scrum teams at ODD:

  • 6-month work plans work well for project teams. They give you the ability to map strategic and product goals. When you look down the field with such a timeframe, six months allows you to build in core metrics to track and measure your achievement goals.
  • Breaking the 6-month plan down to 3-month markers gives people a good sense of time. Three months equate to a season, a fiscal quarter, it offers a good timeframe for scheduling annual leave. A 3-month time plan gives you a realistic perspective on what you can make in that time frame, market timing, and launch opportunities.
  • Within a 3-month plan, you can define 1-month Themes. They’ll help align functional group goals. In our office, we set them among our development team, marketing, and the editorial desk. With the 1-month timeframe in mind, you can start to create your user stories.

With the chronological framework for an Agile project plan set, I proceeded to share other tasty tidbits of advice, the kind you can only gain from the hard-knocks, real world lessons from the tours of duty in the agile trenches:

  • I promoted the invaluable experience of running a design sprint to kick off a new product or service.  It’s like IDEO design thinking meets lean principles. This is a chance to explore new ideas, build and test things, learn from user research, and prioritize. Google Ventures offers a great rundown on how they do it.
  • When thinking about all the promising things you want to make, narrow the field! Less is more!
  • Get user studies and user reviews in early!
  • Time pressure works best for moving your projects to done. There’s no better motivational stress than when working on a deadline.
  • Agile is more about building working software, it’s also about making a quality product. In our two-week sprints, we schedule in a day for QA each week. It’s a good idea to schedule in a review by a technical expert during those scheduled QA days. If you can recruit a functional team of technical experts, even better!
  • Co-location is ideal. I’ll have to agree with Marissa Mayer on her views on telecommuting. Our developers got more things done and bugs fixed quicker when they physically worked alongside one another.
  • How do you know if your team is delivering value? If you as a team can maintain an open dialogue as to what to prioritize, i.e. the stuff that’s of the most value, the most important, the most meaningful things to make.  Commit to offer these slices of value more frequently, and you’ll create more satisfied customers.

What other words of advice would you offer a tech team dipping their toes into the agile waters?

Let’s share them in the comments section!