Three Small Steps You Can Take to Reboot Agile in Your Organization
This past summer, 18F held an agile workshop for the National Technical Information Service (NTIS), part of the U.S. Department of Commerce. An agency with roots going back to World War II, NTIS is facing a future that requires a strategic realignment towards open data and services. This strategic alignment will also require that NTIS operate in a more nimble, proactive fashion when working with partners in the public and private sectors.
In order to support NTIS’ success in their new mission, it was important to us to support the adoption of business practices that future partners would expect. Our goal was to re-introduce agile techniques into existing processes through small, rapid incremental changes. We believed that even small changes could have a big impact on transparency, accountability, and communication over the long term.
So, we worked with NTIS to host a workshop. Since many of the workshop participants had taken a course or two on agile before, we knew we weren’t introducing a new topic. We focused on learning what was working and what wasn’t, and identified simple tasks we could use to exercise our agile muscles. The workshop was the first step towards helping us understand how and where to reboot agile processes within the organization.
Step one: Identify what’s already working, and what isn’t
In order to better understand what was working and what wasn’t, we asked our workshop participants to vocalize their “hopes and fears.” It’s easy to think of all the reasons a particular idea won’t work, but once we documented them many of the “fears” were somewhat hypothetical and abstract. We acknowledged those while focusing on items that were actually causing issues in the business process. Where possible, we tried to find a solution from people in the room that could remove or modify an idea to make it more manageable. In the same way, participants shared their hopes for ideas and overall outcome.
Step two: Pick a few small, simple tasks to complete
Next, we asked participants to identify things that would make their day-to-day operations work just a bit better. We focused on ideas that were discrete and specific and encouraged participants to break longer-term goals (improving and streamlining business processes) into smaller tasks (develop an agenda template for team meetings). As participants narrowed down on an idea, we asked them to specifically identify who would benefit from the completion of the task and identify the value of it. Once someone had developed their idea, they presented it to the group. When common themes emerged (such as communications), we grouped those ideas together.
As popular ideas surfaced, we formed teams to develop user stories and acceptance criteria for common ideas. Acceptance criteria were framed as being able to answer the question “how will I know when things are done?” The acceptance criteria helped us understand when and how we would know a task was complete, and evaluate the results.
Once we identified discrete tasks, we put them on separate cards on a kanban board. A kanban board is a simple tool whereby tasks are organized, grouped, and tracked across a segment of time, or sprints. As these tasks moved forward, we could use the dedicated cards to monitor progress:
Step three: Monitor your progress
Over the next few weeks, we integrated the tasks identified during the workshop into our sprint process and monitored our progress. We also experimented in how we worked together, stopping things that weren’t working, and building on things that did.
The results, while imperfect, were encouraging. Tasks were being completed across the self-organized teams; not always as quickly as we had originally envisioned, but participants were seeing first-hand the value of breaking larger tasks into smaller ones, self-assigning responsibilities across teams, and enforcing a level of accountability to report on progress. In essence, a few small agile tools and techniques were helpful in removing confusion from processes and shortening how long it took to complete a task.
Through the process, we learned that incremental improvement is still improvement, and sometimes tools can be a distraction. We were reminded that teams are often different, with varying levels of comfort for tools; kanban board on a whiteboard can be just as effective as an electronic version. Uncertainty and fear of new business processes will always be there, but they can be mitigated if they make things easier, and gradually introducing agile processes can encourage broader adoption.
What we learned
Agile doesn’t have to be a “rip and replace” process. Perhaps one of the more challenging aspects of adopting agile techniques into existing projects is the idea that doing so will increase uncertainty, add work, delay progress, and confuse participants. The truth is that uncertainty and fear are already there — agile is helping to root these issues out, recognize their nature, and mitigate against them. Small, rapid incremental fixes (like the introduction of a kanban board) may still have a big impact on process and team productivity while introducing an easier way to track them.
Do what works. If productivity on your team is increasing because you’ve found a modified set of management tools that work well for you, keep doing what you’re doing. It’s easy to get distracted with the type of tools and forget about the process. As long as you have concurrence and participation amongst your team and can address issues quickly, you can continue to foster a productive environment.
Listen to your team. A core tenet of agile is the participatory process, transparency, and accountability required in order to be able to successfully deliver in small increments. A formal process and vision from management will help remove inertia barriers, and those processes that involve employees are more likely to address their needs. “False starts” are a risk — building momentum in the right direction and sticking to it is important, so buy-in before a formal process is put in place may help to avoid conflicts requiring a lot of course correction later.
Looking for more? Check out 18F’s Agile Principles and Practices guide, and see our other posts on agile.
This post was originally published on the 18F blog.
