“Any chance we can meet this week rather than next?” This was Josh’s response to a suggestion to have a meeting next week to discuss next steps. This set into motion a series of events that illustrate the power of a number of agile principles, many of which are enabled by the adoption of evolutionary design.
Evolutionary Design is Joshua Kerievsky’s passion, and it is a practice we strongly embrace here at Industrial Logic. Here’s a recent story about an existing React Native app we are working on that augments our workshops with learning games. It started around Noon. We had the first version of the next game released for testing by 4 PM.
Ready, Aim, Fire
We had a meeting Friday morning before lunch to discuss the next steps. Josh proposed a new game idea. We agreed on two actionable steps:
- modifying an existing feature of the app,
- adding the new game.
He challenged us to apply principles of evolutionary design while working on it, and then we broke for lunch.
Clean up first
After lunch, we modified an existing feature because production feedback showed us it did not add value. Then, we deployed that change to production (Google Play and Apple App Store).
Don’t hesitate
We decided to start work on the new game we had discussed.
Start with a quick design discussion
We had only made a couple of decisions in our meeting with Josh regarding the new game:
- We wanted to make a mobile game based on a concept Josh shared with us.
- Josh wanted to explore how this might work on a mobile device to see if it would work, so the emphasis was on rapid feedback over polished, completed software.
We had an idea of how it could look, so we started with a Google Drawings doc Josh had copied for us that had some visualizations of his game. This was great because it already had icons and visualizations with the look and feel of the original game.
We mocked up a quick version of what the first screen could look like in Google Drawings. We discovered that you can use settings in Google Drawings to set the exact size of a shape and set it to the dimensions of an actual phone. Having decisions to make and being empowered to do so, we quickly decided to:
- Break game experience into multiple screens.
- Expect users to use portrait mode on a phone.
- Icons on the bottom, working area on top, so their hands won’t obscure the view.
- Clarify how this would go into the existing app instead of a new one.
- Decide to continue releasing to prod while incubating a new game.
- Deciding on the smallest possible thing we could do.
Work in small batch sizes to achieve value quickly
Brett suggested we start with a first commit that would be really small, just a way to enter into the game screen and then go back.
The next decision was how to do that in such a way that does not affect the functionality of the current app in production.
After deciding on a simple way to get into the new game, we looked at the smallest next step that would have value. Just the ability to go into the game screen and come back out.
We both thought, “Wouldn’t it be great if we could get Josh something he could look at today?”
Then Tim suggested we re-use the mockup we created earlier by capturing an image of it and displaying it on the screen when we navigate to it in the app.
Within a few minutes, we had created a commit to trunk that added a way to enter into the new game and show the mockup. We immediately pushed it into both Android and Apple iPhone test environments.
Here’s a timeline from that day:
You might ask, “What is the value of having a game you cannot play that only looks like a game?”
Well, I am glad you asked. As software developers, we often develop something according to spec and demo it only to have the stakeholders say, “I don’t want it to look like that.” You can rant at them for saying they wanted one thing but then changing their mind when they saw it, but that does not change the reality that, as a software developer, things change. Designing, building, and reviewing is known as a feedback cycle. This approach allows you to shorten that feedback cycle with less effort.
This is how we do Evolutionary Design. How are you getting quick feedback?
