This is part 1 of a 3 part series. Part 1 is focused on how software development methodologies can be applied to community development.

Jeff Seigler from Revitalize or Die posted this a while ago on social media (slightly redacted for brevity):

“It isn’t that a community can’t sort out what to do, it is the actual “doing it” that is the problem. So providing city leaders with the answers seems like the right course of action, but it turns out, this isn’t as helpful as you might think. I can tell city council how to address vacancy, but I can’t make them do it.

We can stop looking for answers when it comes to community revitalization, because they are all there. We have to focus on the process. How do we actually get cities to implement the changes needed? This is where we must focus our efforts. This is how we can bring about real change and go about the business of improving the lives of residents.”

This is the first time in my software development career that I’ve felt prepared to take on a community development project! Let me explain.

Software is never “done”. Communities are never “done” either. They are simply an ever evolving snapshot in time.

Software development projects are all about the people; the resources that are tasked with implementing a particular system or feature. In a community, a project may require resources, but is all about the people planning and executing on a vision.

Large scale software development projects have the tendency to have time and cost overruns if things are uncertain during implementation. Sound familiar?

Hopefully by now, you get my point. Many communities have a comprehensive plan, but haven’t planned on how to execute on a process that achieves the goals outlined in their plan.

In part 1 of this 3 part series of articles, I’ll be introducing Agile Software Development, a methodology that transformed how teams implement software. This is a framework that is used by thousands of software development teams all over the world, and in more recent years has been applied in other disciplines with similar success.

What is Agile?

Agile is a framework for a set of practices to deliver a product that leads to quality, maturity, and repeatability. Note that this is a framework of practices, and not a script that you can execute upon to ensure that you can do these things.

It’s important to understand why we want a new process in the first place. In software development, poor planning leads to rework. Depending on the phase of the project (architecture, design, implementation) the cost of that rework can be catastrophic on your budget and your team. The process should lead to:

1. Mentorship, where team members can shadow and learn from senior leaders, and everyone can learn from past mistakes.
2. Conflict resolution, where everyone understands how to approach conflict and expectations are set on how to properly resolve conflict.
3. Continuous improvement, where feedback is encouraged and the team defines tactics to make themselves better over time.

There are some pitfalls (what we call anti-patterns) that we’re trying to avoid in software development. Tell me if these sound familiar:

• Hero culture. Community leaders are expected to orchestrate and execute on a vision where they may lack proper time, resources, or trust of the people they work with (likely a mix of all of these). This leads to overwork and burnout. Hero culture needs to be replaced with mentorship and teamwork.
• Blame and shame. Teams need to take failures as learning opportunities and not reason to publicly place blame on a single contributor. Teams need to shift mentality from blaming a single person to a failure by the team.
• External interference. These are those unforeseen things (usually people) that interfere with your work while you are executing upon it. It’s important to identify this external interference and have strategies in place for managing this when you are actively in the middle of working on other priorities.

Agile, Waterfall, and Comprehensive Plans

This section is devoted to discussing the Comprehensive Plan that you likely have in your town or district.

Prior to Agile Software Development being in style, most large-scale software projects were completed through what is termed “Waterfall” software development. Waterfall assumes that there is a lockstep process of requirements gathering, architecture and design, code implementation, testing, and delivery. If an issue is discovered in the process of working on a waterfall project, it is likely that you would have to wait for an entire software delivery before that issue could be resolved. If the issue was found early in the process (requirements or design), the impact of that issue could be catastrophic. This is why the software industry has shifted towards agile development: To fail fast, iterate quickly, deliver often, and save its teams time and money.

Waterfall development is especially lousy at mitigating for changing requirements. If you’ve gotten this far, you can see how Waterfall development and Comprehensive Plans share a lot of characteristics. We must find a way to circumvent the long tail of Comprehensive Plans to find quicker ways to make change in our communities.

Introducing Scrum

Some of the items I’ll talk about below came from here and some are based on my own experience.

What is Scrum? Scrum is the most widely adopted version of Agile development. The term Scrum was chosen in its reference to Rugby, where a scrum of teammates are working together in an orchestrated fashion to achieve their goals (to score goals, in fact). The principles of transparency, inspection, and adaptation are at the heart of optimizing the value of the Scrum team’s work. The five scrum values (courage, focus, commitment, respect, and openness) enable the transparency, inspect, and adapt principles.

Given my experience, you NEED the following three things to consistently happen in a Scrum team to be successful:

1. Safe Space. You need to give you and your team a space where any and all ideas are allowed to be brought up. Open communication should be welcomed and expected.
2. Fail Fast. This requires that you iterate often to identify when things aren’t going well so you can course correct quickly and not waste additional time.
3. Commit. If you take nothing else away from this article, the key to the process is to make a commitment to the team to complete the work. If you are leading this effort, it’s your responsibility to communicate this to your team regularly. 

The work you have to put in

We’ll refer to this section as the 3 C’s: Capacity, complexity, and communication. These are all prerequisites to kicking off your new process.

Capacity

Having an understanding of your capacity as a team is critical, as this will help you immediately understand:

• Who is your team? Do you have your team defined? Are they full time or part time?
• What are they capable of? Do you know their work history and skills? Can you put them in a position to do work where they will be the most successful and/or enjoy the work they are doing?
• Do you need outside resources? Will outside consultants, volunteers, etc be part of your work plan?

Although not directly related, it’s also important to understand who your community stakeholders are, as they can be allies in helping you expand your capacity as new challenges arise and you lack the skills to complete work.

Complexity

You can’t work on what you don’t understand. You need to bring order to chaos. The Stacey model summarizes in the groups the complexity drivers of a problem: requirements to achieve, technology to use and people involved in development or use. In short: the better you understand what you’re doing, the simpler a task becomes, and the more certain you’ll be in completing it.

Key to reducing complexity is creating a definition of “Done”, a practice that many people struggle with. There is no black and white answer for this, and typically varies based on the task. The important factor is defining Acceptance Criteria that allows you to review and verify the results of work that has been completed in order for you to have that definition of Done and to call a task completed.

One of the key practices in Agile is reducing complexity. We do this through breaking complex projects into a series of smaller tasks that can be completed during a sprint.

Communication

State your intent both internally and externally. A lot of times, you work to make changes to how you are doing things and you neglect to tell people about it. This is a mistake. Stating your intent about a process change 1) adds accountability both internally and externally and 2) opens a dialogue with the community and your stakeholders to ask additional questions.

Also, make it clear what you want to accomplish; Help people understand WHY you are making a process change. You may receive pushback, but doing this will help you see who is in alignment with you and who will be your detractors.

Stay Tuned for Part 2!

In Scrum, a sprint is an amount of work that the Scrum team commits to complete over a negotiated period of time. As a Scrum team, you will iterate over many sprints and (hopefully) improve your process (and throughput) over time as you learn from your previous work. In part 2 of this series, we’ll walk through organizing the work for your Scrum team and what a typical sprint looks like.