Category Archives: neat!

Use a P.H.E.E.L. blog for better team communications


Projects are much healthier when there’s a single, unambiguous canonical source of truth for all the work we’ve done. We call this a "PHEEL" blog, which is to say any work product which might fall into the following categories:

  • Plans,
  • Hypotheses,
  • Explorations,
  • Experiments, and
  • Learnings

Ought to be delivered here. Depending on the team, you may elect to add "Decisions" to the list, or manage them in an ADR.

This record ought to be 1) immutable, 2) chronological, 3) narrative, and 4) comment-able, so we often choose to use blogging software. The critical factor is Team Adoption: this only works when "post to the PHEELblog" becomes the default vector for any and all deliverables; if it feels like extra work, it won’t happen.

Continue reading

Magical Meeting Stories: A “Responsible Recipe” for the Fewest Possible Meetings

My buddy Douglas has been exploring different approaches to meetings, and I had a blast discussing some of the ideas laid down in A Responsible Recipe for the Fewest Possible Meetings, which led into some of the facilitation ideas covered in 7 Best Practices for Facilitating Agile Retrospectives.

Check it out and let me know what you think!

John Perry Barlow, RIP.


Years ago, I volunteered at the Personal Democracy Forum conference. The volunteer coordinator was one of those people you fell instantly in love with, almost otherworldly, her feet barely touched the floor. I spent the day sitting at a table with another volunteer, doing volunteer-y things, helping people along with the conference, talking occasionally to Micah and Andrew, the organizers.

At the end of the day, the coordinator came by: “we’re all having drinks upstairs, you two should come.”

Tired, exhilarated, grubby, we ascended to the much-fancier-than-expected bar and joined the others, where the coordinator was holding court, deftly hosting a dozen or so out-of-place volunteers, making us feel comfortable, as if we knew each other. Then:

“Oh! Meet my dad!”

John Perry Barlow appeared to tower over us. I was awed by the man. I’d admired him ever since I’d read A Declaration of the Independence of Cyberspace, followed the EFF, and only later put together that his name was also familiar from the Grateful Dead. I introduced myself in turn, unusually starstruck. Barlow chatted gamely for a few minutes and then excused himself.

Not long after, Andrew or Micah came over—”Jon, come over here, there’s someone you should talk to.” They led me to a cordoned off section where Barlow was sitting with Craig Newmark. “John, meet Jon—you’ll have a lot to talk about.” The next 45 minutes crackled with intensity and adrenaline and our excitement at the latent possibilities of the intersection of technology and civics, of what the future held.

I rode the subway home, ecstatic, thinking “I can’t believe this is my life”.

I never spoke to Barlow again, but always looked forward to the next time I would. He was as close as I get to a hero. Goodbye John.


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!