Agile in other contexts
Many moons ago, I chatted with a woman about utilizing agile in other contexts and have since wanted to see it in action in a non-tech environment. I recently got a grant for a technology-fuelled neighborhood garden and we’ve been doing a bit of preliminary research into our users’ needs. Since this is a fairly low-key project, I’ve had a bit of time to explore the topic and came across a Green Streets Game workshop that sounded much like participatory design meets gamification. Essentially, it empowers neighborhood residents to collaboratively come up with a possible future for their street/hyperlocal neighborhood. In fact, the description of the game really reminded me of Gamestorming, a book that describes many ways of engaging teams through play. Curious about how the game might work, I signed up.
Warm Up Exercise
After arriving at the workshop, we warmed up by answering a few questions about our own neighborhood and then performing them charades-style:
- What does “liveability” mean to you and what does it look like?
- What’s the best thing about the street you live on?
- What would you improve on the street you live on?
This served not to just break the ice (acting out borrowing a cup of sugar from your neighbor can do that), but also get you to start thinking about features you personally find important. I could see how kicking off any project could benefit from a quick Q&A-charades exercise like this.
The Green Streets Game
The “game” itself was really quite simple: to figure out as a team how to transform a specific city street into a park and what the “features” of that park might look like. I would imagine that the game is meant to be played by the users (neighborhood residents). However, it was easy enough to role-play, i.e. imagine who would be using the street and empathize with them. It was interesting how unlike most design projects there were no constraints–apparently the City of Vancouver does not guarantee street parking to residents. There were just things that we could choose to consider (or not).
Following this, we each got three “points” to vote with on the board which was broken up into several categories such as Greening, Local Food, Group Activites etc. Each category had a bundle of cards assigned to it, “features” such as Fruit Trees, BBQ pits, Public Art. (I’m sure dot voting is familiar to anyone who’s done agile).
We spent a minute or two using up our points by voting with a dot. From this, we were able to count up the total dots and prioritize the categories.
Then depending on the total amount of points a category received, we could choose as a group the same number of feature cards. Much like sifting through a backlog (or product wishlist), this prompted discussion, debates about pros/cons and idea-generation. (I wish I jotted down the features we settled on, but there were 2 rain gardens, fruit trees and a community message board).
After settling on all of the features, we were then each given a mini map of the street. We were given 10 minutes to individually sketch in how we would implement those features–it was like a super fast assumption prototype. Here is mine:
We then each got to present our design, and then we did some affinity mapping. One map was devoted to common themes and the other was to highlight interesting, unique ideas/designs. We then discussed what we liked about the new ideas and then along with the common themes, we worked together on one large map to blend together all of our ideas. Think of this as a “Version 2” protoype and that concluded our workshop.
Things I wondered
It was really fun to see something very agile-like in action for such a low-tech design problem. We were a pretty laid-back bunch with similar ideas, so I’d be interested to see how this works with a more divided group…or one that has very verbal polar opposites…or a quiet group that isn’t terribly engaged. We were also a fairly small group–how would this translate to a much larger one? Would there be point where it would get too unwieldy? Would you ever succumb to the dreaded “design by committee”? Also, it being so hyperlocalized, how does a design like this solve for larger infrastructure (high-level vision) problems?
I suspect that the answers here would also have a lot in common with agile!