Building with Atoms, Building with Bits

Engineering is an old discipline.


“Pyramids” by David Bolton, licensed under CC-BY2.0.

Very old.

Building with Atoms

The difference between building for digital and traditional modes of building is the difference between atoms and bits. For traditional engineers and designers who build with atoms, planning is often orders of magnitude less costly than building. Imagine what it takes to build a bridge or a stealth bomber. With these economics, it makes sense to plan first, and it’s crucial to get it right the first time. Only when planning is complete does it make sense to start building. These separate, distinct, serial phases are the heart of what agile software development calls “Waterfall”. Specialization is rewarded, so coordination among specialist groups (planners, builders, etc.) is crucial to minimizing idle time, so that hand-offs can occur in an orderly manner. In this world, predictability of timing and estimation is paramount.

Building with Bits

The digital world is different: the cost of planning and the cost of building is (roughly) the same—it’s certainly the same order-of-magnitude. Into this new world come new economies. Now that the cost of planning is as low as the cost of building, the imperative to Get It Right The First Time (Or Else!) disappears. Now, the important thing is getting it—something, anything—out into the world. Instead of having to model and predict whether you got it right, just get it out there and let the world tell you whether it’s good enough, and how to improve it. This is the fundamental change that makes agile software development possible, and leads to the great emphasis on experimentation, testing, and rapid iteration. In the old world we optimized for predictability. In this new world, we optimize to lower the cost-of-change.

How to build anything

So what does this mean? Agilists often disparage “waterfall” but it’s not as if traditional, Gantt-chart style planning is wrong or bad. (It’s responsible for the vast majority of planning and building—EVER.) Rather, Waterfall and Agile methods ought to be regarded as two different tools, optimal for different tasks.

Need to build in a domain where planning is much cheaper than building? Measure twice, cut once—waterfall is probably the right way to go. That doesn’t mean you can’t benefit from reducing the cost of change when possible, but it does mean that predictability ought to be prioritized over optimizing cost-of-change.

Building in a domain where planning and building cost about the same? Agile methodologies (which optimize for low cost of change) will give you a significant advantage.


A Crash Course for Non-Technical Stakeholders who need to Manage Product and App Development

Project Rhythm

How do you set priority, check progress, and stay focused on the right thing on the monthly and quarterly level? The Concepts of Pivotal Tracker video outlines that process in the context of Pivotal Labs’ style of Extreme Programming flavor of agile. A Responsible Recipe for the Fewest Possible Meetings goes on to specify a starting point for healthy team communications structure—enough so everyone knows what’s going on (or knows enough to probe more deeply), but not so much that unnecessary time is burned in expensive meetings.

Continue reading

Podcast: Designing for Agile is Product Management

I had a ton of fun with the folks at the This Is Product Management podcast chatting about agile, XP, design, and lots of other fun stuff. Go check it out!

Designing for Agile is Product Management

Jonathan Berger, former Associate Director of Product Design at Pivotal Labs, uncovers the pitfalls of the status quo in Agile environments and how borrowing concepts from extreme programming can enable product designers to operate more effectively.

(6:19) How can agile be applied to design?
(18:25) What is extreme programming and how can it be applied to design?
(29:48) How can product teams do to align design resources with development sprints?



Check it out and tell me what you think in the comments!

Types of Design

I just blogged about Types of Design over at the Pivotal Labs blog.

“Design” is a messy word, and describing which type of design you mean can be tricky. Sometimes it’s more helpful to describe types of design not as crisp definitions—”Visual Design looks pretty, and UX has boxes and arrows”—but instead in the spirit of Family Resemblance, i.e.:

things which may be thought to be connected by one things which may be thought to be connected by one essential common feature may in fact be connected by a series of overlapping similarities, where no one feature is common to all.

Check it out, and let me know what you think in the comments!

The Benefits of Pair Design

I just blogged about The Benefits of Pair Design over at the Pivotal Labs blog:


How is design different for Agile product development?

“Design” can mean many things, but designing products for Agile software development methodologies present distinctive challenges. Engineers build software more quickly (and change it more rapidly) than most…

Check it out, and let me know what you think in the comments!

InVision takes a look Inside the Design Team at Pivotal Labs


The fine folks at InVision did a nice interview and write-up of our design practice. Check it out!

Balanced Team Sunday Salon at Pivotal Labs

I just blogged about the Balanced Team Sunday Salon at Pivotal Labs over at the Pivotal Labs blog.

This Sunday Pivotal Labs hosted a Balanced Team Sunday Salon following the three-day LeanUX NYC conference. LeanUX was chock-full of amazing talks and workshops, and the ensuing sentiment was my brain hurts! The Balanced Team Sunday Salon was a chance to recover, process, and reflect. We started off with brunch: bagels and bellinis…

Check it out, and let me know what you think in the comments!