When people talk “agile,” in general, they are talking software development. Most of the basic tenets of Agile Methodology were not founded in software, though – there was iterative design and production, stand up meetings, and various methods to predict effort and track progress long before software was being coded. Some of the “lean” methodology appears to have come out of the software/startup world, but if you look hard enough, you will likely find someone doing something similar in the past.

However, these systems and guides flourished when applied to areas that were in most need – specifically, small teams and startup businesses who were forced to produce more than the sum of their parts, and who could not afford to spend many weeks or months planning and designing before getting to market.

It has become clear to me, over the last few years, that the ability to work iteratively, and to be able to pivot quickly when necessary, can be especially powerful in larger organizations and municipalities. Of course, there are plenty of projects that necessitate a traditional “waterfall” process (please do not manage that bridge re-build using Agile!), but the employees that we work with, who communicate daily with citizens, can see great benefit leveraging aspects of Agile.

This is NOT Your Parents’ Muni!

There was a time when most municipalities were small enough to be keenly aware of what the populace needed, or had enough person-to-person communication on a regular basis that it was clear what their focus should be from day-to-day. Even with all of our “communication” tools today, those days are over.

Even smaller municipalities have a difficult time understanding the sentiment and needs of the larger populace at any given time. Communities appear to be more divided, have many, many more channels available to connect with other citizens and communicate more discreetly, and are bombarded by 24 x 7 media and news, that can shift opinions in minutes – not days or weeks. There were few that could have foreseen this landscape 30 or 40 years ago.

Having the ability for your “street teams” to be able to hear, react, and clearly communicate with the people they serve is invaluable. Something as simple as a daily stand-up can keep your staff on the same page, allow them support from the rest of the team as needed, and brace themselves for what would have otherwise been an unexpected fly-in.

Sprint. And Then Sprint Again.

It seems silly to use sprints for regularly scheduled work, but we all know that week-to-week, there are surprises, emergency requests, and coverage necessary for employees who are out of the office. Using sprints to manage requests, and set expectations can go a very long way toward your team taking true ownership of tasks and understanding that they are being listened to on a regular basis. It will also help you to understand exactly how much work is able to be completed from sprint to sprint (velocity), identify bottlenecks, and support your team more thoroughly. Sprint meetings do not have to be hours long, they do not necessitate a certified scrum master, and they are extremely adaptable to your team, your organization, and what your overarching goals and objectives are.

User Stories Are Powerful. Prioritization Is Necessary.

In all of my experience with project and product management (longer than I care to admit), simple user stories may be one of the most powerful tools I’ve come across. Before being introduced to Agile and the magic of the user story, often taken directly from a user request, there were sales folks and user testing and product experts and the owner’s brother and on and on…

Having requests captured directly from the users of your services and then converting them to user stories that your staff can work on is immensely powerful. You are likely to find that once you begin this process, you are excited to connect even more with your users – they tell you exactly what they need and you just deliver it in the way that best suits your team… Genius!

But, into every life a little rain must fall… And being able to prioritize, ruthlessly, is a necessity. You will not be able to deliver on every request. Sometimes they are fully set aside because they only impact a small number of users in a minimal way. Sometimes there is not budget to deliver on a request that may delight a large part of your community. Other times, you will not have the resources necessary to accomplish what you would like for your users.

This is life. We are forced to make choices. Most people understand this, and if you have an ongoing dialog with your users, they are likely to understand and appreciate the transparency.

You Don’t Have To Be Agile To Be “Agile”

There are various Agile tools and processes, and many people who are experts who have lots of rules. However, you can be more agile in your day-to-day work, and your service delivery, without having to be completely and totally Agile. Find the tools that work for you and implement them. Empower your employees to take control of how work is managed, scheduled and prioritized. Be transparent with your community, and sprint toward your next objective.

At the very least, stand up every morning with your team, discuss what happened yesterday, what is going to happen today, and ask if they’re experiencing any challenges, roadblocks, or just need a hand with something specific.

Good communication starts with those closest to us, and it can be a viral act. Staying as agile as possible is always a good bet – whether you specifically leverage Agile, or not.

As always, if we can help you and your team, don’t hesitate to contact us.