A few years ago I was at the home of an artist friend who also works as a high-level software developer for a small but well-regarded software company. As I was leaving, I noticed that the wall behind his computer was covered with a well-organized grid of multicolored sticky notes, each scrawled with a cryptic instruction. I asked him what it was and he said “That’s my ‘kanban.’” Kanban, I learned, was a simple productivity tool that he and his developer buddies used to get things done: to-dos on the left column, work-in-progress in the middle column, completed work in the right column, color coding to separate categories of tasks. I chalked it up as alpha-geek life hacking and filed it under Curiosities.

In the spring of 2013 I encountered a much larger kanban on a whiteboard in the basement offices of New York Public Library Digital Labs, where another artist-cum-technologist friend works. As he described his team’s development process, he referenced a number of odd-sounding words and concepts like “scrum,” “sprints,” “stand-ups,” and (my favorite) “planning poker.” All of these, he explained, were tools that made up a larger concept known as agile software development, or agile for short. Creating software is a complex undertaking, and the agile methodology allowed his team to break their work into manageable pieces, work iteratively, empower team members, and incorporate feedback on the fly. It sounded a lot like how devised theater gets made, and I wondered whether this alien technology (management methods are really a form of social technology) could be used in worlds outside of software development.

Fast forward to the fall of 2013. The Alliance of Resident Theatres had just been awarded a significant three-year grant from the Scherman Foundation Katharine S. and Axel G. Rosin Fund to translate the ArtsPool business plan into a functioning agency. As we began working in earnest, we quickly realized that this new agency’s core purpose — a cooperative pool of administrative resources owned by its clients – involved a level of complexity that was not very well-suited to a traditional command-and-control approach. At the same time, we recognized the need for some internal structure to formalize the horizontal peer-to-peer way of working that had naturally emerged among the development team. Around that time, Zappos was making waves in the news with its announcement that it was transitioning to a “holacracy” model and planned to eliminate all job titles in the company by the end of 2014. Holacracy itself is an interesting model (think of a series of interlocking circles), but what Zappos’ switch really represents is a formalization of the agile management practices that the company has already been using. Zappos, we learned, was not alone. Other companies such as Twitter and Whole Foods had already begun to hack the alien technology of agile to make it work for things other than building software.

The flexibility that is baked into the agile approach was a natural fit for the complexity we faced as we began to develop ArtsPool’s systems, so we made a collective decision to move to an agile framework.

Worlds Colliding

I use the phrase “alien technology” here partly in jest, but also to highlight the attitude of many people and organizations when they have their first close encounter with a new idea. Whether it is a device, a piece of software, a language, or a concept, a thing is alien to us until it becomes useful to us or a critical mass of our peers. In the 1950s, arts organizations were encouraged to adopt a technology that was alien to them at the time: the corporate model. This growth-driven upward path toward institutionalization served the field well for a time and has since become enshrined by funders, governments, and organizations themselves as the one true path. Recently, however, this model has begun to shift dramatically under our feet as for-profit companies — under constant pressure to innovate or die — have gotten experimental. In fact, some of the most successful companies of the new economy are built upon concepts — e.g. sharing, openness, social capital, free products, etc. — that were once alien to them but that give them a distinct advantage in a world that is increasingly distributed, networked, and complex. (See David Sheingold’s recent post “Arts and the Sharing Economy”). The Rockefeller Foundation, our project’s first funder, has recognized this and recently began implementing an “agile transformation” in various areas of its work and planning. Nonprofits are beginning to see the need to evolve, and agile can help.

So What is Agile, Really?

Agile was pioneered by software developers in the early 2000s who wanted to create nimble, adaptive products that could respond more directly to customer needs. They envisioned agile as an iterative and incremental process where products evolve through collaboration between self-organizing teams and end users themselves.

Agile’s core principles are outlined in the 68-word Manifesto for Agile Software Development.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In an even tinier nutshell: people matter most, so listen to what customers and employees want and collaborate with them to give them better products faster.

Agile was created in response to traditional “waterfall” approach, which tries to predict customer needs and releases product in one big launch after a long period of planning and development.
waterfall-light

Agile, by contrast, is built on the concept of iterative and timeboxed loops — often referred to as sprints. Agile sprints contain microscopic versions of waterfall’s discover-design-build-test sequence, but they incorporate feedback from stakeholders so that plans can adapt as real-world needs change.
agile-light-970px

Minimum Viable Product

Agile is also organized around the concept of Minimum Viable Product (MVP), a strategy for developing products that provide the exact features that customers want.

A minimum viable product has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. [Wikipedia]

The minimum viable product approach is invaluable to organizations trying to do a lot with a little. Startup culture has already integrated agile into its cultural DNA for this very reason, and nonprofits would be wise to take a page from the ways agile has benefited their cash-strapped peers in the tech sector.

Development teams can adapt to challenges on the fly. Agile is often employed when trying to solve a complex problem where “you don’t know what you don’t know.”

Management can mitigate risk by keeping failures small and on a short time horizon. Non-viable products and services are identified early before they eat up a large investment of resources.

Failure can be leveraged for competitive advantage by involving customers in the process of improving a product or service.

Customers are able to use working products and services much earlier in the development cycle and at lower cost of entry.


At ArtsPool, we embrace the exploration of alien technologies and believe that our field can be made stronger, more sustainable, and more agile by looking at what is happening beyond our own borders. Some excellent writing has already been done by Gwydion Suilebhan of HowlRound, Andrew Taylor of The Artful Manager and Andy Horwitz’s Ephemeral Objects blog to begin mapping ideas like agile, minimum viable product, and object-oriented programming onto the arts, but there is still much more territory to explore.

What is an alien technology that you think could be useful in the arts or the broader nonprofit sector? Leave us a comment below or drop us a line via the contact form to sign up for updates on future developments.

  • richak
    • Max Dana

      I heard of Extreme Programming in the context of learning about agile but I hadn’t yet encountered Extreme Project Management. I particularly like this bit from your link: “Underlying XP are the values of simplicity, communication, feedback, and courage…”

  • Scott550

    Sounds like a sure way to be NOT innovative. Leadership requires guts and experience. And decision making. Not endless rounds of “feelings” to be shared. I’m happy to see this trend coming to a very fast, useless end.