What can world-changers learn from software developers?

This is the second of a three-part series in which I’ll share some lessons drawn from the world of software development that can be applied to the social good sector. Today’s post is about using data to make better decisions. Read the first part about recognizing obstacles to action for what they are here

One of the defining features of Scrum (the software development methodology we use here at Idealist) is the regular opportunity for “retrospectives.” Once a week the team gathers to talk about what went well during the previous week, and what we want to change for the next week.

The key here is the short cycles—it allows us to experiment with semi-crazy ideas, because we’re only committing to them for a week. If they don’t work, we throw ‘em out the next week. It’s very low risk.

shutterstock_97680683

Photo via Nomad_Soul on Shutterstock.

An obvious benefit of this “inspect and adapt” habit is that it allows us to continuously improve our processes. A less obvious benefit is that it creates a culture of empiricism. Whenever we can, we bring real data to the retrospective.

We might start off with an instinct or a hypothesis like, “I wonder if we’d get more done if we aimed higher next week” (which is a valid question, not a foregone conclusion).

We can then test that hypothesis immediately and a week later gather to look at the results. We aimed higher—did we or didn’t we get more done?

Inspect, adapt, change the world

Nonprofits and other worldchangers use inspect and adapt processes as well, of course. The staff at Single Stop USA, for example, are working to end poverty. They keep students in school by helping them and their families navigate the world of public benefits, providing them with access to tax preparation support in addition to legal and financial counseling.

Since their founding in 2001, Single Stop has continued to work towards that goal with laser-like focus, but understands that their approach must be nimble enough to evolve based on empirical data.

Nate Falkner is the Vice President of Strategy and says that Single Stop USA makes better use of data than any organization he’s worked with. For example, they’ve used data to identify potential partners to help distribute their programs.

Early on, they looked at studies that showed that programs that gave community college students at risk of dropping out just two to three hundred dollars would often mean the difference between staying in school and dropping out.

A lightbulb went off, and the Single Stop team realized community colleges were ideal partners. Single Stop’s programs could serve as a dropout prevention strategy for the colleges (on average, Single Stop clients receive benefits and services worth over $1,000), while the colleges could provide Single Stop with access to a large number of potential clients and an infrastructure through which to expand.

Similarly, after gathering data that showed the words “tax preparation support” carries less stigma than “government benefits” (think politically charged terms like “food stamps” and “welfare”), Single Stop refined its messaging to potential clients. They focused their outreach message on the tax preparation parts of their program, drawing in clients who later became interested in their other resources.

Let out your inner data nerd

When it comes to developing an “inspect and adapt” process, we recommend keeping the following in mind:

1. Schedule time for reflecting on process, and treat it as sacred.
It can be tempting to skip the retrospective when other things seem more pressing, but we’ve found that treating it as sacred has kept us sharp.

2. Minimize the risks associated with innovating on process.
We limit our experiments to one week, which allows us to try out some pretty dramatic ideas. You’ll often hear someone say, “It’s only for a week, guys” during our retrospective sessions. This reduces anxiety for people who tend to be averse to big changes.

3. Adapt the process; don’t move the goalposts.
As Nate says, “Our mission is ending poverty, and that doesn’t change. We’re being smart and nimble about how we approach that discussion and how we approach stakeholders on their terms.”

How have you used “inspect and adapt” techniques to innovate on your internal processes?

Tags: , , , , , ,



What can world-changers learn from software developers?

This is the first of a three part series in which I’ll share some lessons drawn from the world of software development that can be applied to the social good sector. Part one is about recognizing obstacles to action for what they are.

I work on the web development team here at Idealist. My business card has the title of “Scrum Master,” which sounds equal parts terrifying and mystifying (in reality, it’s neither). One of my primary responsibilities is to remove obstacles for our web developers.

Scrum” is one of several popular software development methodologies collectively known by the umbrella term “Agile.” Agile processes seek to address some of the issues inherent to highly complex projects such as software development, by providing a set of shared values, engineering principles, and communication methods.

As I’ve learned more about these methodologies, I’ve discovered there are many applications to the work that members of the Idealist community are engaged in every day. After all, what’s a more complex project than eradicating poverty, ending homelessness, or convincing world leaders to cooperate on climate change?

A technique for recognizing obstacles

Every morning, we have a 15-minute meeting called “the daily scrum” where each developer makes a commitment for the day, and talks about their obstacles.

One technique we use is making a list of certain words that we think might indicate a hidden obstacle, like “try,” “maybe,” and “hopefully.”

We write them on a whiteboard. Whenever a developer uses one of those words during the daily meeting, we call it out. For example, a developer might say, “Today I’ll try to finish the new blog feature…,” and the rest of the team will challenge him to explain why he’s only going to try.

This isn’t some Yoda-esque motivation strategy (“Do or do not. There is no try.”). Rather, it’s an attempt to understand what is causing the hesitation. Typically there’s an underlying obstacle, like the developer isn’t familiar with the relevant part of the code. Once that’s been articulated, we can work as a team to solve it—perhaps by having him pair up with another developer who’s more experienced with that part of the codebase.

shutterstock_130585973

Photo credit: Shutterstock

Applications for world-changing work

Identifying your own obstacles, or your organization’s, is a key step in any plan to change the world. Here are some strategies:

1. Make it a regular practice.
In Scrum, we ask ourselves every day what our obstacles are, and what’s getting in the way. In your context, this may be a weekly ritual, or something that you do at a twice-annual staff retreat.

2. Learn to recognize symptoms of hidden obstacles.
In the world of web development, there are a few common signs of unspoken obstacles: a general lack of progress, having more work “in progress” than there are developers on the team, or releasing buggy code. In the world of social good, the signs might include: not hitting your fundraising targets regularly, skipping writing your annual report to stakeholders, or getting unsatisfactory feedback from clients. Recognize these symptoms for what they are: evidence of some underlying obstacles.

3. Make obstacles visible.
Some Scrum teams have an “Impediments board” where they list their obstacles to action on index cards. Cards get removed when the impediment is removed. By making the obstacles visible, everyone sees them and they tend to get resolved faster.

4. Prioritize obstacles.
Not all obstacles are created equal. For example, an obstacle that is preventing your organization from receiving donations might be more important than something that prevents your organization from getting a new logo in time for your summer campaign. Some Scrum teams limit the number of obstacles “in play” at any one time. This forces you to prioritize, and choose the most significant obstacles to focus on.

5. Share responsibility.
A good Scrum Master will facilitate the removal of obstacles by creating a culture of shared team responsibility. Similarly, an executive director or project manager might be ultimately responsible for removing obstacles within an organization, but by empowering the team, they will be resolved more quickly.

We’ve found paying special attention to identifying and removing obstacles has greatly improved our development work at Idealist. What do you think? Do you have any tips or tricks for finding and resolving obstacles in your organization or projects?

p.s. Stay tuned for the next part of the series, where I’ll share some ideas for how to “inspect and adapt” on your internal processes.

Tags: , , ,