I returned to Brooklyn this week with a spring in my step from a great AMA Digital Marketing Day. I had the privilege of sharing the stage for the morning keynote with Belinda Waldock, an agile guru, and a stellar outgoing AMA chair, Jo Taylor, and I regaled attendees with an explanation of how we used agile at the Brooklyn Museum to develop our app, ASK. I spent the afternoon running two workshops with a total of about 60 fearless individuals who wanted to try their hand at agile planning. They did a fantastic job, and hopefully walked away feeling empowered to deploy some iterative thinking in their next project. I met some amazing people, was inspired by how other institutions are using agile thinking in their projects, and shared a glass (or two or three) of wine with the awesome members of the AMA staff and two of my fellows (shout out to Alison and Cat) at the after-party. All-in-all a great way to spend the day!
For the workshops, I prepared five scenarios inspired by projects undertaken by DMA fellows that I felt encapsulate the trends we face in the cultural sector and that I’ve heard during my time with Digital Marketing Academy and Audience Diversity Academy. Working in groups, participants planned an initial experiment to address their selected challenge: content, delivery method, audience, motivations, or resource allocation. Not surprisingly, the biggest struggle for many of the groups was clearing away the many ideas for solutions to the challenge and instead focusing on defining the challenge and then planning an experiment from there. This is, for me as well, the most challenging part of agile. So many of us are problem-solvers and idea-generators. You give us a challenge and we will rattle off half-a-dozen ideas for how to address it. That’s not quite what agile is about. It’s about eliminating the noise and tuning in to the single frequency, that single issue, and building from there. To that end, I provided the workshop participants with a “cheat sheet” for agile planning that encapsulates the thinking we used at the Brooklyn Museum. I share it below in the hopes that it will be useful for you too.
Agile Planning Tips & Tricks
Don’t be intimidated by agile planning. Like any process, breaking it down into steps will help as you learn how to adapt this approach to your next project.
Going through the process of thoughtfully building out your experiment can be very useful for shaping your thinking. Ideally this can be done in a small working group (no more than 5 people) comprised of those who will participate in running the experiment and/or are stakeholders in the results. If there are individuals that “must” be included, consider a small working group to plan the experiment and a small advisory group to act as a sounding board and help finalize the details. The most important questions to answer while planning any experiment are: How are you defining success? How will you measure it? A good experiment has a clear definition of success and a measureable outcome, at least in part.
To build your experiment, address the questions below starting with the first one. The others can be addressed in no particular order over the course of the planning session. Writing your responses on index cards or post-it notes can be useful here as a reminder to keep it scrappy.
- What are you trying to determine? Answer this in a single sentence or pose single question. Keep it focused. The answer goes on a card by itself.
- What are you not testing? This can sometimes be really helpful in defining what you are testing. For example, a test on delivery method will require content, but you are not testing the content itself so don’t let that be a distraction. The answer goes on a card by itself.
- What are the risks of the test? These are known factors you should consider as you plan your experiment. Ricks could include high traffic causing a web crash, incomplete analytics based on what you are testing, or a negative visitor experience due to potential confusion. It’s important to get these down on paper in part so you can plan how to address them if they come up (and can be addressed). These go on a card together.
- How will you run the test? In full agile-mode this is the story, and is often written from the user’s point-of-view. You are welcome to take that approach. The important aspect of this is answering, in detail, how you will run the experiment. Think simple, think scrappy. Include any A/B testing if required. You may need multiple cards for this portion.
- What do you need to accomplish the test? Realistically, jot down all the resources (time, money, staff, supplies) do you need to execute the test. Be inclusive. This is a chance to tweak the test to match available resources. You may need multiple cards for this.
- What are potential next steps? This is your chance to think one step ahead. If this happens, then you want to test x, but if that happens, you want to test y. Of course, z might happen, which is why you run tests to begin with! This should be one card only so you don’t get carried away thinking too far ahead.