Agile Profile is a regular feature profiling leaders in agile government.
NYC Council Member
Why did you choose Agile, especially for a non-software environment?
Most people think of government as slow and bureaucratic, but that isn’t a required feature. In fact, it is a bug, mostly tied to old models that were successful in the industrial era. The predominant governing model was the “waterfall method,” an approach that allows for ample input at the beginning of a project, but little—if any—during implementation or once the project is complete. Government must adapt from this industrial model to what it more closely resembles: an information and services based model that allows for continuous feedback along the way.
When I began serving as a New York City Council Member, I brought this goal to re-orient government with me. The only problem was that I was working with a team as well as co-workers in government who were used to or expecting the old model of governance, particularly from me. It was important to the goals we wanted to achieve together to adopt a system that would help us get there and that everyone could understand— and that was Agile.
In any given project for government, there will be multiple points of failure, foreseen and unforeseen, along the way. Through a waterfall method, projects often never get done or that get done in a manner that disappoints. Through Agile, the team is able to plan ahead and adapt as failure is managed into overall success.
12 Principles of Agile Government
(modified from the original “Twelve Principles of Agile Software“)
- Our highest priority is to satisfy the constituent through early and continuous delivery of valuable services.
- Welcome changing circumstances, even late in implementation. Agile processes harness change for the constituent’s advantage.
- Deliver working services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Constituents and government must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.
- Working services are the primary measure of progress.
- Agile processes promote sustainable development. The government and constituents should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Following the Agile workflow, when taking on a project, my team first identifies whether it will satisfy the constituency, identifies likely and unlikely challenges and thresholds for changes to the project, begins the project providing initial drafts using a process that allows other team members to track progress, checks in with constituents requesting the project frequently, provides support internally among team members and requests support from constituency when needed, checking in regularly online and face to face. We deliver a working project followed by reflection on success and failure during the project with opportunities for improvement on the next project.
Did you see positive results immediately or did it take time?
Agile takes time to learn, time to implement, time to do correctly, time for the culture to permeate, and time for the final step of reflection, which provides iterative improvement to bring positive improvement to the work environment.
Our method for team reflection on how to become more effective, then tuning and adjusting its behavior accordingly, follows the retrospective model on which we were trained by CivicActions. The first retrospective was tough as we began to change the way we think about how we work and reorient. By the second retrospective team members came in with specific changes that helped get our government office to the productive place it is now. Subsequent retrospectives have brought on fine tuning that often corrects new problems that have come up or previous problems that might have slipped between the cracks during previous retrospectives.
What challenges did you face, and how did you overcome them?
A big challenge has been to get around the expectations of a hierarchical, regimental, bureaucratic organization, and the struggle with our office’s changing course on a project. Most people are used to project assignment then success or failure, not project assignment and collaboratively working together until the project is a success. Team members can feel frustrated to continually face failure on a project only to have the project change in order to overcome that failure. Once the team has been through enough projects to understand Agile, we become increasingly ready to respond to changes.
As a team leader, I have also found that team members are unsure of how to accomplish tasks and ultimate goals of the project. I have found that providing an outline of the project along with predicted points of failure and likely project changes provides the big picture team members need to adapt to Agile.
What resources do you recommend to government leaders who want to get started with Agile?
Training, training and more training. When I first got elected, we adopted Agile, but we didn’t institute it correctly or fully. While we got most of the way there, key aspects were missing and while team members understood what we were doing they didn’t understand why we were doing it. As frustration with Agile grew, we decided to have a staff training from an Agile champion from CivicActions, where I had been first trained. That Agile training made all the difference, resulted in buy-in from the team, and adoption of the full Agile toolset.