Archive for the ‘Agile’ tag
David Bland tweeted something today that I’ve heard/thought before, but reminded me of what the essence of both XP/Agile and Lean Startup are all about.
I’ve distilled this into a single meme image. Print this out and put it on your wall.
[Paraphrasing] There are lots of things we don’t know that we don’t know about [the project we were working on]. Agile is how we optimize our process for learning those things. – Ward Cunningham
One of the things that really changed how I thought about building software was learning about the Dunning-Kruger Effect. I didn’t know that’s what I was called, mind you, but I certainly had witnessed it and once it was explained, it made perfect sense. What is the Dunning-Kruger effect?
“people reach erroneous conclusions and make unfortunate choices but their incompetence robs them of the metacognitive ability to realize it.” - http://en.wikipedia.org/wiki/Dunning-kruger_effect
What does that have to do with Agile? Well, some of the seeds for Agile, at least from Kent Beck and Ward Cunningham’s influence came from the days when those two guys shared a lab and were partners in R&D at Tektronix. I’ve written about this before, but basically, their job was to come up with, every set period of time, some idea that Tektronix should pay a team of guys to develop out into a product or tool. So, KB and WC would come into work every morning and one of them would propose an idea and they would spend the morning trying to hack the idea into working software. If it wasn’t working, they’d go back to working on whatever was the last best idea, and then at the end of the time period, they always had something that worked that they could turn over as an idea. This is where some of the seeds of TDD, iteration, and other ideas that are now staples of Agile came from.
But why would you do that? Why would you essentially start over every morning? Well, as it turns out, humans are really bad at knowing what they don’t know. So why not come up with an idea and just work on that idea until you had something? Let’s explore that. . .
BDUF is for those that don’t understand the Dunning-Kruger Effect
I don’t feel like this is a very controversial topic (that might also be the other end of the K-D Effect) because I think this one has already won out. It certainly has in the ruby community. I’ll go ahead an explain it though. BDUF stands for “Big Design Up Front” and most non-enterprisy, non-corporate software teams know, you can’t design all of your code before you write your code. And the agilists out there will even say that the only way to write truly simple clean code is to write a test first. I hope this isn’t a big shock to anyone. If we examine why this is true, we pretty quickly get to a point where you say “we don’t know enough about the code to design the code without first writing some code”. In other words, we don’t know what we don’t know about the code yet, we have to learn what we don’t know and adapt our application architecture as we learn. I guess if you get a CS degree, you’ll run up against a whole set of folks that don’t believe this, but I’ll go out on a limb and say that most of those folks also don’t write much software. Anyway, suffice to say, we’ve got a whole set of practices, red-green-refactor, continuous integration and deployment, to optimize against doing BDUF (among other things, surely).
Specification Documents are for those that don’t understand the Dunning-Kruger Effect
Another example (I think more important and less widely accepted, and the real reason I wrote this post) of the optimization for all the “things you don’t know that you don’t know” in Agile is that we don’t write spec docs. We don’t start out a project with a giant document that spells out everything we’re going to build. That’s not to say no one knows what we’re building, or has a vision of what it looks like when it’s done, au-con-trair, that’s definite a recipe for disaster (and, I think, most people’s biggest fear that haven’t participated in an Agile project). We spend the time to write all of this down in whatever format we would need to give it to a developer and walk away. Why? Well it’s that damn Dunning-Kruger effect. You *can’t* actually write a good spec, and not only that, those that don’t know this are the ones that precisely think it’s possible. No matter how many lines of code you’ve written, or UI’s you’ve designed, or businesses you’ve started, you will never know enough about what you don’t know to write a document that will cover every edge case, angle, possibility, challenge and decision that has to be made to successfully create quality software.
I hear this lot when I tell people this: “But you can change your spec” or “Good specs allow for learning”. I’m sure you can and I’m sure they do. Change and learning is precisely what agile is all about and not just embracing change, but optimizing for it. You’re *always* going to change that spec. Every project I’ve ever been on, at one point or another, something was too hard or expensive to be worth it and we’ve always changed what we’re going to do. Most of the time, this something was a surprise. It wasn’t what we thought would be hard or even something we thought we needed to do! I’ll even go further to say that some of the more successful projects I’ve been on, not only did we optimize for learning things early, we optimized for being able to change things easily.
The problem with writing a spec and then changing it, however, is that usually this renders part of the spec useless, or worse yet, it renders useless some “real work” you have already done. There’s a million quips and anecdotes people use for this, “Fail fast. . .”, ”If you’re not embarrassed when you launch your project, you waited too long”, etc. The reason people say these things is precisely because they’ve experienced the Dunning-Kruger effect. They’ve written a spec or built software thinking they had their bases covered, that they knew things, but they didn’t end up knowing everything and not all of what they thought they knew ended up being true. And many of these people have come to the conclusion that if they would have done less planning, and got to implementing even faster, they would have learned important information that they didn’t know they didn’t know earlier and saved themselves work. XP is about optimizing for this in a technical setting, “The Lean Startup” is about optimizing for this in a marketing and product development setting.
Recently, a group of folks (including myself) from AboutUs.org attended a workshop called “Agile Product Design with Jeff Patton“. Jeff is a really smart guy who has been doing some great work to bring Agile software development techniques to the product design and user-centered design fields.
Let’s step back and look at how most software and websites are developed. Companies often start a new software development cycle by having their business people identify a market opportunity. The business analysts and marketing people sit around and come up with either a new product or a feature that they can sell to their customers. Then they get the designers in, who make a “sweet” interface for it. Finally, a big specification file, describing the new feature and how it’s supposed to work, gets handed off to the developers. They’re supposed to make it all work.
This is what software people call the waterfall, because each step pours into the next. There are many problems with this process, but the biggest is that if any of the assumptions made at any one step are wrong, you don’t know until you get to the end of the entire development cycle. You’ve wasted a lot of time and resources.
Another frequent consequence of the waterfall method is that the final product can vary significantly from what the business analysts thought they getting. That’s because there was no opportunity to check back with the business case during the development cycle.
Here at AboutUs, we’ve always used the Agile method of software development. Now, with Jeff’s help, we feel like we’ve got a very cool improvement to Agile that helps us define what we’re going to build, how it’s going to work, and how it’s going to deliver value.
The Product Shaped Hole
Jeff’s process starts out by identifying who your customers are. This is user-centered design. At AboutUs, we have identified 14-15 different types of customer who use our site, each for a different set of reasons. We have fleshed these types out into profiles that we call “personas.”
Next we started to identify which tasks each customer type wanted to perform on our site. These tasks range from “logging in to edit,” to “reviewing recent edits for abuse,” to using new features we are still developing or would like to develop.
We can take these tasks, turn them into “stories,” and build a “story map” that describes the personas and their activities. Our business goals govern the entire process. They tell us which personas matter, and therefore, which tasks matter. That in turns informs every development choice we make.
So what’s really cool about this story map is that it’s a physical object that everyone can see. It reminds us continually of our business goals and the people who use our site. It governs everything we do, right down to each small, actionable chunk of software, and each of these becomes its own particular story.
Some of these stories have been delivered — our site does lots of stuff already — and we still have plenty of stories we want to complete this week, next month and within the next year.
The coolest thing about this story map is that it’s still alive. You can see what’s done, what we still want to do, and, if you’re the type to read between the lines, what we haven’t thought about. And it’s those unfinished and unthought-of stories that are the “product shaped hole.”
This isn’t a complete description of Agile user-centered design. I haven’t covered paper-prototyping, sketchboarding, walking skeletons or other cool techniques. But story maps have really changed how I think about software and Agile, and it’s going to change how we build things at AboutUs.