Talking Data Visualization with Sarah Nahm and Ian Johnson (transcription)

Sunday, June 16, 2013

Talking Data Visualization with Sarah Nahm and Ian Johnson (transcription)

We were lucky to have two Data Visualists, Sarah Nahm and Ian Johnson from Lever, join us for lunch in Pivotal SF last week talk and about the current state of Data Visualization. Nina wrote a great summary of their thoughts. Here’s an (almost) transcription of the talk. In accordance with my notes policy, any errors, misstatements or shenanigans should be attributed entirely to me and not the speakers.

What To Do With All Your Data

Sarah: My approach is that Data Visualization is goal oriented; it’s not about being on a chart. A lot of people assume that a line chart is Data Visualization, but I think google search is Data Visualization. By building a service and they’re building a specific and powerful Visualization. There’s usually a form that data can take to hit a goal. It’s not about one answer, it’s about doing many. I’ma huge fan of unsexy Visualizations, like tables. Designing tables to be effective is hard; people tune them out. Designing for people’s attention is a huge part of Data Visualization. The second huge think is to think about how data transitions. Is this a button? A portal? Does it start another activity? All those things are design principles that figure into my thinking. Ian is totally different in an really awesome way.

Ian: I’ve learned a ton getting into this field. I came from math and didn’t know Data Visualization was a separate thing. I just had numbers and I could turn them into pixels and colors. From that perspective, any transfer or exchange is a way to turn one data into another. What do we want to accomplish? Goal oriented design has been a really big positive change for me to deliver things that work for people.

Question: Can you talk about [didn’t hear] something that came together?

S: The original question was about “how do you break out of business dashboards?”

Tim McCoy: Can you talk about the tension between using data to tell your story and how data builds the story?

S: Where Data Visualization is now is about showing the data. Insights is hard just not just of “big data” or because the datasets are hard. This has driven me to learns statistics; i highly recommend the Cartoon Guide to Statistics. Learning more about machine learning, getting more of a literacy about it; it’s way too easy to find a correlation and wave that around as an insight, but it’s not that simple. Designing something around data you can’t anticipate is hard. Designing around a story is about being acutely aware of when you’re smart, and trying to be dumb. The anecdote that pulls this together is that in our app—basically Lever is a hiring software that isn’t about finding as much as about managing the data problem. When you find the 300 candidates, you need to keep track of them; it’s a confined but messy data problem. We have a list of candidates here. The big Data Visualization is that there isn’t’ a dashboard; data should be ambient and a portal to get to what you want to look at.

We call this the filterlist—it’s a name that we picked and it just stuck.

As you filter the list, you see the Data Visualization filter and update. As you change criteria, the list changes. Something that was really hard about this is that these aren’t all you’ll ever have about these people, they’re portals to list. If you filter a list and the output is a list of people, but also, what’re lists that people really need? How else can we show this? “There are people I reached out 3 months ago, and I dropped the ball, and how do I get back in touch?” Last week I was doing something about time but it was really fuzzy and heuristics based. We invented “Last Interaction view” which are irregular but meaningful timespans (e.g. 1 week, 3 months) drawn as little airplane windows with sparklines below. This chart gave us so much grief; there’s nothing scientific about it. It kind of bugs people because we made all these decisions. But the user looked at it with the user eye, the user looked confused. But when you look at the sparkline, you see “oh, that time was busy; that other time wasn’t busy.”

The goal was to let people know that if you look at this, you’ll see the list of people you dropped the ball on 3 months ago. A scatter plot would be more accurate, but it ultimately didn’t translate to how people thought about it. All the other teammates were like “maybe we should cut it”, but Ian said “maybe it should be a sparkline, people think about it that way.”

Q: How do you start?

S: I always start with What It Needs to Be; that’s usually a text document. It’s so easy to be distracted. There’s so much fun stuff. We had all this stuff; 6 or 8 questions people needed an answer to about a candidate. It was all about focusing on that. Otherwise it’s too easy to do what’s fun or pretty.

Q: ? [didn’t hear]

S: A We usually get negative feedback, because its hard for people to think about data in context. Until they can see their own data, it’s hard to grok. This is really reductionist. It’s really minimal to try to not overwhelm people. Our style of this ambient, around all the time, makes it hard to not have your own data.

TM: yeah, I did a finance project and the most challenging aspect was that without real data, it’s a total mess.

S: Maybe you should talk about Chris S.
I: THis idea of fake data is extremely important; without data, you don’t have a Visualization. I try to be hard-line about this. We’re still really bad about creating data. People come to us with nothing. We have to comb through existing systems, spreadsheets, etc. We do paper sketches with existing data, some rough D3 sketches. Everyone who was higher-up than our client loved the data porn, but the client was like “where’s the stuff I want to see?” “Where do I get the answers to my questions”?

S: People using our product are beta testers at [REDACTED]. The only guy watching the data carefully; Ian did all sorts of lo-fi sketches of what visualizations might do. In many ways lo-fi helps, but that was just priceless in terms of interactivity, in terms of “what do I want to filter on?” or if there were a time-based graph I could see what formats I needed to export to. Prototyping is no new thing, but the nice thing about Data Visualization is that prototyping an interface around what the data can be is really important; it lets us put a play button on it. There’s something about the way an engineer throws a button on anything can be really helpful; it’s really awesome.

Q: How do you know when to up the fidelity?

I: Data fidelity should get high ASAP, even if its a sub-sample of the data. It should have the final structure.
S: You can never wait long enough to do visual high-fidelity. Clients know about Data Visualization; some good things and some naive things. They know the questions they want to ask, when they need it, etc. People have really terrible taste in charts; they think they know what they want, but they never break down what they really need. Once you get them to say “I want to email this to my boss”, it changes the deliverable from the fully interactive website to an animated gif. The more it does the work that people need; you can make it pretty later. If you’re thinking about the charts as vying for your attention against this list of what you’re trying to do, there’s a degree to which the visual styling needs to be environmentally aware, but usually I go visual too soon.

Ofri Afex: I need to explore many directions while I’m doing charts, otherwise I get too used to the initial approach and get locked in to my first choice.

S: I rely on my design partners; they’ll take a headline and common chart elements and make a bunch of visual styles right at the beginning. I think that’s really valuable. It has to mingle with the rest of the application. I still feel that the charts have to be what they have to be, and that’s locked in by the reductive design decisions you make.

Q: Wha?

S: We have to show these variables. We have this much space. We have this much sampling fidelity. We have this much interactivity. E.g. for lookup, tables are the best. Charts are meant to show relationships. For so many business products, lookup is the task that’s needed, but clients want pretty charts. Like I said, Google search is Data Visualization.

Q: The reality is that stakeholders need to buy in.

S: The current bar is so, so low. It’s fun to surprise people with how nice of a place they can live in. It all stems from scoping the problems they have to answer, and making them feel confident. That’s the UX side—accessibility and confidence. Todays’ tools are built for experts, but the need is getting democratized. Recruiters aren’t trained statisticians, but they know what questions they want to answer. In some ways, you make sure it meets those needs. Building for the next step: “what do you want to do once you know it?” is where current products tend to drop the ball. That’s where people get excited. On one screen, we did throw a bubble chart in just for visual sexiness and visual balance so it didn’t feel too dense or unplayful.

Q: ??? [couldn’t hear]

S: Many Data Visualization have elements that feel like whitespace: it’s a waste unless you’re thinking about principles like balance and designing people’s attention. The bubble chart is like whitespace; it gives people a chance to take a breath. It’s a signpost that says “we’re in a new part”.

I: This particular bubble chart—a bar chart would work better—but it’s not the main thing.

Q: I just want to dive in.

I: Anything you click on—there’s hover states, etc, you build filters—but there’s no external changes other than highlighters.

Q: How do you think about that problem?

S: We have three redundant ways to indicate a filter is activated. We’re nervous that users won’t know.

Q: Do you split test it?

S: We should probably test more. This is the thing we worked on most recently. we want to ship and see how people work in the whole system. What we’re kind of asking is “When people change the data, how do they see the change?”. The real time framework we’re building on is going to be this amazing way to manipulate things, we can affect anything on the page. The vision is that the delta of the data is as important as the new state; I’d love to show the ghost of the sparkline. The vision for the filtervis is to show that.
I: You can use the browser history API to show that stuff going back!

S: Questions around change over time are where people are doing interesting things. That seems to be top of mind. Tributary makes that easy. Dealing w/ that medium of motion and time.

Q: You talked about representing change over time. How do you attack the problem of representing change over scale, e.g. trillion-row database?

S: What does the user want? Do they want to get back to the big picture? There’s a natural inclination to set up data as a hierarchy, but the Visualization of the data need not mirror the data. Often data mirrors a company’s org-chart, but that need not be.

Finding Pivotal (Designer edition).

Jonathan Berger

Tuesday, June 4, 2013

Everyone has an Origin Story. This is mine.

I discovered Agile by accident. I was a self-taught designer who’d travelled to Florida to hand off a project to the development team. My partner and I had spent the summer building this perfect product, and I was completely in love with it. But there was a problem: I knew that when those dummy developers got their hands on it, they’d ruin the thing. So I did the only thing I could: I went down there (in a very hostile frame of mind) to defend my baby.

That’s when everything changed.

Those “dummy developers” weren’t dummies at all. They were amazing. Smart, friendly, wonderful people, working in pairs with a sane process. This wasn’t an exception. I didn’t luck out and meet the one rockstar or the lone unicorn. No, this was a world where there was a system that worked to help people build strong web apps in a sane, sustainable way. The process held the promise that all those late nights, all the stress, all that constant re-invention of the design-wheel could be replaced with a systematic, repeatable, tractable practice for design. I returned to New York determined never to go back to the old way. I wanted to bring these things to design. I wanted to figure out how to do Pairing and Testing. Maybe it wouldn’t be exactly the same for design as for development, but the benefits of these techniques were missing in design—and I wanted them.

So I had a choice: find a shop in NYC that practiced Agile, or move to Florida. Happily, Pivotal Labs had expanded to NY earlier that summer. They were looking for an agile designer, and I signed on.

What would an Agile design practice look like? No one knew, but there were signs: how should a development shop interview a designer? Make him pair on his interview! It was intimidating and exhilarating, and a portent of things to come; of intuititing the right direction to go in, even if we didn’t know how exactly to get there. Of adapting techniques on the fly to invent our way to a practice that married agile and design.

On my first day I came in, said ‘hello’, put on my headphones and started working in Illustrator. It was me at my laptop and two pairs of developers: one pair to my left and another to my right. By my second day, I took the headphones off and started listening to everything around me. One of the affordances of pairing is that there’s talk all day. Listen, and you’ll hear the development process unfold. I started to learn the rhythms of What’s Important and What’s Not, of what’s a Real Problem and what’s not, what’s in interesting domain modeling question and what’s an implementation detail. These are distinctions that the design world lacks good language for. These are also, coincidentally, some of the hardest things to learn when you’re trying to learn to build software. This kind of stuff is really crucial, so I was fortunate to be in an environment where even while I was using Illustrator, these guys were coding and testing and pairing; I was absorbing the technique and practice the whole time. For me, that was the beginning of building an Agile design practice grounded in an Agile development practice that worked.

How’s it gone so far? There’re a lot of smart people working on the same problem. There’s still a lot of work to do. Sometimes it could be lonely being the only designer in a shop full of developers, but now Pivotal’s building out a Product Design practice, and it’s a great environment from which to drive out this practice. (Want to help? We’re hiring!). Pivotal’s mission is to change the way the world develops software, and bringing Agile practice to design fits into that mission seamlessly. Agile Design practice has come a long way, but it’s still years behind development. There’s a lot more to do, and I’m grateful to be part of a team that’s doing it every day.

A Responsible Recipe for the Fewest Possible Meetings

Jonathan Berger

Monday, May 20, 2013

Meetings are crucial to healthy team communication. But they’re also opportunities for waste, occasionally dull, and always expensive. Every team is different, but continuing the theme of “Convention over configuration for process”, I’ve found the following structure keeps meetings to ~7.5% of your week. This minimizes waste, maximizes making-time, and makes for a nice scheduling default for projects.

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!

7 Best Practices for Facilitating Agile Retrospectives

Jonathan Berger

Monday, May 13, 2013

Facilitating a retro is a very powerful role; it’s almost akin to being a courthouse judge (and stenographer). By asking questions, recording testimony, and shaping the debate, you mold and influence your teammates’ feedback in a very vulnerable and trusting space. If the Product team sets goals (like a Legislature) and Development and Design teams implement them (like an Executive Branch), a retro is a chance to reflect, interpret, and set future direction—not unlike a Judiciary. In practice, that means it’s important to be especially honest and impartial, and to double-check that you’re doing justice to the team’s best interest and the speakers’ intent. Here’re a few patterns I’ve observed that help make the difference between a good retro and a bad one.

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.

Set your sights on the next Milestone with an Idea Board

Jonathan Berger

Monday, April 29, 2013

The Idea Board Technique

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.

What’s (not) in a Name

Jonathan Berger

Monday, April 15, 2013

I solve design problems. Sometimes I use hi-res mockups, sometimes I use wireframes. I always use empathy. I always strive to understand the user and design against their needs.

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.

Long-term Estimation in an Agile Environment, or: How I Learned to Stop Worrying and Love the Assumptions Label

Jonathan Berger

Monday, April 1, 2013

Estimation is Hard

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:

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.
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.
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.

Labs

Enforcing Sustainable Pace at the micro-level

Jonathan Berger

Saturday, March 16, 2013

Timer settings for the Normal break.
Appearance settings for the Normal break.
Timer settings for the Micro break.
Appearance settings for the Micro break.

Sustainable Pace is one of the Principles behind the Agile Manifesto

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:

: Timer settings for the Normal break.

: Appearance settings for the Normal break.

: Timer settings for the Micro break.

: Appearance settings for the Micro break.

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?

3 Challenges for Agile Design

Jonathan Berger

Monday, February 25, 2013

Software development has been revolutionized by Agile development practices, but designers struggle to adapt to the very same techniques—despite suffering many of the same challenges that led to Agile. What exactly are these problems? And how can Agilists and designers address them?

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.

How to Build an Awesome, Affordable, Flexible Standing Desk using Metroshelves

Jonathan Berger

Sunday, February 10, 2013

I’ve written about using a standing desk; now let’s talk about building one. Commercial standing desks are ugly and overpriced. Building standing desks out of Metroshelves is a great alternative: economic, ergonomic, efficient in their use of space, robust, and flexible. Best of all, if you decide you no longer want a standing desk, its easy to reconfigure into shelving or a sitting desk.

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

Screw the wheels into the bottom of each rod
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.
Flip everything up from the floor so the four rods and one shelf are sitting on the wheels.
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.
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

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.
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:

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.
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.
Ideally, place the desk so that the Monitor Shelf is in direct contact with a wall, preventing it from tipping over.
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!