Going Responsive with Agile Planning

“Three Simple Truths” from The Agile Samurai by Jonathan Rasmussen:

1. It is impossible to gather all the requirements at the beginning of a project.
2. Whatever requirements you do gather are guaranteed to change.
3. There will always be more to do than time and money will allow.

Woah. This blew my mind when I read it. To quote Ze Frank, “true fact.” If this is what agile is selling, I’m buying. If you’re unfamiliar, agile is an iterative planning process that requires you to be responsible and responsive to your learnings. Although it’s traditionally used by software developers, we started to ask ourselves if we could use it in conceptual planning for Bloomberg Connects.

The data we gather at each step informs the next one. Simple, right? [image source]

Because this project will have a great deal of impact on our entire visitor experience, from entry to exit, we wanted to be extremely deliberate and thoughtful in our process. We needed to challenge our assumptions and to admit we didn’t know what we didn’t know. We also needed to take it a step at a time and agile is all about thinking in small chunks. The entire process is based on not getting too far ahead of yourself.

To keep ourselves in check, we only used notecards to map out our plan. We didn’t want anything that felt or looked permanent. We carried these cards around on a board to presentations with the director and with staff and then pinned them up in my office for quick reference.

Adapting agile for content planning ended up being a really helpful process for organizing all the components of a project as big as this. We had to zero-in on one idea or question at a time, which kept it manageable. For each pilot we determined what we wanted know, how we would find out, what resources we would need, the duration of each pilot, and almost most importantly what we were not testing. The last point in particular was helpful to keep us focused and on track. We would also put down considerations for next steps (some were spot on and some weren’t) and the risks of each pilot, which always included the possibility of creating a negative visitor experience.

Our goal for the entire project was pinned at the top to remind us of the bird’s eye view while we were down in the weeds. As we learned from one pilot, we planned the next and added another set of cards. Eventually my corkboard looked like this.

It took some convincing to get staff on board with the process, but they were up for the task. We were asking everyone to think in weeks as opposed to years—a tall order for an institution like ours whose exhibition schedule, for example, is already fairly planned out into 2018. First we had convince our leaders of the merits of this approach and then we needed to get everyone behind moving at what seemed like an impossibly fast pace. It was also important to let everyone know that we really, truly, did not have a grand scheme in mind before embarking on our path. And we didn’t.

So what happens now that we have a direction? Well, we know the project will have three phases: the app, a physical presence in the building, and integration into our website, but we still don’t know all the details or how even the phases might overlap and inform each other. It’s very tempting now that we have a basic framework to plow ahead, but we are being extremely careful to continue to take it a step at a time—to test, evaluate, and iterate.

We are still using agile as we move forward for this project, and I hope will be able to use it for other projects in the future.