Most nonprofits are interested in process improvements that will better enable them to accomplish their respective missions. However, major change can be intimidating and complicated to implement, especially if the organization isn’t quite sure what it needs to do differently or lacks the expertise to make it happen across the organization.
As a Senior Program Manager with AIM Consulting, I had the opportunity to assist a nonprofit with a major business transformation using Agile methodologies.
The nonprofit is an endowed charitable organization whose mission is to reduce or eliminate the need for foster care through direct services to children at risk of abuse or neglect. To achieve their strategic goals, they wanted to do two things: 1) overhaul their entire practice and 2) implement new technology that would allow social workers to better manage their cases.
Before AIM Consulting came into the picture, the nonprofit attempted to achieve these goals by treating each goal as its own project and running them simultaneously under separate project managers. They started the practice redesign by hiring a consulting company to create a new practice model–a narrative document that describes the goals and values of the organization and how they go about achieving their mission.
These early efforts proved frustrating. The people who best knew the organization were involved only sporadically in the process and there were prolonged delays. The practice model was created through a waterfall-like process of conducting interviews, drafting, redrafting, and editing. When the document was finally completed, it didn’t reflect the organization’s view of itself. After weeks and months with no results, leadership knew they needed help.
Realizing that they needed specialized expertise in program and project management, the nonprofit turned to AIM Consulting. I was brought into the organization as an expert with 30 years of experience building and managing programs for companies of all types. The nonprofit hadn’t considered using Agile before I came onboard, but a lot of techniques under the umbrella of Agile were perfectly suited to the problems the organization was struggling to solve.
What is Agile?
Agile is project methodology typically used in software development. It was conceived as an alternative to Waterfall methodology, a step-by-step process that relies heavily on documentation and has a long wait before a final product is delivered. In contrast, Agile stresses frequent delivery of “working software” through an iterative looping process of 1-4 week increments called “sprints”. Agile emphasizes collaboration and transparency, meaning that development teams and stakeholders work closely together so that everyone knows how the project is progressing and can collaborate quickly on changing needs.
Agile has taken the technology industry by storm and has since found application in other industries. It is especially applicable for big, thorny projects with unclear outcomes that are subject to change as new business needs are discovered.
Although the nonprofit was not developing software, they were developing their business–redefining all of their offerings and operations and implementing new tools to better serve children and families. This was a herculean undertaking that could only be successful through a disciplined approach to program and project management.
As Program Manager, my first task was to create a Program Charter that outlined the goals and broke down the total quantity of effort into three major streams of activity: 1) Redefining the practice, 2) Selecting and implementing a new Case Management System, and 3) Preparing the organization for widespread change. Accomplishing all three would be an interdisciplinary effort requiring participation from social services, research and IT, with over 50 resources across the organization participating over 18 months. The three streams of activity were broken down into 17 projects, most with specific deliverables, such as a new practice model.
As Scrum Master, I taught all team members the basics of Agile, using descriptions from The Scrum Guide by Scrum originators Jeff Sutherland and Ken Schwaber.
- Agile: A methodology that uses small, manageable increments of activity to develop a product.
- Scrum: A framework within which people can address complex problems while productively and creatively delivering products of the highest possible value.
- Scrum Master: The person responsible for ensuring that Scrum is understood and enacted according to Scrum theory, practices, and rules.
- Product Owner: The person responsible for maximizing the value of the product and the work of the Development Team.
- Team: The professionals who do the work of delivering a potentially reusable increment of a “done” product at the end of each sprint.
- Sprint: A time-box of one month or less during which a finished, useable and potentially releasable product increment is created.
- Sprint Planning: A meeting to decide the work to be performed in the sprint.
- Backlog: An ordered list of everything that might be needed in the product.
- Standup / Daily Scrum: A 15-minute meeting for the team to synchronize activities, inspect work done since the last daily meeting and create a plan for the next 24 hours.
- Sprint Review: A meeting to inspect the work completed at the end of the sprint and adapt the backlog for the next sprint.
- Sprint Retrospective: An opportunity for the team to inspect itself and create a plan for improvements to be enacted in the next Sprint.
Each team created and prioritized the backlog in their first sprint meeting. They did this by writing ideas down on cards, sticking the cards to the wall, and arranging and organizing them into prioritized groups of tasks. For example, the team on the practice manual project identified the creation of a Table of Contents as the first item in their backlog. Once the backlog was established, we used fixed sprint lengths and followed typical Agile processes, including the day 1 sprint planning, daily stand-up meetings, a 1-2 week sprint, an end-of-sprint review, and a retrospective at the end of the project.
The following factors were critical to success:
1) Involving Executive Leadership
One major obstruction to the success of an Agile project is lack of involvement from leadership. However, the nonprofit had strong commitment at the senior leadership level. At the beginning, I told the executive team that if this was going to work, they would need to give at least an hour of their time every two weeks to attend sprint reviews on what has been produced over the previous two weeks. They did this.
2) Dedicating the Right Resources
A common objection to Agile is that business people can’t be spared, but in the case of the nonprofit, the right people across the organization were sanctioned for the effort and dedicated to the task. Operating managers negotiated with executives on their output targets for the coming year, reduced the workloads of people dedicated to the strategic effort, and moved resources around to backfill positions where necessary.
3) Creating A Project Charter for Each Team
Although Agile stresses collaboration over documentation, some documentation is necessary. One thing that kept the teams focused and organized was the creation of a brief charter for each project. In the very first sprint meeting, each team had to create a 1-2 page document that stated the goals of the team. This charter had to be approved by stakeholders before any further activity commenced.
4) Getting the Product Owners Right
The Product Owner is the person who speaks for the customer. These were people in the organization who best understood what the children and families served by the organization needed. With a few exceptions, they were not executives. They were not even managers. They were social workers who were equipped to make key decisions for the team about tradeoffs, features, and priorities that would ensure that what resulted was what would best serve children, families and social workers.
The Product Owners took their responsibility seriously. When they couldn’t make team meetings due to conflicting responsibilities, they deputized proxies to be their eyes and ears and make sure that items were correctly prioritized and questions answered so the teams could keep producing.
5) Communicating the Purpose of Daily Standups
At first, not everyone understood the concept of a daily meeting where every participant was expected to show results. Team members were used to being assigned to committees where people attended, but didn’t necessarily produce. We developed a clear distinction: If you were coming to a sprint meeting, it was because you were accountable for something. Those that got away from the discipline of the daily standup would drift in different directions and would have to recommit to the process.
6) Demonstrating Success with an Early Win
When trying something new, it’s important to show that it is working. For most teams, success was completed work, not logged hours or dollars spent. The first win was the table of contents for the practice manual. The practice manual describes how social workers conduct their work with families–essentially a field manual. In the first sprint review, just two weeks from the kickoff, stakeholders got to see a table of contents that showed what the practice manual would cover. They also got to see that the teams were producing, that the sprint reviews were a valuable use of their time, and could visualize how the whole program was going to come together. This demonstrated how the Agile process was going to work.
The nonprofit successfully transformed its entire business practice, implemented a new case management system, and adopted a new business process with minimal disruption. Although not every team adopted Agile, it was largely Agile methodologies that enabled the organization to redesign its practice and transform operations from the ground up. In a review at the end of the program, participants wrote on notecards what worked the best and what worked the least. Agile was cited most often as a major component of success.
Whether your organization needs to completely transform its processes or is merely struggling with a single, complicated project, Agile may be the best approach. With specialization in program and project management and particular expertise in Agile transformation and adoption, AIM Consulting has the experience to help any organization overcome the challenges and achieve long-lasting results.