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.
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 other 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.
