Implementing Agile in a Non-Profit Environment
Applying Agile in a non-profit context requires recognition of a near-universal truth: non-profits are notoriously underfunded and understaffed, leaving individuals wearing many hats and mostly in fire-fighting mode. This leaves very few resources for any type of process improvement, even when individuals and organizations are receptive to a new way of working. But this means that Agile can have tremendous benefits within the non-profit sector, even if it looks a bit different than the traditional IT-Agile models.
My initial attempt at applying Agile for non-profit began several years ago when I volunteered to help an organization with their strategic planning efforts. Having already been a volunteer in other areas, I was able to reach out to one of the leaders on their volunteer board to better understand their current planning and implementation process.
I discovered that their team was thorough with planning, albeit in a traditional big-plan upfront manner, and good about having open discussions, but there was little room to adapt once their plan met real-world disruptions. While a lot of time was spent on the actual planning, they had no way to track the day-to-day activities that often were areas of multiple responsibilities.
With a bit of trial and error, we managed to transition this all-volunteer non-profit towards a more Agile approach to both discovery and delivery. From this and other subsequent efforts, there are three key lessons I have learned to consider when transforming from the traditional IT-based Agile concept to one that better fits with a non-profit model: understand why, determine when and visualize how.
In order to ensure quick realization of value, everyone involved needs to develop a shared understanding on why their organization is pursuing Agile. Since gold stars are not given for “achieving” Agile, usually organizations see Agile as a route to achieve a particular goal, whether it is something specific like better planning for a repeatable annual event, or something more abstract like increased board engagement.
Especially given the resource constraints, non-profit organizations should start by taking into account the following assumptions as part of the planning:
- Where is the organization now? What is the current state, in terms of both planning and actual doing?
- Where does the organization want to be? What is the overall goal?
- What does the organization think matters? Is there a specific cultural objective that needs to be maintained, such as an overall sense of team engagement, or a specific stakeholder who needs to be satisfied?
- How does the organization expect to get there? Does the organization think the path being followed is correct? How is effectiveness in reaching goals being measured?
Developing shared understanding on these key elements initially will help determine both the specifics of an agile implementation, as well as the continued validation of its effectiveness.
Quantify the When
Getting organizations accustomed to pursuing any process in an incremental, iterative is a key element in transitioning to an Agile approach.
Instead of having a “big” planning session, breaking it up into smaller increments, like a Sprint planning session should be considered. For example, if a yearly planning session is the norm, it might be feasible to break those sessions into a quarterly cadence. Or, if monthly planning sessions are more standard, transitioning to weekly sessions should be considered. Trying to go from multi-year planning to weekly would be too overwhelming for everyone involved.
Deconstruct goals from macro to micro level, with micro being whatever time segment makes the most sense for the organization. I often use variations on user story mapping techniques to help people understand how to chunk big pieces of work into smaller deliverables. Techniques such as impact mapping to determine which specific actions might have the highest value can also be used.
Visualization of Workflow
Once the time segments are decided and goals have been deconstructed into smaller actionable items, the next part involves visualization of the actual workflow.
When people are working in groups, a lot of assumptions are made about who is doing what and how what one person does connects with what another person is doing. Is the task dependent – does someone else’s work stop until it is done? Or, can they only go so far until another step is complete?
Many times in a non-profit environment, these types of dependencies and interconnections are not articulated very well. This is mostly because people spend so much time putting out fires along with having limited resources. In other words, they are only able to deal with issues as they come up.
For example, let’s say things are broken down into quarterly segments with an annual conference as the end goal. The steps that need to be taken to get to the end goal each quarter should be visually defined and what team members are responsible for the tasks and processes should be determined.
A Scrum or Kanban board are excellent examples of how to enable this visualization, whether it is via an electronic or physical board. Shared visualization facilitates both the mechanics and the mindset of collaboration and dependency management.
Once an organization has visualized their workflow and have started working in this adapted Agile way, the work is not quite done! Inspecting and adapting on a regular (weekly) basis will help ensure that this new approach is actually is being followed and is sustainable. As with any other Agile transition, change is hard and the journey does not always follow a direct path forward. The occasional backslide will happen, but this is when the value of the above three-pronged approach will be realized.
Knowing why will enable the organization to identify when they have gotten off-track, having a time-box will prevent them from getting too far off-track, and having an actively maintained information radiator will ensure that everyone stays on the same page, or at least will let them know when they are not.
By Leila Rao – Agile Coach, AgileXtended