It’s no secret that government organizations face efficiency challenges. With hurdles like complex bureaucracy, a commitment to transparency and required agreement across agencies with differing missions, government organizations aren’t exactly set up for blazing-fast progress.
Though tech companies face an entirely unique set of challenges, the ability to act quickly and efficiently in the face of nearly constant change is required for survival. As a mechanical engineer by training, I choose to manage all my teams with the same precision and objectivity of an engineering team. What this means in practice is that we’ve implemented what’s called an “agile methodology.”
An agile methodology hasn’t only made us more efficient, but has also greatly improved our ability to accurately predict bandwidth, as well as forecast what we can feasibly achieve over a given period of time. There’s no reason government agencies can’t do the same.
The benefits of an agile methodology
First, agile methodology allows for frequent reprioritization. “Waterfall methodology,” the work-flow standard across most government agencies, accounts for numerous dependencies and is geared towards long-term success, making it very difficult for an organization to change direction in the middle of a project. Agile provides frequent feedback to ensure that teams are always working on what’s most important.
Second, it helps teams measure the amount of work your team is accomplishing in a given time period. This helps those teams make accurate predictions when estimating future work capabilities, which prevents humans – notoriously bad at estimating the time a task will take – from overcommitting and under delivering.
Third, it improves resource utilization. A waterfall project may have a team member committed to a long-term task, while their counterpart has nothing to do. An agile project will be filled with small, contained tasks that can be accomplished by any team member available.
What are sprints?
In the agile world, a sprint is a period of time where team members commit to completing a finite amount of work. In the beginning of the sprint, the team defines the workload that a given project entails, and sets a deadline for completion. At the end of the sprint, the team reflects on what they accomplished and why they may have not completed everything they intended.
Short sprints – typically lasting around one week – allow teams to increase responsiveness and frequently reprioritize. Longer sprints – two weeks or longer – allow for teams to commit to bigger, meatier tasks that require a little more momentum to complete. Either way, the sprint framework establishes more opportunities to prioritize: a team can be confident that they’re generally working on the most important task at any given time.
How do I decide what work goes in a sprint?
In order to decide how to most effectively segment a project into sprints, we use a technique called “pokering” to assign “story points,” which outlines what we’re preparing to accomplish. The number of story points describes how much total work will be required. The reason we use story points, as opposed to minutes or hours, is because humans are notoriously bad at estimating the time it takes to accomplish a task. Story points quantify effort as opposed to time.
To define what a baseline story point is for your team, find a small task that takes everybody roughly the same amount of time to complete. For us, that well-understood task is writing a retrospective (a review of the lessons learned from some project that we can reference in the future). If a retrospective is one story point, we may say that writing a new travel policy will take five story points, or the equivalent of writing five retrospectives.
From there you poker, or assign the story points. Our team votes at the end of each week to assign the number of story points to each task. While maybe nerdy, we only select story points that exist in the Fibonacci sequence (1, 2, 3, 5, 8, 13…). The reason for this is that tasks become increasingly harder to estimate as they increase in size, so we force ourselves to add additional story points to account for that uncertainty. AKA “it will take you longer than you think.”
As you track how many tasks you complete each week, you’ll be able to measure your team’s “velocity,” i.e. the amount of work an individual or a team can get done in a given period of time. As you continue working through sprints, it should be clear that velocity helps you commit to the right amount of work and avoid over-committing.
Using sprints in government agencies
Hopefully, I’ve convinced you that sprints have real applicability in government agencies, with the potential to speed up what are otherwise monolithic, intimidating projects. Between improving predictably and allowing for more opportunities to re-prioritize the hundreds of tasks on a team’s plate, taking the steps outlined above can really help agencies move more quickly and more confidently.
Do you think your team could benefit from adopting an agile methodology? Check out some of the resources below to learn more about how sprints can help teams move faster and ultimately get more done.
Sprints are the Secret to Getting More Done
Agile Project Management: The Sprint Methodology
Matthew Polega is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.
Leave a Reply
You must be logged in to post a comment.