Writing Requirements on Wood
Not long ago, we had a contractor finish our basement to create a play space for our daughter. Since my life is a continual series of software projects, I was curious to see what I could learn by observing a real-world construction project. Overall, it’s got a lot in common with Lean UX.
The Three Key Lessons
The connection occurred to me when I was reflecting on our experience at Lean Day West this week. Our team had a front-row seat for insightful talks from Bill Scott, Farrah Bostic and many others. Jeff Gothelf posted his list of takeaways from the event, and we have a few of our own.
Document just enough, just when you need it
The contractor in our basement project wrote things down at the right moment, at the right level of detail, in the right place. In this picture, he left some notes for a carpenter written directly on the correct material to use, listing the tasks and placed in the spot the work needed to be done. It was a map, a task list and a spec all in one.
Are the documents in your company doing triple duty? How well do they help the next person complete her tasks? Do they just capture the decisions of the stakeholders? If the document was a person, what job would it be hired to do?
For the plumber, our contractor marked where to drill by drawing right on the concrete using the biggest Sharpie I’ve ever seen. I tried to get a photo of that as well, but they were too efficient (!) and started working before I had the chance. The X didn’t exist five minutes before it was needed, and didn’t exist five minutes after either.
In my experience, writing a detailed spec long before it’s executed is a fantastic way to waste tons of time. You’re wrong in ways you don’t even understand yet (you’re listing your assumptions, right?) and you don’t have the build team’s attention anyway. They’re busy with what’s needed for this sprint.
Use experienced people
The tradesmen were able to get by just fine without a 50-page spec partly because they were all talented, experienced professionals. They didn’t need to be spoon fed.
Similarly, prototyping and hypothesis testing isn’t a great place for rookies unless they’re as fast as someone with more experience. If you’re truly being Lean and prioritizing learning over building, you need to work quickly because you want to fail as fast as possible. Odds are, you’ll spend too much time explaining things to The New Guy.
Small teams, close together
There were a number of hectic but critical days where the trades were all together, working side-by-side in my basement. The plumbers and electricians performed a particularly intricate dance to hook up the vanity in the 5’ x 8’ bathroom. Goofy as it was, any other approach would have been far less efficient.
Are there times when many hands make light work? Sure. In the case of the basement, a team of painters with fancy spray guns attacked the walls and finished in two days. But that’s the exception rather than the rule; most jobs simply can’t be split a dozen ways.
Stay Lean and Mean
Are you building a product and running Lean? Gather a small team of experienced people and give them the info they need at the right moment. It’s “easy, peasy, lemon squeezy,” as my daughter likes to say.
Then she runs down to the new basement and makes a mess.
