Attract More Funding By Accelerating Your Nonprofit’s Mission with Scrum

Your roadmap to cost-effectively leverage Scrum and thrive with an Agile mindset.

My friends, I would like nothing more than for your nonprofit organization to not only succeed but to thrive. Indeed, in today’s political climate, it's absolutely imperative.

There is an ideal world. And, then there is reality. Most of us live in the latter. I know I do.

Nonprofits need funding to stay afloat. The unfortunate reality is that 90% of nonprofits are small, competing for funds against the larger more “corporate” 10% who are taking humongous bites out of a shrinking pie.

However, smaller nonprofits can leverage Scrum to level the playing field. I believe it will become a pivotal business practice, turning the tide and making THE difference in a more balanced dividing of the pie.

Nonprofits need to be run like a business. What is now distinguishing thriving for-profit companies from those withering away is an Agile mindset. And, within this, the most popular framework used to address today’s complex, adaptive problems is the lightweight Scrum framework.

This is the second in a two-part series. In the first, I shared from my perspective as the former CEO and Founder of Hope Xchange Nonprofit. I presented a sadly-missed opportunity to save lives and improve mental health outcomes for a most vulnerable population, LGBTQIA+ youth diagnosed with bipolar disorder who are unquestionably at the highest risk for suicide. Hope Xchange could have given them a reason to stay. We did not. But, I’m convinced the outcome would have been different if we had used Scrum to launch our HOPE for LGBTQIA+ program rather than traditional waterfall project management. For more on why I fervently believe this, I invite you to read Part One: Saving Lives By Using Scrum.

In this second part, I’m sharing from my perspective as now a Certified Scrum Master with over 25 years of startup and entrepreneurial experience in the for-profit sector. By adopting an Agile mindset and demonstrating Scrum’s value with an in-house pilot project in your nonprofit, you will standout to potential funders. And, in this dog-eat-dog world, you must absolutely show them that not only can you accelerate delivering on your mission but you know how to run your nonprofit like a thriving for-profit business.

To maximize the impact of limited resources and to stay flexible and innovative with both program and fundraising initiatives, follow these three rules to succeed:

1. adopt an Agile mindset and Scrum framework,
2. purchase a white board and sticky notes,
3. and, start sprinting following the roadmap below.

Before we dig deeper, if you need more convincing on how Agile/Scrum is making a dramatic difference in both for- and not-for-profit sectors, Part 1 presents more data on this topic. Or, simply ask yourself the question that Jeff Sutherland (co-creator of Scrum) posed in his seminal book, SCRUM: The Art of Doing Twice the Work in Half the Time:

whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually something people want. And, question whether there are ways to improve how you’re doing what you’re doing, any ways of doing it better and faster and what might keep you from doing that?

Let’s Get Down to Running Your Nonprofit with an Agile Mindset and Launch Your Scrum Pilot Project. Let's Get Sprinting.

As the video below shows, the goal of each Sprint in a Scrum is to deliver a “done” product increment. In our context, the goal is delivering an incremental and tangible “step-forward,” with that step-forward contingent on what type of pilot project you decide to take on to demonstrate Scrum’s value to both internal and external stakeholders. More on that to come.

Your first Sprint begins with Sprint Planning. This event is mission critical to the success of your business initiative. For that reason, we’re going to go out-of-the-box (or Scrum framework) here … but, just this once.

Usually only the Scrum team attends Sprint Planning but in this first Sprint ONLY we are going to allow other key stakeholders such as the CEO, CFO, program leads and whomever else is keen to take part in shaping the pilot to attend. If anyone on your Board already buys into this, invite them too, particularly if they are knowledgable about Agile and Scrum! And, it’s also the case that the Scrum Team itself will be self-selected during this event so that’s another reason for the larger crowd.

During Sprint planning, five important questions need to be collaboratively discussed and answered (and, don’t panic, I’ve given you helpful tips for each one below):

1. What is a good Scrum pilot project?
2. Who will play the role of the Product Owner and Scrum Master and who will be on your Development Team?
3. What homework should the Scrum Team do during this first Sprint and before subsequent Sprints begin?
4. What is the appropriate duration for your Sprints, including this first one?
5. What is the plan to demonstrate business value? (i.e., How do you compare the Scrum pilot outcome to business as usual? What benchmark(s) will you use?)

Regardless of your answers to these questions, the goal of your first Sprint is to develop a trained Scrum Team. Your team needs to be prepared to take on subsequent time-boxed Sprints to iteratively and incrementally deliver the selected pilot project. As you move through the Sprints, the project scope will be refined in a Product Backlog — ordered list of desired outcomes or features (which I recommend he/she formats as User Stories) — that is owned by your new Product Owner.

Tips for Answering Sprint Planning Questions

Selecting your pilot project. When thinking about an appropriate pilot project, don’t go overboard. Keep it simple and pick something manageable that you already planned to undertake, whether it be developing a new smallish program, improving upon an existing program, or embarking on a social-media, cause-awareness campaign.

Picking your Scrum Team — Product Owner, Scrum Master and Development Team. The Product Owner is responsible for the business value of what your team produces, ongoing visioning, ordering the Product Backlog for dependency and priority, and budgeting and dates. If you’re selecting a new program or program enhancement, the Program Manager is the right person for the job. Note that this has to be a single person, not a committee, and this person has ultimate authority over the product/program.

The Scrum Master ensures the team is functional and productive, leading with influence rather than authority. Most small nonprofits can’t afford an experienced Certified Scrum Master, so look inside for someone who is good at coaching, mentoring and facilitating. This individual should also know how to empower the team and needs to be given the authority to remove any impediments that get in the way of your development team getting work done. (Once you demonstrate the value of Scrum, consider additional training for your Scrum Master. There are a lot of options out there however, I would recommend the Certified ScrumMaster training offered by the Scrum Alliance.)

The development team self-organizes to get the work done, has no titles other than “team member” and must be cross-functional (albeit, some nonprofits may not have the staff diversity to achieve this latter goal but, again, we are living in the real word here, so just do the best you can to accomplish this). According to Scrum Guide 2017, the team should be small enough to remain nimble and large enough to complete significant work during the Sprint. Fewer than three members decreases interaction and results in smaller productivity gains. More than nine requires too much coordination. Seven is the sweet spot.

Recommended Scrum Team Homework and Free Collaboration Tools. The definitive guide to Scrum by co-creators Jeff Sutherland and Ken Schwaber is all of 19 pages and describes Scrum roles, events, artifacts and the rules that bind them together. You can download it for free here. But, don’t get me wrong. While this is a lightweight framework and simple to understand, it is indeed, as they say, difficult to master. However, it’s not impossible; and, as your team moves through each Sprint, they will continually improve and pick up more and more speed (or velocity as Scrum Masters like to call it).

If your team members are more visual learners, in addition to reading the Scrum Guide and to reinforce the material, I would strongly suggest they also view the free Scrum Alliance e-Learning Scrum modules.

Many Scrum teams use a rolling white board and sticky notes. And, this is one of my three rules to success above. If your team is more technical and/or you have some virtual remote members, also utilize free tools such as Trello for collaboration and organization. In addition, there are many free Scrum software tools that include items such Burndown Charts, a graphical representation of the rate at which work is completed and how much work remains to be done. Charts such as these make the work of the team visible to the rest of the organization, enabling one of the three key pillars of Scrum, transparency.

Selecting the Right Duration for Your Sprints. Sprints, the heartbeat of Scrum, are the container for all the Scrum inspect and adapt loops. Sprints are ‘time boxed’ to a maximum of one month in duration but the time allocated should be driven by the capacity of your team to accomplish the work that needs to done each Sprint. Short sprints are frequently used in for-profits but, in reality, nonprofits are stretched way too thin so longer durations may be required.

Also keep in mind that once the Sprint is underway, no new work can be pulled in. If the development team finds itself overcommitted, it must renegotiate with the Product Owner and push work back to the Product Backlog so as not to compromise meeting the Sprint Goal.

Because the very first Sprint is unconventional in its purpose, the duration is decided on-the-fly and should be long enough to ensure all homework is done! Moving forward however, all subsequent Sprints should be consistent in duration, with the length decided up-front and fixed.

Here’s an example of what your Scrum approach would look like if you opted for five Sprints with a program increment release after each. Client feedback is also solicited and interwoven into your Product Backlog User Stories and ordering. Note this feedback could also be testimonials used in fundraising drives conducted in parallel with Sprints to support each of the program increments, rather than doing one big “all-or-nothing” fundraising push up-front to fund the entire program.

Demonstrating Business Value. How to best demonstrate the business value is contingent on what type of pilot project you opt to undertake. For example, if you’re launching a new program, in the past you may have used a traditional waterfall project management approach: 1) defined program need; 2) developed program requirements; 3) researched funding sources; 4) applied for grants and/or run online fundraising campaign 5) hired Program Director; 6) circled back to planning stage as to how to get the program off the ground, etc. Consider how long this would have realistically taken you to accomplish? Use this as your benchmark.

Time for Your Scrum Team to Take Over: The Sprint Continues

Your trained Scrum Team takes it from here, meeting in a Daily Scrum for 15 minutes, inspecting and adapting as they go along, with the Scrum Master making sure there are no impediments in the way. Sticky notes on the your White Board are moved from “To Do” to “In Progress” to “Done.” An illustrative example of a Scrum Board from the first part of my series is shown below.

Internal stakeholders are invited back at the tail end of the Sprint to the Sprint Review where the development team demonstrates to the Product Owner and key stakeholders what was accomplished during the Sprint and the highest-value Product Backlog items (or User Stories) to be tackled in the next Sprint are agreed upon.

The Scrum Team then holds a Sprint Retrospective. This final Sprint event is one of the most important parts of Scrum as, when done well, it enables your team to continuously improve Sprint after Sprint. The team collaboratively and openly discusses ways to improve the product/program and processes, with at least one item identified for continuous improvement brought into the subsequent Sprint.

Immediately thereafter, the next Sprint kicks off and you’re off and running again.

What Have You Got to Lose? Accelerate to Attract More Funding.

I fervently belief nonprofits can accelerate both human effort and successfully deliver higher-value, life-changing programs and services that are urgently needed faster.

As noted at the outset, Hope Xchange Nonprofit, while agile in mindset, did not leverage Scrum. We paid dearly and our doors are now closed. I strongly urge you to learn from my misstep.

What have you got to lose from adopting an Agile mindset and running a Scrum pilot following this roadmap? Accelerate your mission and attract more funding.

Wishing you a prosperous and thriving journey forward.