The Problem is the Problem

I was charmed and captivated by this post, called “You Are Solving the Wrong Problem.”

In the late 1950s, a British industrialist proposed a contest, inviting folks to build an airplane powered entirely by human effort. Many groups vied for the prize, spending months on complicated designs, only to have them fail spectacularly during actual testing.

Finally, after almost 20 years of failed solutions, a man named Paul MacCready pulled it off, building what would come to be known as the Gossamer Condor and the Gossamer Albatross. How did he do it? He realized that the problem was the problem:

Paul realized that what needed to be solved was not, in fact, human powered flight. That was a red herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminum tubing, and wire.

The first airplane didn’t work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, retest, relearn cycle went from months and years to hours and days.

Robert and I were talking about this last night, and he was telling me about agile software development. Read the link for more, but here’s a pertinent bit:

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle… This minimizes overall risk and allows the project to adapt to changes quickly.

(I’ve noticed this with software programs such as Things and Evernote. These programs update constantly… and are constantly getting better.)

What’s striking is that this story of Paul MacCready and the Gossamer aircraft came to me after a session meeting in which our elders figured this out intuitively: the problem was the problem as we’d (or I’d) defined it.

I inherited a committee structure at Tiny Church that is organized into 11 committees, headed by elders. As you can imagine, some of these function well as committees, some are committees of one person, and some are basically dormant. Some of these areas have huge, constant responsibilities; others are seasonal or sporadic. Add to that the complication of only 6 elders and 11 committees—that’s a lot of different hats. Not to mention the fact that people want opportunities to do ministry, but they don’t join a church to serve on a committee. (Especially when there’s a perception that once you’re on it, you’re on it forever.)

So I’ve felt for some time that a reorganization was necessary, but I was stumped how to slice and dice it. I polled friends, posted queries on Facebook, you name it. Do we organize by elements of our mission statement? Form sub-groups on session? Consolidate several committees?

I brought all of this to session last night and expected we’d do some general discussion and, at least, get the different roles and options on the table, but that it would take several months to come up with a new structure. But we ended up with a specific way forward. We’ve got our structure, and it’s an agile one. We began our Gossamer Condor.

In essence, the session will no longer staff committees. (Yippee!) In fact, at this point at least, we do not even have specific elder areas of responsibility. Instead, each month we will look at the calendar of upcoming ministry events at the church, as well as emerging opportunities that come up, and determine how those items can be best implemented: invite a specific person to make it happen? Oversee the formation of a short-term task group, with the elder serving as liaison?

Thus, in addition to being the visionary/spiritual leadership of the congregation, the session will be “dispatchers” of a sort—matching ministry opportunities with particular people with the gifts and availability to implement them at a particular moment in time.

We solved the right problem. Our problem isn’t finding the most appropriate structure for our session. Our problem is how to get the church’s ministry done.

What excited me is how can-do the session seemed to be at this approach. And this excitement was present in spite of the fact that we know problems will arise. If we’d spent months developing The Perfect Structure, those problems could be seen as a threat to all our hard work and easily ignored. But with an agile process, problems are essential information—necessary parts of making our processes better. With an agile process, we will be constantly evaluating and tweaking.

I’ll be sure to let you know how she flies.

Advertisements

13 thoughts on “The Problem is the Problem

  1. Mary Ann: I really like this. For the past few years, I have been encouraging the session to see their main responsibility to be to “enlarge participation, build community, and identify and develop new leaders.” They assumed their job was to “get things done.” That’s often done best (or at least most easily) by themselves or with a group of the usual suspects. This helps re-define the goal, and directs them toward solving a different problem.

  2. Keith Snyder says:

    Just glanced at the agile software link. I wonder how agile vs. waterfall applies to novel writing.

    • MaryAnn says:

      That’s an intriguing question. I’m not writing a novel, but at my writing group today I brought an essay-length piece that will fit… somewhere in the book. I don’t know where because I’m just generating content at this point and haven’t settled on a structure. And on the one hand this makes their job harder because they don’t know how any given piece fits into the overall picture. On the other hand, their comments on these pieces help me make good decisions about the structure.

      That feels somewhat agile. In fact, Robert talks about how the initial release of software is often very rudimentary and almost piecemeal, but getting it out there helps you gather info about what else the program needs to do.

      And I know at some point I will need to commit to a structure in order to get meaningful feedback from my writing group. I just hope I know when we’ve reached that point.

      • Keith Snyder says:

        I should probably just generate content until one of them is the end.

      • MaryAnn says:

        Robert clarified that the first release of software in agile is called the “minimally usable” release. It does just enough so ppl get where you’re going with it and can suggest what else it should do.

        He thought the analogy to novel-writing would be to write and share a short story that sums up the novel’s plot… but since that doesn’t seem like a productive way to go, the metaphor breaks down in that respect.

  3. I love this! Not only is the “new system” flexible, but it’s inherently dynamic, bringing more energy to the ministry itself.

  4. Bill Searight says:

    Unsure of where I come down on nFoG, I’m adding this blog entry to my approach to it. I’m not sure if the task force gave us the Albatross or the Condor, so I’m going to read more of their discussions about the problem they wanted to solve.

    Also, I’ve been considering Bruce Reyes-Chow’s flexible Session framework.
    https://docs.google.com/Doc?docid=0AcvMstGMoKNLZGR6NDR0ZDdfMzlnbjhwamozZg&hl=en
    Have you looked at it? Any thoughts?

    • MaryAnn says:

      I looked at the doc when I was conducting my research—it’s more developed than where we obviously are, but I like the stuff near the end—the proposed session meeting agenda and the yearly calendar.

  5. Rev Dr Mom says:

    Need to think about this one A LOT. I’m assuming your session = my vestry. I’m in a parish in which the laity are very passive because the previous very long-term priests have been very clerical-control centered. I don’t WANT to do everything nor is it in anyone’s best interest so I’ve been working the last year to rebuild a really non-existent committee structure with a vestry person on each committee. But I’ve also come to the realization that outside the vestry people are very good at getting specific tasks done but don’t want to commit to long-term things (like committees). So maybe we need to go back to the drawing board.

    But then I wonder—where does the vision come from to generate the tasks? We are very short on vision here, something else I’ve been trying to get folks invested in. Is it just the work of the Vestry? Eh. Lots to think about. And I am now going to read the Bruce Reyes-Chow link.

  6. Sarah E says:

    a term I heard yesterday comes to mind when I think of your way forward – flexagility. It’s fluid and responsive and yes you will get tied up in knots from time to time but it is relational and those in relationship will figure it out, and more. In some ways, it is also a self-facilitated peer group 🙂

  7. […] our session begins a new way of doing our work, appropriate delegation will be essential. This has some good ways of thinking about what stands in […]

  8. […] it some, but if it still doesn’t work, we call it a day and move on. (I’m all about agile ministry, […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s