This is Aaron and Mike. They work for a company called Workiva. Workiva makes a suite of products on a platform called Wdesk. It solves big problems for large companies, and it’s one of the biggest software-as-a-service companies you’ve likely never heard of.
Aaron and Mike look happy, don’t they? But that’s typical for people who’ve worked together to solve tough problems. Or could it be because the guy on the right has a beer in his hand? Nah, that’s not it. It’s that feeling from having solved a tough problem that’s making them happy. The beer is just a reward for solving the tough problem. If you don’t get beer, or an equivalent reward, for solving tough problems where you work, you should have a talk with someone about that.
For them, discovery started with framing the feature idea they were working with to really understand who it was for and why they were building it. Then they talked directly to customers to validate their guesses about how they were working today and what the real problems were. After that, they built simple prototypes. For Aaron and Mike, they were able to build simple electronic prototypes in Axure and test them with customers remotely—first to see if they valued the solution, and then to be confident that it was usable. For the feature they were working on, they didn’t feel like they needed to prototype in working software to learn what they needed.
After multiple iterations with simple prototypes, they finally felt confident they had something worth building. That may sound like a lot of work, but they did it all in about three days. Their last step was to create a backlog and a plan for delivering the feature. That’s their plan in the picture. It’s a good plan. And that’s why they’re happy.
It’s important to note that this map isn’t about a whole product, it’s just about a feature they’re adding to an existing product. That’s why it’s smaller than Gary’s in Chapter 1, or that of the Globo.com teams. I’m telling you this because some people mistakenly believe they need to map their whole product to make a small change, and they use that as a reason not to map.
Map only what you need to support your conversation.
To build this new feature, these two guys will need to build shared understanding with their team. Their team needs to be able to point out problems and possibilities for improvement, and to estimate how long it’s going to take. That’s what they built this final map for. They used it to tell the feature’s story—step by step, from the user’s perspective. Notice the printed screens injected into the map? They pointed at screens and highlighted details while walking through the map so those listening could better envision the solution. The people at Disney who walk through movies using a storyboard have nothing on these guys.
When team members asked why the screen behaves as it does, they had stories to tell about variations they’d tried, and how users behaved. When the team asked detailed questions about exactly what happens when data is entered, or information submitted, these guys had given it thought and could answer. Or, when they didn’t know, they discussed ideas with the team, and made notes on the prototypes or sticky notes in the model. They even added a couple of sticky notes for details they hadn’t thought of, but the team did. Aaron told me that the team spotted several technical dependencies that he and Mike would never have found.
Anyone who’s been in the software development game for any length of time knows that one of the biggest challenges is estimating how long development will actually take. I’m going to let you in on one of the best-kept secrets of good estimation:
The best estimates come from developers who really understand what they’re estimating.
There are lots of methods that promise to give more accurate estimates. I’m not going to cover any of those here. But I will tell you none of them work if the people building the software don’t have shared understanding with one another, and with those who envisioned it.
Building shared understanding shouldn’t be a well-kept secret about estimation. So you should go tell someone else right now.
The team at Workiva can’t really get away with building less at this point. They can’t do what Globo.com did in Chapter 2 and cut things away, because they’ve already validated that they need it all. When they were prototyping, they were able to cut away a lot and validate that their solution was still valuable to customers. But, when you look at their map, it’s cut into three slices.
“Why would they care?” you might ask. A third of what the customers want is sort of like delivering a third of a sports car. No one could drive it. But Mike is the product owner. He doesn’t get to walk away after he’s identified a good solution. His role changes now, and he’s a bit more like a director in a movie. He’s got to be there as every scene is shot. And he’s got to decide which scenes should be shot first, and which scenes get shot last. He knows that in the end the entire movie needs to come together and look like one coherent whole.
So Mike worked with his team to create a development plan. This is what they did: they sliced their map into three, crosscutting slices.
The first slice cuts all the way through the functionality. Once they build all those pieces, they can see the functionality working from end to end. It wouldn’t work in all the situations it needs to, and if they shipped to users this way, those users would howl. But Mike and his team will be able to see the software running end to end. They’ll be able to put real data in it to see how well it performs, and they could apply some automated testing tools to it to see how well it scales. They can learn a lot about the technical risks that might cause them trouble later on. They can be more confident going forward that they will be able to release on time. Or, at least they’ll spot the unforeseen challenges that would slow them down. I call this first slice a functional walking skeleton—a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”
They’ll layer on the second slice to build up the functionality—to get it closer to releasable. Along the way, they’re likely to learn some things they couldn’t predict. They may have overlooked some characteristics this feature should have—finer points that weren’t explored in the prototype. They may have found that the system just doesn’t perform the way they expected and some extra work will need to be done to get the speed they want out of it. These are the “predictably unpredictables”—a concept closely related to Donald Rumsfeld’s “unknown unknowns.” Don’t pretend they don’t exist. You know they do.
Finally, they’ll layer on the third slice to refine the feature, to make it as polished as it can be. They’ll also add in some of those unpredictable things.
Each of these slices isn’t a release to customers and users: it’s a milestone the team members will use to stop and take stock of where they are. From a user and customer perspective it’s incomplete, so save yourselves the embarrassment.
Mike and Aaron’s team estimated this feature to be about two months’ worth of work. Like Eric, they used two-week sprints, so it would take them four sprints. I guess they could have made four slices, one for each sprint, but they weren’t thinking of it that way. And you shouldn’t, either. Think of these slices as three different buckets with different learning goals for each. Decide which sprints or iterations they’ll go into when the time comes.
One thing that seems to be a secret, but really shouldn’t be, is that estimates are…estimated. Hit the Web and find any list of oxymorons. I’m confident you’ll find this term there: accurate estimate. If we knew exactly how long things would take, then we wouldn’t have called it an estimate, would we?
Ok, so here’s the other secret: the more frequently you measure, the better you get at predicting. If you commute to work every day, I suspect you’re pretty good at predicting how long it’ll take. If I asked you how long it’d take to get to a different address in roughly the same area, I’ll bet you could predict how long commuting there would take within plus or minus about 10 minutes. That’s the way estimation works.
By slicing large things into small things, we get more opportunities to measure. Of course, there’s some subtlety to this, but as a general principle, you’ll get better predictions if you’ve got more examples of how long similar things have taken to build.
As a product owner, Mike is ultimately on the hook for getting this feature released on time. He’s a good product owner, so he helps everyone in his small team take some ownership of that goal too. He treats these early estimates as his delivery budget.
With every small piece the team builds, they can measure how long that piece took to build. They treat what they’ve built as spending against their budget. They may find that they’re halfway through their budgeted time, but only a third of the way through building the feature. Certainly they didn’t expect that, but now they’re aware and they can do something about it. They could borrow some budget from other features they’re working on. Or there may be small changes they could make to the feature that won’t substantially change the benefit users get. Or they could just face the music and see what they can do to change expectations with the people they’ve promised delivery to.
Depending on how bad it is, they may all need more beer.
When slicing out a development strategy, they’ll look to tackle the things that may blow their budget as early as possible. Those are the risky things. And it’s conversations with the whole team that help spot them.
What Mike and Aaron have done is to follow a strategy used by artists to finish in time. It’s one I’ve used for years with software. And, when I first met my friends at Globo.com, I found it’s one they use, because as I mentioned before, if they’re late with cool, new interactive stuff for the Olympics, the Olympic committee won’t reschedule the Olympics. I’ll guess this strategy is one you even use routinely, without thinking.
Let me first explain what da Vinci doesn’t do. But, unfortunately, it’s too often what people building software do try to do.
Suppose you were da Vinci, and you wanted to create a painting and were working the way a naïve software team does. You might start with what you believe is a clear vision of the painting in your mind. Then you break up the painting into its parts. Let’s say you had five days to paint this painting. Every day you’d paint more parts. At the end of day five, huzzah!—you’re done! What could be simpler?
Only, it doesn’t work like that—at least not for artists. This way of creating things assumes our vision is correct and accurate. It also assumes something about the skill of the creator and her ability to precisely define parts without seeing them in context. If you do this in software development, it’s called an incremental strategy. It’s the way a bricklayer might build a wall. And it works if each piece is as regularly sized and well defined as a brick.
When I used to draw as a kid, I fell into this trap. I’d often be drawing some sort of animal and start with the head. I’d work on that ‘til it was perfect, then continue to draw the rest of the body—legs, tail, and so on. By the time I got close to done, I could see that the proportions of my animal had gotten a bit off. The head was too big, or too small for the rest of the body. The legs seem to be twisted at an odd angle. And the pose of the creature just seemed a bit stiff. At least, that was my perspective as a talented six-year-old—and all six-year-olds are talented artists.
It was later in life that I learned I’d benefit from sketching the whole composition first. From there I could get proportions right, and make changes to the pose of the creature. I’d maybe even reconsider what I was going to draw.
I wasn’t there with da Vinci, but I expect he did something much the same.
Even da Vinci would probably acknowledge that his vision wasn’t perfect, and that he’d learn something as he was creating the painting. On day one, I imagine he first sketched the composition, or maybe did a light underpainting. I can imagine him at this point making changes to the composition. “Hey, I think the smile is going to be an important part. I’ll move her hand away from her mouth. And those mountains in the background…too much.”
By midweek, da Vinci is adding lots of color and form to the painting, but he’s still making changes as he goes. By the end of the week, he knows he’s running out of time, so all his effort shifts to refining the painting. One wonders if the Mona Lisa missing her eyebrows was a deliberate choice, or if da Vinci simply ran out of time to add a new, fully refined feature.
Great art is never finished, only abandoned. — Leonardo da Vinci
That quote is attributed to da Vinci, and it speaks to the notion that we could continue to add and refine forever, but that, at some point, we need to deliver the product. And, if da Vinci’s work and that of lots of other artists are good examples, we—the people who appreciate the work—have no idea it was abandoned. To us, it looks finished.
An artist or author works this way. In fact, the people who put together the morning paper or evening news work this way. The people who create live theater work this way. Anyone who must deliver on a deadline, and learn as he goes, recognizes this strategy.
Use iterative thinking to evaluate and make changes to what you’ve already made.
In software development, iterate has two meanings. From a process perspective, it means to repeat the same process over and over. That’s why the development time-box used in Agile development is often called an iteration. But when you use this term to describe what you’re doing with the software you build, it means to evaluate and change it. And changing software after it’s built is too often seen as a failure. It’s where terms like bad requirements or scope creep get used to reprimand the people who made decisions about what to build. But we all know that change is a necessary result of learning.
Use incremental thinking to make additions.
Unfortunately, we can easily get trapped in the whirling eddies of iteration. So we’ve got to keep our eye on the calendar and keep incrementally adding more. The artist adds more not only by adding whole new things to a painting, but also by building up things that were already added.
You might do the same things in software by first creating a simple version of functionality without any extras. You might think of this as your sketch. After using the simple version, you’d build it up by adding more functionality to it. Over time, it builds up to be the finished version you and others may have originally envisioned. If things go really well, it builds up to something different than you originally envisioned, but better because it benefits from what you’ve learned.
This may hurt your head a bit, but I’m going to mix some metaphors here. I personally rely on a strategy based on a chess metaphor when creating software. I’m a crap chess player who barely knows how to play the game, so if I’m misusing the metaphor, you’re not allowed to write me and correct me. No matter how small the product or feature release, I prefer to slice my release backlog into three groups:
If you’ve discovered what you believe is a viable first release to customers and users, work together as a team to slice that first public release again into opening game, mid game, and endgame stories. The team creating the product is best at identifying where the risks and opportunities to learn are. They’ll feel the strongest ownership over the plan they create together.
That’s what Aaron and Mike did with the help of their whole development team. Look again at how happy they are.
In Chapter 3, Eric had to deal with the risk of identifying the wrong product. He used a strategy of slicing out releases that allowed him to put whole products in front of customers.
In this chapter, Aaron and Mike are focused on technical risk, the things that might blow their delivery schedule or cause the feature to cost much more than they expected. They won’t show what they end up with at the end of every cycle to customers and users because they already know it’s not sufficient. But they’ll take a good, hard look at it themselves and with their team, and use what they learn to safely steer the development of this feature.
It’s subtle, but you might have caught in Chapter 2 that Eric was taking two two-week sprints to build his next minimum viable product experiment. And he had to decide which things to build in the first sprint, and which to build in the second sprint. He used this kind of thinking to make those decisions. He and his team put the risky bits first—the parts that Eric or his team wanted to see working sooner so that they could course-correct before they put it in front of their customers.
You’ve seen four pretty good examples of building and using maps for different purposes. There are a lot more ways to use maps that we’ll explore in later chapters. But before you get too far, I want to show you my favorite trick for teaching others how to map. I promise if you try it, you’ll map like an expert from that moment on.
Let’s pick up there in Chapter 5.
 I got the idea for this simple visualization from John Armitage’s 2004 paper “Are Agile Methods Good for Design?” John describes approaching user experience design this way. I’m suggesting we carry the metaphor into the way we build as well.