Case Study: Agile Government and the Broadcasting Board of Governors (Office of Digital & Design Innovation)

Case Study: Agile Government and the Broadcasting Board of Governors (Office of Digital & Design Innovation) 2017-04-23T23:02:16-08:00

Broadcasting Board of Governors  Office of Digital & Design Innovationby Son Tran

Download PDF version


The Office of Digital and Design Innovation at Broadcasting Board of Governors (BBG) starts getting things done. Keys: training and prioritization.


In the Office of Digital and Design Innovation, the office where I work at the Broadcasting Board of Governors, we practice Agile in the Scrum flavor to manage our development projects. We’ve been doing Agile Scrum for the past two years, about the same amount of time that I’ve been with the office. In fact, I was brought into the office specifically to serve as an Agile ScrumMaster.

Of the roughly 3,600 employees who work for the BBG and all its entities, we are the only office to practice Agile project management. I wish that was not the case! Slowly, and by example, our colleagues in the agency are seeing that Agile projects run well. Our cycle times are shorter and more predictable. People are starting to notice that we get things done!


Why did the office decide to embrace Agile? While the decision to go Agile by our leadership pre-dates my time at the BBG, I learned from inquiring with my director that the office had two goals for going with the Agile methodology. First, we wanted improved communications at all levels: from within the project teams, between our office’s teams, and from the office to other program offices and functions within the agency. Another goal was to allow our office the flexibility and space to learn, better define and deliver projects iteratively. I think in the end, we achieved those goals.


As I look back on what we, as an office, went through, I can recognize a few useful life lessons for those of you looking to go Agile. Allow me to share with you a few of them.


How did we go Agile from out of nowhere? With training, training, training! Vertical specialists received training to become Agile Product Owners. Along with the director of my office, they passed the exam and became certified Product Owners by the Scrum Alliance. Project team members also received a one-day on site training on how to work in an Agile team. It was brief, more like dipping the very tips of your toes into the murky waters of Agile. Only practice and time would get the office fully immersed in the Agile way. If only there was a group like Agile Government Leadership had existed then to assist us!

Tools, practices, wonky details

What did we use to track our projects? Jira. Personally, I have mixed feelings about this tool. If you only have one Agile project to manage, there are simpler and FREE tools out there to try. Trello comes to mind. Jira’s good if you have to manage a portfolio of projects. It’s not the most intuitive tool out there. I spend a lot of time either managing the views, i.e. organizing which project shows up on which project board, or which projects colleagues can see when they sign on. Jira does offer its own wiki, Confluence. It’s useful for collecting all the preliminary artifacts you capture in the initial phase of defining your project roadmap, i.e. the sprint zero phase.

Daily standups

We embraced the daily stand up, also known as the daily Scrum. If there’s one thing to take away from doing Agile, it’s to do the daily Scrum! Make sure it happens every day and limit it to 15 minutes.

Scrums are very helpful in minimizing two risks to your project’s cycle time:

  1. when a team member goes rogue, i.e. decides to do his/her own thing despite the work the team has agreed to commit to during the given sprint, and
  2. when a team member goes into stealth mode, i.e. goes M.I.A. and no one has any idea what he/she is up to.

As a ScrumMaster, I hate it when these things happen! They’re time-proven ways to raise the stress levels and cause excess grief. No surprises, please!

Single calendar

All of our projects ran on the same sprint calendar. It was easier for managing resources. As a small government office, our design and developer talent is spread thin across several project teams. We found that it was better to dedicate a team member to one project than to work on multiple projects at once. There were some exceptions, of course.  When we needed to dedicate a resource across two teams, it was easier to have the developer work on one project the first half of the sprint and then hop on to the second project team at the latter half of the iteration.  Even while the developer was doing work for the other project, it was required to join in our daily Scrums.  This kept our team apprised that things are moving along as scheduled, and this kept the developer informed of our team’s progress.  Again, no surprises!

No team comparison

We used to compare project teams’ velocities with one another, but after a while we didn’t see the point. Teams were made of different people, each with their own velocities, and they faced different levels of complexity. Comparing teams’ velocities didn’t serve any benefit to improving their productivity. So long as they were adding value and delivering, they were on the right track. That’s good enough!

A worthwhile exercise that we did do was norming our story points.  Our scrum masters and business analysts got together, analyzed empirically available completed stories of varying complexity levels and established a standard for assigning points to a story given its scope.  As projects come and go and we amass a proven track record of performance, we revisit this exercise once or twice a year to stay consistent in our story point estimations.

Demo days

We used to have a big Demo Day on the final Friday of each two-week sprint. Project teams that had something to demonstrate would show their wares. It was a whole office affair that morphed into a big meeting. People got bored so we changed it to a walking tour of the office and coined it the “Tour du Demo.”

We have an open office, and this allowed us to visit one area to another checking out the project teams’ work at their respective work stations. Now the demos happen independently by the project teams, without any office-wide coordination, and sometimes occur after the sprint has ended. Even though they occur independently, that doesn’t mean colleagues cannot attend another team’s demo. Logistically, it was easier to run demos this way.

Whichever way you organize your demos, the key is to emphasize a more transparent approach. Instead of running some highly scripted presentation, let the actual developers/designers who did the work lead the show and tell about the working product.


Prioritize, prioritize, prioritize the backlog! This is super important!

Make sure your Product Owner steps up to the task. Lay out the project roadmap with a defined order of themes you want the team to achieve within the next 4-6-8-10 weeks beyond your current sprint. I’m glad we got into the habit of doing this. For one team, it kept us prepared to handle the time our product owner took off for six weeks to go backpacking through Southeast Asia on the eve of a major release. Then there was this matter of the government shutdown of 2013. Talk about a blocker! We had a product release scheduled for late October that the shutdown would have totally derailed. Federal employees were forbidden to work during that time, but our contractors were already paid, so they continued on. Fortunately, we prioritized the backlog and did enough story planning to allow our contractors to continue working in the absence of the ScrumMaster, Product Owner, and other resources. In the end we launched the product in time for a major conference!


Two years and counting, we haven’t looked back and continue to practice Agile Scrum!

Our ODDI Teams now follow an Agile process built around the ‘4D approach’ to product development: Discovery – Design – Develop – Deliver. Our teams work in two-week ‘Sprint Cycles’ with the goal of delivering a completed feature or function at the end of each Sprint that can be tested for acceptance and adds value toward reaching the established goals of the project.  This process has enabled us to deliver projects on time, on budget and of the highest value to our end users and audiences.

Personal note

I hope these lessons prove useful to the adoption of Agile in your organization. If you have any questions, by all means post them to the Agile for Government Leadership LinkedIn group. We’d love to hear your comments and concerns. We’re here to help!

About Agile Government Leadership


By bringing applied Agile practices to government, we want to redefine the culture of local, state and federal public sector service delivery across all aspects of government. We will work with Agile professionals and organizations to support their work in getting Agile infused into government processes. We will foster a spirit of openness and mentor those new to Agile so that they have the necessary practical advice, resources, tools and community support for successful deployment. Through Agile Government Leadership, we will create a responsive, engaged government that more efficiently and effectively serves its citizens.

Connect with AGL