1. Daily Standup

5x weekly, 10 minutes each

Standup is a short, team-wide orientation meeting. Each morning, the team meets for a the Team Stand-Up meeting. As it’s name implies, everyone should be standing up—even if they’re remote and parked behind a screen. Meetings tend to run short when everyone’s on their feet, and there isn’t much to cover anyway, just three canonical questions:

• What did you do yesterday?
• What are you doing today?
• Are you blocked on anything?

Since the team is pairing, most of the time the second person will say “pass” since their pair already mentioned the stories they worked on, the issues they had, and what they’re doing next: sticking together or seeking a new pairing partner.

2. Iteration Planning Meeting (“IPM”)

1x weekly, 60 minutes each

The IPM is a weekly tactical planning meeting. It’s aim is to ensure that the backlog is in good shape, and that all the team members have a shared understanding of what the stories mean. The product manager leads the meeting by reviewing the backlog. Each story should be reviewed; questions can be answered, clarifications can be issued, and developers can estimate the stories. Ideally, the meeting is on Monday or Tuesday and the team will get through the current iteration’s undone stories and a healthy chunk of next iteration’s stories. On some teams, it helps to take an hour before the IPM to groom the backlog, prioritize, and flesh out poorly-worded stories in a pre-IPM meeting with a small group (usually the Product Owner and a single developer).

3. Friday Afternoon Meeting

1x weekly, 60 minutes each

A useful pattern on recent projects has been to block out an hour Friday afternoon and rotate between three meetings: the Team Retro, the Tech Retro, and the Release Planning. It’s nice to have a regular time, and every-three-weeks is about the right frequency for each of these.

Week 1: Team Retro

The Team Retro is a chance for the day-to-day members of the team to reflect on how things are going, celebrate successes, voice frustrations, and suggest Action Items. While there are plenty of variations, the classic Retro format is to throw three columns on a whiteboard:

• “Smileys”, or things that are going well, represented by the expected emoticon :-)
• “Frownies”, or things that are going poorly, represented by :-(
• “Mehs”, or things that don’t fit cleanly in either category, but bear mentioning :-\

After ~25m of going around the room and throwing out Smileys, Frownies, and Meh’s, the team might spend a few minutes identifying items which have a common theme, and then spend the rest of the time suggesting action items, either for each item (starting with the Frownies) or, if time is short, on a theme-by-theme basis. The action items are recorded and assigned to individuals, and their progress is followed (often at the start of the next retro). For more about Team Retros, see 7 Best Practices for Facilitating Agile Retrospectives.

Week 2: Tech Retro

A Tech Retro is for and by developers. While pair-programming is essentially continuous code review, it can still be useful to take some time to step back and look at the codebase. Tech Retros often take the traditional “Smilely / Frownie / Meh” format, but focus exclusively on the codebase. This is a great time to talk about modeling decisions and suggest refactors. Often the action items resulting from tech retros are a long list of chores. Try to keep each one to a manageable size, and make sure at least a few of them make it into the backlog for the next iteration.

Week 3: Release Planning

“Release Planning” means different things to different Agilists, but in this context it’s a loose title for a long-range planning meeting. While the IPM is a short-term tactical meeting, it’s important to occasionally step back and look at the big picture. What are the product’s medium- and long-term goals? Are we on track? What should our next milestone be? The Release Planning should be attended by the whole team, and by the stakeholders like clients and CEOs who may not be part of the day-to-day workings of the team. It’s a chance to review epic story tracks, dates and deadlines, and to make sure that everyone has a shared vision of where the team is going—and that it’s a place worth going to.

Why Meetings Matter

Communication is crucial, but so striking a balance between waste and on keeping everyone on the same page. I’ve found that teams which hew to this schedule tend to have a healthy rhythm. While circumstances occasionally require additional meetings, especially on the part of the Product Owner or the outward-facing members of the team, this structure is sufficient to maintain healthy intra-team communication without taking developers away from code any more than necessary.

Do you have another default meeting structure that you like? Let’s hear about it in the comments!

The post A Responsible Recipe for the Fewest Possible Meetings appeared first on Pivotal Labs.

1. Explain and Enforce format

At the beginning of a retro, take a minute to explain what’s going on—even for a seasoned team, but especially for a team with new members. “We’re here to reflect and improve on process—this is a safe space, and we’re oriented towards exposing issues and taking action.” If the team isn’t explicitly aligned on why they’re in the room, they can’t get the job done. Speaking up is high value (it ensures the retro is properly oriented) and low-risk (it only takes a minute).

2. Write Everything Down Verbatim

A retro is about listening. Whoever takes notes ought to be respectful of the speakers voice. That means recording their thoughts as faithfully as possible, without interjecting opinion or commentary. If you do need to paraphrase for brevity, be as faithful to the original comment as possible—don’t insert your view, you’ll get your own turn—and confirm that your version does justice to the original. “You said ‘INSERT COMMENT HERE’ and I wrote ‘INSERT PARAPHRASE HERE’. Is that right? “

3. Categorize carefully

If you choose to categorize items, be very conservative about pre-judging what it is you’re talking about. Sure, you’ve spent the last 25 minutes talking about a few categories, but don’t jump to putting names on the buckets—that’s prejudice, and it shapes opinions. Group like items (“Are these two frownies related?”), branch out from there, and labels will emerge. Be careful that the buckets aren’t too broad to be useful; it can be tempting to draw connections among almost everything, but ideally you’ll be slicing things a little thinner, facilitating more focused action items.

4. Action Items Should Have Intent

Unclear Action Items are worse than useless. One trick is to ensure a verb is the first word of every Action Item. By definition, every action includes a verb, but sometimes the verb is glossed-over or shorthanded in the retro. Everyone in the room understands what’s meant, but afterwards that may no longer be the case. Make sure that Action Items remain actionable when viewed later.

5. Action Items Should Be Falsifiable

Be sure to frame Action Items in terms that can be assessed as “done” or not. “Refactor more” isn’t useful a useful task, because there’s no way to meaningfully tell whether it’s done. “Improve the User model’s Code Climate grade from an F to a D” is actionable, and lets the team take small, achievable steps towards improvement. Also: use Code Climate, Errplane, New Relic, Airbrake or other instrumentation services to help put objective measures on code quality, performance, etc.

6. Action Items Need a Single Responsible Party

Not two people. Not “team” or “all”. One person. When an action item involves the whole team, find a volunteer to be the cop and enforce compliance. If one person isn’t responsible, then no one’s responsible. Addendum: review Action Items. Print them up and put them on the team stand-up board. Cross them off as completed. Review the list at the next retro.

7. What Happens In Retro, Stays In Retro

The retro should be a safe place. Active members of the team should the be ones in the room; sometimes it’s helpful to include stakeholders that aren’t present for most of the week (but that’s a judgement call). Action Items may be displayed publicly, but it’s preferable to only share the raw notes with the people present.

These practices aren’t laws chiseled in stone; they’re hacks and ideas borne of observations of patterns and anti-patterns witnessed in many, many retros. Do you agree? Disagree? Have juicy, anonymized stories supporting or contradicting? Let us know (and share your best retro stories) in the comments.

The post 7 Best Practices for Facilitating Agile Retrospectives appeared first on Pivotal Labs.

A typical Agile Inception ends with a fully fleshed-out backlog for the next few iterations, and some farther-off, coarse-grained, Epic-level ideas written on index cards. What to do with them? Some teams clip them together in a deck of cards that gathers dust and is rarely seen again. I prefer to externalize them on a foamcore board in a riff on a technique Thoughtworks calls an “Idea Board” or “Idea Backlog”.

Making the Idea Board

This is basically an Epic-level reverse-Kanban board that will work in concert with Pivotal Tracker. Create a few columns: “Now”, “Next”, and “Later”. Generally you’ll have 2-3 cards in the Now column, another 2-3 in the Next Column, and the rest (~20-40) in the Later column. The Idea Backlog can often fit on a half-foamcore board (4ft x 4ft), and serves a few uses:

• it externalizes future epics so everyone 1) is reminded they exist, and 2) can see their relative priority
• it gives Stakeholders a place to park long-term ideas, and feel that their contributions are included
• it gives a big-picture view that tactical what-are-we-working-on-this-week systems have trouble displaying succinctly. This is great for strategic-level Release Planning meetings that I like to try to have every 3 or 4 weeks.

On a recent project, we had a bit of Priority Whiplash: every week, we’d go into an Iteration Planning Meeting (IPM) on Monday and agree on priorities. By Friday, someone on the team would say “Why’re we working on this?! What about that other thing?!”. We’d mention the agreed-upon priorities from a few days earlier, but inevitably someone would shake their head and say “I never agreed to that!”.

Idea Board to the Rescue!

We started using the Idea Board and bringing it to planning meetings. Having a tangible representation of the plan helped a lot. “Remember on Monday when we moved the Foo feature set into the Parking Lot to make room for the Bar feature set? I swear no one moved the cards since the last time we looked at this.” This helped a lot. It also really helped that when someone would say “I had a great idea! Let’s make a Baz feature!”, we could write “Baz” on an index card and stick it on the board. It may live in the parking lot for a while, but its visible and everyone is comfortable that we’re prioritizing the feature (rather than forgetting about it).

Some say a big drawback to a strategic paper-based system like the Idea Board is that over time, it falls out of sync with a tactical digital system like Pivotal Tracker. I think this is more a feature than a bug: when the Idea Board has one or two epics that are out of sync with reality it’s no big deal. When the whole board is a big lie, that’s a signal to the whole team that it’s time for everyone to re-asses the alignment between tactical steps and strategic goals: it’s time for a Release Planning meeting.

The post Set your sights on the next Milestone with an Idea Board appeared first on Pivotal Labs.

What am I? What should I call myself?

A User Interface Designer? Maybe a User Experience Designer? No, an Information Architect! A Human Factors Engineer? Is there a meaningful difference between these titles? What should we call themselves? Nanas and Bubbes kvell over doctors and lawyers; why don’t our parents and grandparents know what we do for a living? Why don’t we know what our name is?

A few years ago at the Idea Conference, I heard an answer that was so good I’ve been quoting it ever since (and it’s come up even more now that the words “agile” and “lean” appear so frequently). It was a two-day conference, and the keynote speaker got sick and was unable to close the conference on the final day. Instead, the organizers asked all the speakers to come up and do a roundtable Q&A with the audience. Attendees lined up at the microphone, and the first question rang out:

What should we call ourselves? User Interface Designers? User Experience? Information Architects? Who are we?!

This was a plea to our elders and wisers to shed some light on our very identity as a community. Each and every one of them—designers, speakers, luminaries—froze in panic. All but one.

The outsider stood up. Michael Wesch (of “The Machines are Us/ing Us” fame) grabbed the mic: “Let me take this one.” He went on to say:

I’m not a designer, but as an anthropologist, I can give you perspective on your community. I don’t know whether ‘UXer’ or ‘UI Designer’ is a better designation, but I can tell you this: as long as there’s debate over what to call yourselves, your very identity, your community is vibrant. The moment you agree on your name, your frozen and a known quantity—and ready to be commodified.

Every time someone asks me “what should we call ourselves?” I tell that story. I love being part of a community that is vibrant. I embrace the questions and challenges and learnings that keep us, for now, impervious to commodification. And I still hope I’ll figure out a way to explain to my grandmother what exactly it is that I do all day.

The post What’s (not) in a Name appeared first on Pivotal Labs.

Flexible plans executed via iterative development are at the core of Agile:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This is great for figuring out what to build, but all this flexibility can make planning and estimation hard. In practice, developers tend to prefer backlogs containing a few weeks worth of fine-grained stories following INVEST principles, followed by low-fidelity—and unestimated—chunks of epic-sized features. The thinking is that any stories farther out are unstable, and that it’s wasteful to spend time specifying them in detail. Agile planning tools like Pivotal Tracker are built with this perspective in mind, and are great for managing fine-grained details. But what happens when you need to get a more big-picture view of a project? Recently, a colleague said:

As development moves forward, features change. And those changes have implications on the stories later in the backlog or icebox. … Not sure if this the best way since it causes me to not want stories that extend beyond a few iterations.

Isn’t this the perfect distillation of the Agile Manifesto’s notion of “Responding to change over following a plan”? I find the problem isn’t changing stories—this is a natural part of Agile development. Rather, the difficulty is doing the work to 1) figure out which stories are stale, and 2) to re-estimate stale stories, lest 3) clients make plans based on stale estimates and then get upset when we say “sorry, those estimates aren’t accurate any more”. Ideally, the estimates will be revamped downwards (there’s less uncertainty now that we know more about what’s going on, right?), although sometimes we’re discovering hidden complexity and the estimates go up. D’oh!

The Assumptions Label Technique

One technique I’ve used successfully on a few projects is what I like to call the Bullpucky Assumptions Label. I pull it out when the client demands—not unreasonably, I might add—that we estimate out the next 3-12 months of work so that they can get funding / approval from their boss / etc. I’ve seen project teams fight this for weeks (the PM getting more irate and frustrated the whole time), finally lose, and schedule a (miserable) half- or one- or two-day mini-inception during which they proceed to estimate every story for the next few quarters in fine-grained detail. Of course, they inevitably have to re-estimate half those stories in angry IPMs when it becomes clear the estimates are wrong, grumbling “we told you these estimates were bullpuckey”.

Here’s the Assumptions Label technique:

1. Schedule a 2-3 hour Assumptions Meeting with the PM and 1 or 2 devs. (You don’t need the whole team; these aren’t real estimates). Estimate “stories” (they’re really closer to epics) at a multiples-of-8-point level of granularity. Pretend we’ve built the basic shopping-cart and inventory functionality of Hamazon (“The Internet’s Favorite Purveyors of Pork since 2009!”), and now the client wants to fully copy Amazon’s feature set. It might contain rough estimates like “Reviews and ratings? Mmmm…24 points. Recommendation Engine? 40 points.” Rough out the desired feature set. You’re basically estimating at a pair-week level of granularity, so multiply pair-weeks by (velocity/team strength) and you’ve got your pointed estimate.
2. Write titles in all caps (they’re easier to see that way). Don’t bother writing a description for the story. It’s ok to use multiple 8-pointers to get to the number you need.
3. Throw an “assumptions” label on all these stories; they’re easier to wrangle (and it never hurts to drive the point home).

The Assumptions Label technique in action. Use it to re-prioritize coarse-grained blocks of epic, and watch estimated completion dates adjust.

Now your PM can give a rough estimate to their boss or their boss’s boss, re-prioritize at a rough level of resolution, and cut scope or add pairs. But it remains clear to everyone that these should never be mistaken for actual, deliverable stories. In fact, these “assumption” stories become a decent way to see what’s next when story-writing. IPM or pre-IPM often becomes an exercise in picking the top assumption off the top of the file and fleshing it out into real stories. By reducing the difficulty in seeing what’s a real story and what’s a rough estimate for planning’s sake, everyone gets better visibility into the project. Pivots can set better expectations for their PMs, PMs can set proper expectations for their boss, and trust is preserved on the team.

The post Long-term Estimation in an Agile Environment, or: How I Learned to Stop Worrying and Love the Assumptions Label appeared first on Pivotal Labs.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

For the last few years I’ve been using an app called Time Out to make sure I take regular breaks. It runs in the background and throws a “micro break” about every ten minutes—just look away from the screen for ten seconds and rest your eyes—and a “regular break” about every hour or two, reminding you to get up and walk around for a few minutes. To be honest, the app gets a little annoying (especially when you’re pair-programming, collaborating with others, or recording screencasts), but its worth it. Whenever I stop using the app, eyestrain comes back after a day or two.

Here’s how I set up my Time Out:

Pro tips:

• Set the “Micro Break” (every 10m) with yellow background, fade in immediately, last for 10s. (this is to remind you to look in the distance to rest your eyes). Disable all snooze buttons for the Micro Break.
• Set the “Regular Break” (every 55m or 85m) with at red background, fade in immediately, last for ~4m. I like to set the frequency + duration to != 60m, so that my breaks go out of phase w/ the clock. Disable all snooze buttons except “postpone 5m”. Time Out is great, but it requires discipline. Once you start hitting ‘snooze’, you lose respect for your breaks and it’s all over—Time Out turns into an annoyance rather than an aid.

Our bodies were built for dodging saber-toothed tigers, not for working at a computer in a climate-controlled office. Download and set up Time Out; chances are good you’ve got many more years ahead of typing and using screens, and it’s important to take care of your body.

What tools do you use to stay healthy at work?

The post Enforcing Sustainable Pace at the micro-level appeared first on Pivotal Labs.

When is Design Done?

Agile development preaches “Done means Done”. When a story is accepted by the Product Owner, it’s ready to be deployed out into the world. What does “done” mean for design? Automated testing guarantees that on every story, developers will enjoy Acceptance Criteria: a concrete measure of what counts as “done”. Designers, on the other hand, rely on subjective criteria to determine when they’re done. In the best case, this means the product team—or often, the designer working alone—if only they had a partner to pair with! In the worst case this is purely subjective sign-off from the client. While agile developers have access to tools like velocity to plan their work, designers have structural difficulties in estimation, and are consequently less able to plan. Consequently, questions like “when will that feature be done?” are more easily answered by a developer than a designer. That’s not because designers are less responsible than developers. It’s because it’s harder to know when you’re done with design—but that’s of little comfort to anyone who needs to budget time and resources to manage the project. Because Acceptance Criteria—or an answer to the question “what does ‘done’ mean?”—for design is in different units of work than “done” for development, there’s an impedance mismatch in coordinating between the two. Breaking design into units of work with more discrete Acceptance Criteria helps coordinate design work with development work.

What’s Wrong with the Deliverables Business?

Agile Developers ultimately deliver user-facing code, but designers output thinking: solutions to design problems, traditionally expressed via mock-ups or assets. How should the two interact? Should design stay an iteration ahead of development? What does it mean when a developer discovers an interaction problem in a design they’re implementing? Should they stop work? Developers are the tip of the spear when it comes to experience design: in the process of building software, they’re often the first people ever to use it. Sometimes this means they uncover interactions on UX problems that the designers didn’t anticipate. If the necessary design changes cascade into other work, what should the designer do: stop work and refactor (and fall behind), or come back to it later?

Furthermore, it can be difficult to determine how much design is required for developers to complete their work. The best design deliverable is the Simplest Thing That Can Possibly Communicate the Design Solution, and this can vary from team to team and design problem to design problem. Under ideal circumstances, an experienced designer may be able to reasonably estimate how long it will take to 1) solve the design problem, 2) communicate the solution, and 3) iterate on the problem / solution once it’s usable and testable as working software. But. BUT! That’s asking a lot. And it absolutely shreds the question “how far ahead should design stay of development?”.

Why do Designers Feel Unwelcome in Agile?

Let’s take stock: we’ve got gallant developers, accurately estimating stories and delivering working software, and the goofus designers, unable to tell you what they’re doing or when they’ll be done. Knowing “how much design is enough?” is hard. Knowing how much design to start with is hard. Reared in a culture that prizes individuality, that venerates Rock Star Designers, that applauds Working On It Til Its Done, that publicly shreds less-than-perfect work in Crit as a rite of passage, that (with the occasional exception) is alien to the notion of sustainable development—it shouldn’t be surprising that designers are uncomfortable. That starts to lead to discord on the team: designers hating agile; feeling rushed, feeling like they don’t get the benefit of iterative design; feeling that once they touch something, they don’t get to go back and refactor it. Let’s throw in a bit of rah-rah agile ideology, a few jargon-y IPMs and retros, promises that “we’ll come back and refactor that later”, and the creeping suspicion that this whole Agile thing is nothing but smoke, mirrors, and Kool-Ade. Is it any wonder that designers can be hostile to agile?

What can we do? Looking to the example that Agile Development sets, we can see several concepts that may help: Acceptance Criteria-delimited design stories. Meaningful estimation of work for design. A culture that values Sustainable Pace. Translating these ideas from development to design may do more than just help designers work more comfortably in Agile environments—it may help us practice better design.

The post 3 Challenges for Agile Design appeared first on Pivotal Labs.

Choosing a design: Standard or Cantilevered

There are two major designs for a standing desk: “Standard” or Cantilever. I prefer the Cantilever design, but it’s less well-balanced than the Standard design, and requires a little more care in its placement and construction.

Standard Design

The Standard Design puts the keyboard tray in front of the standing desk, and the iMac over the center of gravity of the desk. It’s the most stable design, although it’s not as comfortable or efficient in its use of space as the Cantilevered Design.

Cantilevered Design

The Cantilevered Design puts the keyboard on top of the center of gravity of the desk, and cantilevers a shelf off the back for the iMac. This is a great design for desks which face windows or exterior walls; because the shelf is offset off the back, it can sit above an air conditioner or HVAC system that ring exterior walls in many offices, saving space. Because the keyboard surface is above the footrest, it’s also a bit more comfortable. It is imperative that a cantilevered desk is secured, either by leaning it directly against a wall or setting a counterweight on the base, or both. Failing to do so may tip the desk over, sending your beautiful and expensive iMac crashing to the floor. CANTILEVER AT YOUR OWN RISK!

Materials Needed

• 4 Rods. I like to mix a pair of short rods in the front with a pair of long rods in the back.
• 4 Shelves. 36in shelves are a little tight pairing situations where you’ll sit two people abreast, but they work. 48in are nice and roomy. From top to bottom, you’ll need:
• Monitor shelf
• Storage Shelf
• Keyboard Shelf
• Foot Shelf

In a Standard design, the Keyboard Shelf will connect to 2 rods; the others connect to all 4 rods.
In a Cantilever design, the Monitor Shelf will connect to 2 rods; the others connect to all 4 rods.

• 4 Wheels. Mobility is your friend. Buy two plain and two locking casters; the locking ones should go diagonal from each other.
• 3 Surfaces. I like wooden butcher blocks, but you may also find plastic.
• 1 rubber mallet (or hiking boot) for assembly.
• A counterweight (required for a Cantilever desk; encouraged for a Standard desk)

The Build

1. Screw the wheels into the bottom of each rod
2. On all four rods, clip a plastic collar onto the bottom notch, and send them through the first shelf. This will be the Foot Shelf. It’s easiest to do this by putting the narrow edge of the shelf on the floor and sliding the rods through while they’re still parallel to the floor.
3. Flip everything up from the floor so the four rods and one shelf are sitting on the wheels.
4. On all four rods, clip the next collar about 28 notches from the bottom (you might want to modify depending on your height). Put the next shelf on. This will be the Utility Shelf.
5. Place the butcher block on the Utility Shelf—it may be hard to get it on after you add other shelves.

Building a Standard Desk

1. On the front two rods only, clip the a collar directly about the Utility Shelf. Slide the next shelf only on the front two rods, so it overhangs in front of the rest of the unit. This will be the Keyboard Shelf.
2. On all four rods, clip the next collar about 39 notches from the bottom (you might want to modify depending on your height). Put the next shelf on. This will be the Monitor Shelf.

You’re done!

Building a Cantilevered Desk

Follow steps 1-5 from above. Then:

1. On all four rods, clip the next collar about 5 notches above the Utility Shelf; this will be the Keyboard Shelf. Set the height so that your arms will be at a 90 degree angle when typing. Don’t forget the butcher block will add another ~inch of height.
2. On the back two rods only, clip the a collar about 39 notches from the bottom; this will be the Monitor Shelf. Set the height so that your head will be level when looking at the center of the monitor. Slide the shelf only on the back two rods, so it overhangs behind the rest of the unit.
3. Ideally, place the desk so that the Monitor Shelf is in direct contact with a wall, preventing it from tipping over.
4. Put a counterweight on the Foot Shelf before loading the Monitor Shelf. If you don’t counterweigh the desk, it will fall backwards, potentially injuring you or wrecking your equipment.

You’re done!

The post How to Build an Awesome, Affordable, Flexible Standing Desk using Metroshelves appeared first on Pivotal Labs.

Design starts with systematic thinking and then shifts to incremental changes. No matter where a project starts, at some point the design systems’ integrity will degrade to the point that you need to look at the whole thing fresh. Welcome to the Big Design Refactor. In the beginning, you had a beautiful, functional design system. And then you had to watch, helplessly, as it degraded under the weight of a thousand tiny changes. It’s maddening, and a big reason many designers are allergic to Agile methodologies.

What can you do? Understanding and accepting that this design-system degradation is an affordance of differently-sized design and development cycles is the first step towards making peace. Once you realize and accept this change, it’s much easier to deal with. Plan on it. Talk about it with your team. Designers need not work at developers tempo. Rather, they should strive to stay in-rhythm with development, working at their own pace, and making sure their beats and decision-points intersect with development at regular intervals.

As the designer, it’s your job to keep an eye on the health of the graphic system. Just as the developers incur and pay down their technical debt, you’ll manage your design debt. How? Mention that the graphic system is starting to break down. All the while, you’re still doing your work. Keep solving the tactical problems, keep delivering value. At some point, the balance shifts: you’re no longer plugging little leaks or engaging in preventative maintenance. The system is undermined; the cracks are starting to show. Now’s the time to have a talk with your team. You’re going to need a few weeks to work on this. You’re going to need the development team to find something design-light and backend-heavy to focus on for a week or two. Hold a design retro. Get their feedback, and their buy-in, and their good ideas. And now you’ll have a break from the tactical work of patching up design as features iterate. You’re a Pure Designer again, working in your idiom, experimenting and sketching and building a new design system.

How does the Big Design Refactor work?

When I’m in the midst of a Big Design Refactor, I’m spending most of my day in Adobe Creative Suite. I’m pulling the product team over ~4-7 times a week to bounce ideas off of them. I’m pinging the development team ~1-2 times a week to consult on the technical implications of where I’m going. By the end of the week or two, I’m usually delivering a set of user stories accompanied by mockups. It’ll often take an IPM or two to get through all of them, and it’s important that they get implemented soon. Nothing feels more like waste than a heavy investment in design, followed by unacted-upon stories that go stale. This will kill trust between the design and product teams (in both directions); it’s downright poisonous.

Now, while the new design is being built by developers, I’ll occasionally hop back into Adobe Creative Suite for assets or newly-discovered UX tweaks, but most of my time is spent pairing with developers. I’ll also keep a close eye on acceptance. Pixel-perfection is rarely necessary, but miss an important UX point now and the error will become enshrined as part of the system.

Once the Design Refactor has been assimilated into the app—and it’s rare that 100% goes in, but 80-90% is the norm—it’s Tactical Incremental Fun Time! I’ll spend most of this time pairing on stories, picking of styling stories to solo on, and working on design problems revealed by user testing. At this point it’s probably 66% development and 33% Adobe apps. The debt clock is starting to tick again, and once the pain is noticeable, I’ll start making noises: “we’re ok for right this second, but we’re going to need a design refactor in the next 3-5 weeks”.

Why are the Rhythms Different?

Design and development are activities that move at different speeds. Test-driven development and Agile project management allow developers to break work down into small stories and iterate on them. The unit of work for the “what” of the story is “what’s the smallest possible thing that delivers value to the user?” and the “how” of the story is “what’s the simplest possible thing that can work?”. These units of work tend to translate poorly to design, because effective graphic design is almost always a system. Changing arbitrary pieces tends to degrade the whole. Design adjustments that are close in size to development units-of-work can be made, but they inevitably undermine the graphic system, creating Design Debt. Debt is fine, if used responsibly, but it needs to be paid down at some point. (More on that another time.)

Developers work at a quick tempo. They use Agile’s small units of work to facilitate a supple workflow that responds gracefully to changing client needs.

The customer wants to re-prioritize a feature? No problem! Move it to the top of the backlog and we’ll get to it next.

Because they’re backed by tests, devs are free to move around the codebase and project, making changes where the customer likes, with the confidence that their test suite will protect them from breaking the app. Designers have no such safety net—which is one reason that developing meaningful automated testing for design is crucial to a mature Agile design practice.

The rhythm of design is slower. Design pulls together an information architecture, UX metaphors, visual styles, a typographic system, a color system. Visual rhythm, hierarchies, and scale combine into a whole graphic system—more than the sum of its parts. All these pieces interrelate, and changes cascade into other. While adjustments to individual design elements can happen quickly, feature-scale iteration doesn’t allow for changes to the system; those take more time.

TL;DR

Ideally, bring a cohesive graphic system to Inception. Accept that it will degrade over time. Make tactical adjustments to keep pace with agile development, and plan on overhauling the design system every quarter or so.

The post The Big Design Refactor appeared first on Pivotal Labs.

Ultimately the goal is to go to a treadmill desk (for reasons outlined here), but before sinking the money and effort into that endeavor, I’d been meaning to try out a standing desk. It was never really a priority and I was working at a client-site (which inhibited my ability to request furniture) and so I kept putting it off. Finally one day I snapped. After lunch I went to the copy room, started grabbing reams of paper, and in less than 10 minutes I had a standing desk from W.B. Mason.

Standing Desk #1: Improvised Standing Desk

After half a day standing I felt pretty good—my legs were a little tired, but less than I’d expected. The next day we went back to the home office for a lunchtime tech talk. The plan was to stand at the WB Mason in the morning and then sit for the rest of the day at my home office, but I found that I wanted to remain standing. I commandeered an unused metroshelf and built a desk out of it.

Standing Desk #2: Quick metro standing desk

I wanted a few surfaces on the desk: a shelf for the monitor, another for the keyboard and mouse, a third for random work / storage (e.g. to set down keys or reference book or to put your cup of coffee out of accidental-spill range), and a place to rest my feet. Changing position is important if you’re going to stand for long periods of time, and resting a foot on a raised surface changes the way your body carries weight (this is why taverns often have a brass bar to rest your foot on). Its also helpful to have a shelf at the bottom which gives rigidity to the structure of the desk. Metroshelves aren’t very deep, but here’s the trick: it’s possible to hang a shelf on only 2 of the 4 poles, and thereby double the depth. The cantilevered shelf won’t bear as much weight as a shelf with 4 supports, but its sufficient for a keyboard, or even an iMac.

In order to get better foot access to the bottom shelf, I cantilevered the top shelf behind the desk, so the keyboard shelf is over the foot shelf. As a bonus, the iMac floats above the air conditioning unit, reclaiming a bit of wasted space.

It’s hard to see in this photo, but the back of the shelf directly leans against the wall. Note also that the UPSes on the bottom shelf to act as a counterweight to lower the center of gravity. This thing is secure from falling towards the window; no one wants a $2000 iMac tipping over.

Standing Desk #3: Kitchen Island

The next day was a blizzard, and I decided to work from home. Not willing to quit my standing streak, I moved my spare monitor to kitchen island and worked from there for the day. I also experimented with using an iPad and AirDisplay as an additional monitor. Its small and suffers from high latency, but it works just fine as a Pivotal Tracker display.

Standing Desk #4: Keyboard Shelf Metrodesk

Cantilevering an iMac scared enough people that I reconfigured the desk to put the keyboard at front. The footrest is pretty much unusable now (but the bottom shelf is still nice for rigidity and storage), but the desk definitely feels more solid. Wooden butcher-blocks are added for a nicer work surface.

Standing Desk #5: Cantilevered 48in. Metrodesk

Back at the client site, I finally found some metroshelves to build into a standing desk. This one followed the rear cantilever design, which worked nicely given this particular A/C unit and space constraints. This one is a 4-foot-wide desk, which is substantially nicer to pair on. Again, you can see the shelf directly leaning against the structural wall to prevent tipping over backwards. Here we use Mac Pros as the counterweight.

Conclusion

I’ve been standing at desks almost exclusively for ~24 months now, and aside from the occasional exhausted day when I grab a high stool to sit on, I doubt I’ll ever go back to sitting full-time. Standing desks have blossomed at the office too: we’ve got 5 Metroshelf standers, and another 4 or 5 Geekdesk-style adjustable desks. Since we’re a pair-programming shop, that’s ~20 people standing every day. We use bar stools and architectural drafting chairs to let a stander pair with someone who prefers to sit, and the standing Metroshelf desks have proven to be economic, ergonomic, efficient in their use of space, robust, and flexible. Now I just need to figure out how to get a treadmill desk in here…

Appendix

A NOTE ABOUT SHOES:

Don’t wear them. Your feet are perfectly built to support your bodyweight for long periods of time. Even the best running or walking shoes are less than perfect. Barefoot or socks is the way to go.

A NOTE ABOUT FITNESS:

If you’re the kind of person who’d be sitting on a balance ball at a sitting desk, try a Bosu Ball for your standing desk. It’s a great all-day workout for your core and legs, and its a lot of fun. A word of warning: for the first day or two, your vestibular system (i.e., sense of balance) will get quite a workout. I definitely felt the added cognitive load, and while it doesn’t prevent you from using the rest of your brain for work, it definitely takes a bit of concentration. By the second or third day I was used to it, and not standing on a balance ball just felt boring.

A NOTE ABOUT WHEELS:

Get them. Being able to easily relocate the desk is unexpectedly awesome and useful.

A BONUS: Tete-a-tete Pairing Desk

This could provide a standing version of Susser’s Tete-a-tete pairing configuration. We mocked it out when we ordered the second desk, but haven’t had a chance to try it out for real.

Coming Soon:

How to build a metroshelf standing desk.

UPDATE 2013-02-10: check out How to Build a Standing Desk!

The post The Journey to Using a Standing Desk appeared first on Pivotal Labs.