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!

Advertisements

How To Maintain Separate Design and Development Backlogs

I just blogged about How To Maintain Separate Design and Development Backlogs over at the Pivotal Labs blog.

Previously, we discussed when to use different types of backlogs, categorized various types of stories, and described a general flow for agile design. In this post we won’t rehash that material, but instead will describe some of the practices specific to separate Design and Development backlogs.

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

UPDATE: Go read Part 1 How to Manage a Design Backlog and Part 2, How to Integrate Design in an Agile Backlog.

How To Integrate Design in an Agile Backlog

I just blogged about the How To Integrate Design in an Agile Backlog over at the Pivotal Labs blog.

WHEN SHOULD I USE AN INTEGRATED BACKLOG?

An integrated design backlog is appropriate for small- to medium-sized projects (i.e. teams which can be fed with two or fewer pizzas), focused on a single platform. It can accommodate teams which have designers that code, as well as designers who don’t.

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

UPDATE: Go read Part 1, How to Manage a Design Backlog and Part 3, How to Maintain Separate Design Design and Development Backlogs.

How To Manage A Design Backlog

I just blogged about the How To Manage A Design Backlog over at the Pivotal Labs blog.

Every project is different, but Agile and XP have taught developers a stable and robust set of tools for managing (development) work. What about managing design work? (With apologies to Tolstoy :)

[DEVELOPMENT BACKLOGS] ARE ALL HAPPY; EVERY [DESIGN BACKLOG] IS UNHAPPY IN ITS OWN WAY.

A designer colleague asks:

I’d love some insight into how other people use [Pivotal Tracker] / attach mocks and keep things updated as stories split and get added. I’d love to learn how to spend more time working on design rather than managing it.

There are many approaches to managing design and integrating design work with development work…

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

UPDATE: Go read Part 2, How to Integrate Design in an Agile Backlog, and Part 3, How to Maintain Separate Design Design and Development Backlogs.

 

Subjective Design & Objective Design

I just blogged about the Subjective Design & Objective Design over at the Pivotal Labs blog.

“DESIGN” IS A MESSY WORD
When people ask what I do and I reply “I’m a designer”, their first reaction is often to point at my chest: “Oh! Did you design that shirt?”

“Not that kind of designer,” I reply.

Next they’ll point somewhere around the room. “Oh”, they’ll say “did you hang that wallpaper?”

“Not that kind of designer”, again. Rather than let this game play on, this is usually the time to describe web design, interaction design, product design, visual design, UX design, UI design, etc. The content is tailored to the design-literacy of the interlocutor, but the story is the same. Modern “design” in the context of building products is a mix of many different design disciplines (and: naming things is hard.)

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

Sustainable Pace, Agile, and the Big Design Refactor

Kate Rutter drew amazing sketch notes for my talk on Sustainable Pace, Agile, and the Big Design Refactor (video, deck) from the Balanced Team 2013 conference. Thanks Kate!

Minimum Viable Deliverable

I just blogged about the Minimum Viable Deliverable over at the Pivotal Labs blog.

As a business, design is built around deliverables: clients pay for wireframes, mockups, prototypes. As a practice, these deliverables are a means to a single end: communicating design decisions. The Agile Manifesto prefers “Working software over comprehensive documentation”, so why are designers spending time on artifacts the user will never see? Agile seeks to minimize waste, so taken to its logical extreme, all documentation is waste. That doesn’t mean documentation can (or should) be done away with entirely; it’s necessary for teams to function (particularly at scale). But it does suggest that minimizing documentation is a Good Thing, and that designers ought to be seeking to communicate design decisions with the least amount of work possible. Welcome to the Minimum Viable (Design) Deliverable.

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