We had a small but engaged and very diverse group, which was the perfect way to kick off the chapter. There was a mix of people who had been to BT events before and those brand new to the idea, people involved in product development and people who are not. There were developers, product owners, UXers, QA engineers, a scrum master, and a project manager. There were people involved in product development and people who are not.  A big benefit to the mix of backgrounds and skills was the many great experiences and perspectives that were brought to the table.

The 2.5 hour event started with chatting, snacking, and name tag making.  After a presentation of Balanced Team’s history and values from Beth LaPensee, we moved into open space discussions.

The following topics were voted on and discussed throughout the evening. These were all really of the same flavor and blended together nicely:

• Challenges with becoming lean within an organization
• Dealing with pre-established designs/ideas as you transition to lean methods
• Kicking off cross-team partnerships within organizations
• What are some strategies one can implement to enhance collaboration between people with different roles?
• Techniques for engaging stakeholders and customers into the design and development process
• What are some strategies for striking the “right” balance of skills on a team?

Two recurring themes were evident throughout the discussion:

1. The importance of good communication and the entire team having a shared vision of the “why”. Some suggestions of tactics to try:

   • Spend time explaining something to someone who doesn’t “speak your language” - try different techniques like sketching or pairing (see below)
   • Use tools/techniques with your team that get everyone engaged in discussions about goals and vision. Try impact mapping or story mapping.
   • Be open with your team about what your personal development goals are.

2. Pairing as one of the fastest and most effective ways to develop empathy for your colleagues AND to further your own skill development. Things to try:

   • Developers can pair with a Product Owner, for example. This can be helpful because abstracting the technical concepts for a broader audience can also help the developer think about their work differently, more holistically.
   • Pair to develop empathy with your team members or others at your organization. You will learn what you can do to make things better for them.
   • Pairing can also be good for skills development, whether you want a deep dive into a known area or get an introduction to something new.

And there were some leftover topics that we didn’t get to.  There are surely some great discussions in here, so we’ll hold on to these for next time.

• Balanced team with remote members… can it work? If so, how?
• How to overcome parts of the team not being in the same location
• Great tools for team communication
• How can we advocate for QA having more time with UX team in hopes of better balance?
• Roles of “project manager” or someone overseeing a project
• How to combine lightweight discovery (UX) with TDD?
• Balanced “team” as an individual?
• Co-locating with team and with others
• I have a great idea – how do I test it out?
• Give developers empathy around what drives the business.

Everyone is looking forward to the next BT A2 gathering! Watch the MeetUp group for future events.

Thank you to ITHAKA/JSTOR for generously providing the location, snacks, and supplies!

Balanced Team Ann Arbor is getting started!

On Wednesday, March 30 at 6PM we’ll host an evening of open space discussions on Balanced Team topics. Join us to get the conversation about building and working on multi-disciplinary, collaborative teams started.

Register on Meetup

To facilitate conversation, we’ll follow the Open Space format. The agenda is in your hands, so please bring your ideas or topics of interest. Possible topics could include: your lean success stories, challenges you are having as a member of a product team, transitioning to lean, collaboration within your organization, experimenting and learning from your users/customers, learning from mistakes, combining the different view points of different team members and stakeholders in an optimal way, etc.

Hosted and Sponsored by ITHAKA/JSTOR

Venue, drinks and snacks will be provided courtesy of ITHAKA/JSTOR, located at 301 E. Liberty St – corner of 5th and Liberty St. on the 3rd floor. If you want to attend, register on Meetup.

About Balanced Team

Balanced Team is a global movement of people who value multi-disciplinary collaboration and iterative delivery focused on customer value as a source for innovation. We’re a self-organizing group that learns from each other as we explore processes and methodologies to do good work with happy teams. We welcome people who wear many hats (design, development, testing, product management, marketing and sales, to name a few).

If you’re interested in Lean Startup, Agile, Lean, Agile UX, Lean UX, Devops, Customer Development – or anything else that values multidisciplinary collaboration and iterative delivery – we hope you will join the conversation!

After a hearty, cooked breakfast (thanks Pivotal!) we kicked off with a presentation from Johanna Kollmann on the history of Balanced Team. Then participants interviewed each other and introduced each other in the opening circle. As the Salon was an unconference, with the help of post-its and sharpies kindly provided by Unboxed, we then co-created our agenda for the day.

[embed]https://flic.kr/p/BpP4pP[/embed]

We broke into discussion groups to share case studies and offer advice and support and share techniques and tips.After lunch Adrian Howard facilitated a Failure SwapShop. This is a really fun game created by Luke Williams (@alukeonlife), who explains more on his blog:For those not familiar with the failure swapshop it follows a very simple format:

1. “Hi my name is ____ and I failed”

2. > EVERYONE CHEERS «

3. Explain your failure
4. Share the lessons learned

There are only 2 rules:

1. We’re all friends
2. Share only the lessons learned

The aim of the session is to encourage people to discuss their failures in a safe and supportive way, sharing only the lessons learned with those outside the room.

[embed]https://flic.kr/p/ARia76[/embed]

It’s surprising how good it feels to stand up in front of a room of people, share your name and say you’ve failed and hear a deafening cheer in response! Several people volunteered to come to the front of the room and share their own failures and lessons learned. This was a great way to bring the group back together after lunch, and set the scene for the afternoon. A few people commented on how they were keen to try this game at work. I think many organisations could benefit from encouraging their employees and teams to celebrate and learn from “failures” in this mutually supportive way.

[embed]https://flic.kr/p/AY4EQG[/embed]

What the participants thought

Quite a lot of people who participated had never been to a Balanced Team event before. Here’s what some of our “newbies” thought of the event…

Francis Rowland, Senior UX Designer at EMBL-EBI

@francisrowland“It was a tough start to a Saturday morning, waiting for a train down to London, shivering in the cold drizzle. In the end, I was really happy I went along to the Balanced Team Salon. Apart from the frankly top notch food and refreshments, and the good-sized location, I particularly appreciated the feeling of the whole event: egalitarian, focused, open, and supportive. I think everyone I talked to, from developers to product managers, event organisers, to other UX designers, wanted to find a way to share experience, so that we could all get better and doing what we do and working with other people.There was no preaching, no dogma; there were no role-related factions. Everyone pitched in, the format provided ample opportunity to focus on important things; new relationships were formed, and I think most people came away with a positive feeling, and having learned something. That was certainly my experience.So this “salon” turned out to be what I hoped it would be, and I’d happily do it again.”Francis also captured what he learned in his amazing sketchnotes.

[embed]https://www.flickr.com/photos/francisrowland/sets/72157662283104075[/embed]

Marine Barbaroux, Service and Product Designer at Cambridge Consultants

@miss_embe“I’ve been following the Balanced Team group for a while, but never participated in any of their events. I love the philosophy behind the group, and I admit I was a little worried that the audience would only be designers… But it wasn’t the case.Quite the contrary, actually: the audience of the event was diverse, only with the same interest in multidisciplinary teams that can actually deliver. The format is very simple: at the start of the day, people had explained what they were hoping to get out of the session, and it didn’t take long for many discussion topics to be generated. Somehow -don’t ask me how- I  ended up facilitating a discussion around the role of a designer in an agile environment, and it was nice to see that other people struggled where I do.Despite the gloomy day outside, the atmosphere was good and warm: it felt really good to be mingling with new people who are happy to share their experience and failure. For me the day was a great success:

• I made some contacts to help me with my daily job, passing on the agile love in my team (hint: subscribe to the Balanced team google group!)
• I learnt how to actually get people to share their failures (and learning) in a fun way. It’s common understanding now that failing isn’t an issue as long as we learn, but it’s still a bit taboo in some teams… the technique explained in this post will be great help!

So yes, all in all, it was a good day. I left with new contacts, a warm feeling inside, and the trust that people are happy to give up their Saturday to help their community… isn’t that great?”

Lessons Learned

After the event, the organisers Johanna, Michele and Spencer had a retrospective to capture lessons learned. Our top lessons were:

• Compared to previous London events, we had more first-timers than existing Balanced Team members. This meant that fewer folks had prepared stories to tell or case studies to share. Lesson learned: reach out to previous attendees before the event and ask them to prepare/contribute/lead sessions (e.g. sharing a case study/story, lightning talk).
• Find space for smaller, break-out sessions and discussions. One open space worked for a small group in 2014, but did not work that well for our rather large group this year.
• Organise an energising, facilitated post-lunch activity involving all participants - like Failure Swapshop.
• We put effort into inviting a mix of roles, to reflect the balanced team theme, and achieved diversity in attendees. We recommend to approach sending out invites to the event with this in mind.
• Actively seek participant feedback and re-plan throughout the day. A list of facilitation techniques would have been helpful to do this even better - something to prepare for next time.

Finally, if you run a not-for-profit, volunteer event, what do you do with any leftover cash? Due to the kind sponsorship of Cultivate, Pivotal and Unboxed, after covering the evening drinks bills we still had enough money left over from the small event fee to donate 8 places to Crisis at Christmas. This may be a model other Balanced Team Salons could consider.

[embed]https://flic.kr/p/BqcYHi[/embed]

Come join us! Get your ticket on Eventbrite

If you’re interested in Lean Startup, Agile, Lean, Agile UX, Lean UX, Devops, Customer Development – and anything else that values multi-disciplinary collaboration and iterative delivery of value – you’ll find this of interest.

Rough schedule for the day: 10-11am Breakfast, make new friends, meet old ones, generate conversation topics. 11am-3pm Break out group discussions, fishbowls, etc. 3-4pm Share learnings, closing circle, tearful goodbyes. 4pm Drinks nearby at a venue tbc.

Do come: If you want to spend a day actively learning with your peers. Don’t come: If you want to sit down and listen passively to presentations.

Thank you to our sponsors Pivotal Labs, Cultivate and Unboxed Consulting for making this event possible.

Venue: Pivotal Labs Bentima House 168-172 Old Street London EC1V 9BP

Balanced Team is hosting a spring Salon in Chicago on May 2nd, 2015 from 10am–3pm. It will be an open un-conference format focusing on sharing our experiences and good conversation. Those new to Balanced Team are encouraged to attend. Also, it will be a time to get the conversation started ahead of the Balanced Team Summit in Grand Rapids.

Those attending will help set the topics for the day in the collaborative spaces of Pivotal Labs’ Chicago office, inside the Merchandise Mart. We will have Balanced Team experts coming in from all corners to share their experiences.

Space is limited to best encourage good conversation, so RSVP today. Pivotal Labs will be sponsoring food and drink throughout the Salon.

Balanced Team Los Angeles is back and will be hosting an evening of conversation and consumption on May 20th, 2015 from 6:30PM to 9PM at Rhubarb Studios in Downtown Los Angeles.

If you’re interested in Lean Startup, Agile, Lean, Agile UX, Lean UX, DevOps, Customer Development—and anything else that values multidisciplinary collaboration and iterative delivery of value—you’ll find this of interest.

To facilitate conversation, we’ll follow the Lean Coffee format. The agenda is in your hands, so please bring your ideas or topics of interest. Balanced Team experts will be on-hand for those interested in learning more.

A HUGE thank you to Pivotal Labs for providing the food and drink!

For early arrivers (6:30-7:00), there will be a drone flying demo and a chance to ride a Onewheel.

Space is limited and registration is open, so register today.

In cooperation with LeanUX NYC, Balanced Team is hosting an evening of conversation and consumption on April 15th, 2015 from 6PM to 9PM. CompStak will host at 36 Cooper Square in Manhattan.

To facilitate conversation, we’ll follow the Lean Coffee format. The agenda is in your hands, so please bring your ideas or topics from the conference! Balanced Team experts from around the country will be on-hand for those interested in learning more.

And to facilitate consumption, beer, cocktails and hors d’oeuvres will be provided courtesy of Catalyst Group, CompStak and Pivotal Labs.

Space is limited and registration is open, so RSVP today.

Getting from LeanUX NYC to 36 Cooper Square

A Balanced Team tour guide will lead a group to 36 Cooper Square after the first day of the conference. Just keep an eye peeled and an ear open: we’ll rally somewhere at the conference venue and head over together.

To get there on your own…

• Share a taxi or ride-share service. You can get from Brooklyn to Manhattan via the Williamsburg bridge. That’s 5 miles or 15 minutes without traffic ($15+ by taxi).
• Take the subway. There are several routes that will work, depending on how far you want to walk, so check these Google Maps directions or buddy up with a local.
• When you arrive, just look for the Village Voice building, and head to the 6th floor.

For more information

Contact the event committee.

Learn more about Balanced Team and LeanUX NYC 2015.

“To me, if I had to explain the value proposition,” says Harlow, “it would be: Everything from startups to large companies, everyone from experienced people to people just trying to learn about it. And hopefully it becomes, similar to that story map: We’ve structured an event to allow for a purposeful conversation around, what does it mean to work among a diverse group of people with different skills and talents to accomplish things?”

Please check it out here, rebroadcast to your social circles, and then purchase a ticket for the event! Enjoy!

Visit the event website for more information on ticket sales, and of course the event itself.

Your planning committee: Matt Fletcher, Lane Halley, Rick Harlow, Brittany Hunter and Gail Swanson.

PS

Our call for proposals runs through February 6. We’re pleased with what’s come in so far, but we would love to hear some more ideas for great talks! Visit our CFP page for more information.

The session will run for a half-day starting late AM or afternoon, depending on the Lean UX NYC conference schedule and visiting attendees’ plans.

The event will include brunch/snacks, beverages, socializing, small group break-out sessions and a recap, similar to prior BT Salons. Topics are entirely open for consideration, and we’ll solicit ideas soon.

Looking forward to making new friends visiting for the week, and seeing NYC BT’ers, too! More info to come…

Submit a session proposal

Our theme this year is " Balanced Teams Everywhere"

Balance is action guided by incremental adjustments, rather than an achieved state. At the 2015 Balanced Team Summit, we will explore and share the latest techniques and innovations of Balanced Teams in different sized organizations in the software industry and beyond. Throughout it all, we’ll be considering the question, “What does it mean to be a balanced team?”

At its core, Balanced Team is a community and we’re eager to hear from your Balanced Teams. What Balanced Team techniques have worked well for you? What hasn’t worked well? What improvements have you made over the years that are worth sharing? Do you have a nagging question you want help from this group to answer? Are there big issues we need to address in the upcoming year to help build even better Balanced Teams?

Please let us know what you want to contribute. If you have more than one idea, it’s OK to submit more than once. We’re accepting submissions through Friday February 6th, 2015.

Submit a session proposal

Thanks for reading this, we very much look forward to seeing you soon in Grand Rapids!!

For more information, please visit the conference site

---

Hello friends! We are pleased to announce the theme for the Balanced Team Summit on June 13 and 14, 2015 in Grand Rapids, Michigan! Balanced Teams EverywhereBalance is action guided by incremental adjustments, rather than an achieved state. At the 2015 Balanced Team Summit, we will explore and share the latest techniques and innovations of Balanced Teams in different sized organizations in the software industry and beyond. Throughout it all, we’ll be considering the question, “What does it mean to be a balanced team?”

We’re working on launching our conference website and will make a call for submissions soon.

If you want to participate in the conversation about this event and help us plan, please join our Google group. If you would like to get announcements about Balanced Team events sent directly to your inbox, please sign up for our events announcement list.

Your planning committee: Matt Fletcher, Lane Halley, Rick Harlow, Brittany Hunter and Gail Swanson.

• The Girl With the Chisel Tip Marker (Lynne Cazaly)
• Intensifying User Stories (Bill Wake)
• Requirements, Product Ownership, and Other Misunderstood Concepts in Agile Development (Jeff Patton)
• Value Teams: The Next Evolution of the Product Owner (Ahmed Sidky)
• How to recognize the Zombie Persona Apocalypse (Michael Rawling)
• UX Runway: the trials and tribulations of a UX and Agile environment (Natalie Warnert)
• Creating Successful MVPs in Agile Teams (Melissa Perri)
• Go From a Nebulous Vision to Iteration One in 3 Steps (Mary Brodie)
• See the Value (Jeffrey Morgan, Ardita Karaj)
• Lean Startup Snowflakes (D. Andre Dhondt)
• How Agile UX and guerrilla testing helped change government policy (Kevin Murray, Imran Younis)
• The Anatomy of an Experience Framework: How to Create Better Products With Your Customers (Martina Schell)
• Build Products that Matter with Innovation Accounting (David Bland)

You also might be interested in:

• Antonella Cachia’s review of some of her favourite Agile 2014 sessions
• This video of Ahmed Sidky talking about Value Teams earlier this year
• Jen Siomacco’s review of some of the UX related sessions
• Natalie Warnert interviewed about the ‘UX Runway’ at Agile 2014
• Mary Brodie writing about needing a vision for agile projects earlier this year
• Andre Dhondt’s write up of his Lean Startup Snowflakes game
• Davis Hussman talking about Lessons in Gravity, one of his Agile 2014 sessions
• David Bland on How to Build Products that Matter at Agile 2014

If we missed anything please let us know at crew@quietstars.com!

(excerpted with permission from " The Agile & Lean UX News #15")

RSVP on Meetup

Instead of sitting down and listening to a few presentations, we have designed an activity for every attendee to participate in discussions and generate ideas together. Come prepared because it will be filled with plenty of conversations from people in the community sharing ideas, socializing, and offering insights from their own experience.

If you’re interested in Lean Startup, Agile, Lean, Agile UX, Lean UX, DevOps, Customer Development—and anything else that values multidisciplinary collaboration and iterative delivery of value—you’ll find this of interest.

To ensure the quality of the activity, this event is capped at 30 attendees. It is free and first come, first serve. Please RSVP at our meetup page and feel free to invite new folks to come along. We know that our diversity always makes the conversation more fun!

Many, many thanks to our wonderful sponsor, Fandango, for providing food, drinks, and materials!

RSVP on Meetup

Update 11/24: Balanced Team Summit 2015 Theme announcement

---

We’re pleased to announce that we will be holding a Balanced Team Summit on June 13 and 14, 2015 in Grand Rapids, Michigan! The planning committee is made up of Rick Harlow of Visualhero, Gail Swanson of Manifest Digital, Lane Halley, and Matt Fletcher and myself, Brittany Hunter, from Atomic Object.

The event is a year from now, so we’ve got plenty of time to plan a great conference. Currently, we’re working to secure a great venue and choose a theme. We’ve got some great ideas, but everything is under consideration at this point. Is there a particular theme or question you’ve been wondering about and would like to further explore with fellow Balanced Teamers? Let us know by filling out our quick google form!

We are all super excited to host the conference next year. See you then!

Tickets are available on Eventbrite now!

If you’re interested in Lean Startup, Agile, Lean, Agile UX, Lean UX, Devops, Customer Development – and anything else that values multi-disciplinary collaboration and iterative delivery of value – you’ll find this of interest.

Don’t know what Balanced Team is about? Read about the history of Balanced Team, check out our blog posts, and see some of the things that happened at the last Balanced Team London.

Rough schedule for the day:

• 10-11am: Breakfast, make new friends, meet old ones, generate conversation topics.
• 11am-3pm: Break out group discussions, fishbowls, etc.
• 3-4pm: Share learnings, closing circle, tearful goodbyes.

Do come: If you want to spend a day actively learning with your peers. Don’t come: If you want to sit down and listen passively to presentations.

Remember - tickets are available on Eventbrite now!

Thank you to our sponsors Neo & Pivotal Labs for making this event possible.

Venue:

Pivotal Labs Bentima House 168-172 Old Street London EC1V 9BP

[caption id=“attachment_1028” align=“aligncenter” width=“690”] Image courtesy of Jordan Presnick (@JordanPresnick)[/caption]

Salons have proved themselves to be a lightweight version of a larger un-conference event. At this Salon in San Francisco we had several lightening talks recounting some highlights from the New York experience by Courtney Hemphill and Alexa Roman.

We then opened it up to our favorite tool for engagement - the fishbowl. We seeded the endeavor with a broad question open to lots of interpretation… What is Balanced Team? As there were several new faces, there was a good amount of fodder for the bowl that followed.

[caption id=“attachment_1029” align=“aligncenter” width=“710”] Idea Generation [/caption]

The question that received the most dot clusters was the topic on everyone’s tongues: How does Balanced Team fit into organizations: top down or bottom up? For those of us that have confronted this problem, it was easy to surface the issues and throw around some stories of experiences and the learning that was captured from them. The one truth that we can all agree on is that it is invariably hard but always worthwhile. As to be expected, the secondary and perhaps more important component of the event was the time available for old friends to reconnect and talk about their work and passions.

A latent issue that at times would surface during the conversation was the lack of true balance in the attendees at large. We are all practitioners on the design and development side of the product creation process. The missing voices that have the potential to truly balance our work still felt either underrepresented or fully absent. The knowledge, needs, and ideas that come from those working day to day in the fields of ethnography, marketing, sales, business strategy, etc are critical components to the successful execution of ideas. I very much hope to see future Balanced Team events reaching further and further out into our extended networks to bring those voices to the conversation and ignite the future fishbowls with some lively discourse.

Here are some additional photos courtesy of Alexa Roman.

We’re pleased to announce a Balanced Team Salon April 24, 2014 at Carbon Five in San Francisco CA.

RSVP on EVENTBRITE

Salons are becoming popular format in the BT community as they involve plenty of networking, short talks from people in the community sharing what they’ve learned and then a fishbowl - a collaborative, inclusive conversation that allows many people to get involved and share.

With quite a few people in our SF community coming back from an amazing day-long BT NYC Salon we thought we might bring some of that energy and discussion back home. Our talks will share some of the learning and intrigues from the Salon and Lean UX 2014 conference. And then we’ll pull out some of the more intriguing themes and topics that were discussed as starters for our fishbowl.

Please feel free to invite new folks to come along. We know that our diversity always makes the conversation more fun!

RSVP on EVENTBRITE

AGENDA

6 PM - Food and libation 6:30 PM - Short Balanced Team intro 6:45 - 7:30 PM - 3 10-minute talks 7:30 PM - Fishbowl ideation introduced 7:50 PM Fishbowl voting 8 PM Fishbowl Networking until close

RSVP on EVENTBRITE

deLUX is happening again this year at SXSW!

Please join us March 7 for some beers & bites at sunset on the beautiful patio at Adaptive Path, followed by a short program from some of the leading practicioners in the Lean / Balanced Team community.

Program Starts @ 6:30pm. Short talks from:

• Jeff Gothelf, Neo Principal and author of LeanUX: Applying Lean Principles to Improve User Experience
• Jeremiah Gardner, Handcrafted Brands Principal and author of The Lean Brand
• Alissa Briggs + Raman Hansi, Intuit Innovation Catalysts and SXSW 2014 Speakers
• Chris Nodder, Interface Tamer and producer of Questionable Methods.

BUY TICKETS ON EVENTBRITE

The plan: gather everyone for brunch (Bagels! Mimosas!). Generate topics of interest. Split into small groups based on topic. Discuss in groups, and create a poster. Present a summary of the poster. Go home, chill out, enjoy what’s left of the weekend. (Or maybe head to the bar w/ your Balanced Team friends!) Plus a helping of the Balanced Team fixtures (Welcoming new community members! Fishbowls! Closing circle!) that’re starting to become community rituals.

We’re announcing the salon to the BT community first. In a few days, we’ll announce to the LeanUX conference Tickets are $10, and available via Eventbrite. Scholarships are available if the cost is a hardship; just email me off-list. Event details will be managed through Lanyrd.

Please join us!

• Buy tickets on EVENTBRITE
• View more event information on LANYRD

Schedule

09:00 SET UP10:00 DOORS (45m)brunch, socializing10:45 WELCOME (30m)Balanced Team history, introduce CONVERSATION ACTIVITY11:15 GENERATE (30m)start to generate topics, (put topic and NAME OF PROPOSER on sticky)11:45 DECIDE (15m)dot vote, assign topics and leaders to conversation areas12:00 CONVERSATION ONE (30m):People start first break out sessions, facilitator makes poster12:30 STAND-UP (15m):one speaker from group summarizes poster in a sentence. Next round of topics is circulated12:45 BREAK (30m):snack, form 2rd groups13:15 CONVERSATION TWO (30m):facilitator makes poster13:45 STAND-UP (15m):each group gives a 1-sentence description14:00 BREAK (15m):bring posters to central area, people can review/comment on posters14:15 REASSEMBLE (15m):explain FISHBOWL14:30 FISHBOWL (60m):moderated group discussion15:30 CLOSING CIRCLE (30m):each person says one thing they will take forward16:00 ANNOUNCEMENTS:Adios! What’s the next event? What’s the next bar? Off to the bar

To prove that design is driving business, you need specific, targeted data.  We often test conversions by A/B testing two different layouts or copy variations.  But, there is another layer to these metrics - the emotional resonance of design.  Aesthetics can play a profitable role in customer interactions.  Designers take great care in establishing and evolving a brand.  Yet, we don’t have a strong rubric for measuring visual choices.

At the last Balanced Team, Andrew Korf presented how he was working through this challenge at NativeX and offered the topic up for an open space dialogue.  A group of us gathered to develop a framework for metrics-based design.  More specifically, we aimed to validate aesthetic design choices with data.

We’ve created a resource for this information and hope to build on it with your contributions.  Please feel free to add any ideas, blog posts or links in the comments here or tweet us @BalancedTeam with #DesignMetrics.

http://designmetrics.github.io/

Over lunch, the group was asked to think about one or more “conversation topics you’d like to lead.” We collected these topics on sticky notes and put them on the wall. Each speaker briefly introduced the topic they wrote and then the group placed a pen mark on up to three of the topics they would like to participate in. (also called “dot voting”). The topics with the most dots were assigned rooms. People assembled in the rooms that interested them. The conversation hosts were encouraged to share back the outcome of their conversation with the group afterwards through a blog post and/or coverage on the event.

If you want to learn more about Open Space Technology, I encourage you to read this Wikipedia article.

Selected topics

These were the topics the group selected for conversation

• Experiment Mapping workshop
• Lean is for Discovery, Agile is for Delivery
• Experience Wheel workshop
• Let’s Create a framework for metrics driven design
• Why is the Balanced Team conference not balanced? Does the split indicate that balanced team is a design insurgency? 60% design,20% dev, 20% pm. What about researchers and social scientists? There are only a handful here and yet they bring tremendous value to a “balanced team.” How do we really know? Can people share why they were drawn here this weekend? Maybe they don’t fit neatly into those categories\
• Workload prioritization / management tools

Proposed Topics

These are the proposed conversations which were not selected. I include them here as a historical record and perhaps they will provide fodder for future presentations or blog posts?

• What do you do when there really is a “lone genius” with a good vision? how can collaboration be facilitated?
• What are the roles & handoffs of Product, UX and Development?
• Human interactions collaborations and building relationships between team members
• What’s this “Lean” thing?
• Starting a balanced team: how to get organizational support for starting a balanced team process?
• Why is design ’never done?'
• Horizontal vs vertical change
• How is it possible to build trust in community?
• Worst experiences in integrating customer & product development
• What tools do you use? Prototyping, task management, remote communication
• How can we use our design skills to help self-organizing teams design their process(es?)
• How to collaborate with other UX peeps (i.e. user researcher, strategist, IA, UX designer, Ninja?)
• What do you do / where do you go for UX inspirations?
• Educating clients or non-UX people about UX while at work
• How to deal with concensus & ownership moving forward (making progress) in an unbalanced team (and not)
• Is lean-agile-balanced just serving intersets of capital
• Documentation when you’re moving so fast. How do you keep track of decisions/data over time?
• Common language across teams, business/dev./design & stakeholders
• Next event BTNY2014
• Ways to get Lean / Agile to wider community
• Mock-ups are lies! Work in the medium
• Process share
• How do you reconcile business needs and user needs?
• Cognitive illusions that screw up our work
• Mind-time & Build-measure learn & collaboration
• When are high-fidelity mockups appropriate / useful / most efective
• Systemizing UX techniques
• Lean is from Product, Agile is from Engineers. What does Design contribute?
• Staying balanced when scattered: tools & techniques for remotely distributed teams
• Discovery: How does a balanced team functino as a whole in the ideation / customer discovery phase?
• What is “good design” Journal paper review and conversation
• How to be Lean/Agile w/o sprints/iterations
• How much design should be done in the browser?
• UXing vs. PMing: User reserarch to drive features? Product strategy, marketing
• What does “design thinking” mean to you?
• How do you continuously get customers invoved in B2B (bribes, fame?)
• “Design Enough” with the spectrum of design product - what is enough?
• Pitching design thinking to close new accounts
• The roles of Sales / BD in a balanced team

Reflections

Here are some thoughts that I pulled together from the reflections as well as some of the overall highlights from the weekend:

Bloom and Intelleto Witnessing two long time BT alum in their new roles and exciting new endeavors was a total treat. Thank you to Kate Rutter for her excellent sketch notes and to Becky Gessler for her delicious coffee.

Structured vs Unstructured We chose to have more structured content (ie talks) for this event but many responded that they wished for more unstructured time to informally interact, chat over coffee, have time for questions and do more ‘unconference’ style work sessions.

Ideal size Although a larger event was a bit more work to organize, it seems as though people still felt that it was intimate enough and yet broad enough to get new voices heard. Perhaps somewhere around 75 there is a magic number for human interactions?

Talk length There were lots of comments on the talk lengths. Some felt the lightening talks were too short and some felt that 40 minutes was too long. Universally people responded that they liked the fishbowl. Having time after talks for questions and group discussion reaped the most reward from the wealth of brain power at the event.

Open sessions More, more, more! Everyone loved these. Lots of +1s

Quotes

“I loved the experience. Usually conferences are for specific fields - engineers go to engineering conferences, designers go to design conferences - but at balanced team there was a mix of disciplines. So when I told people at balanced team SF that my work is in research, everyone asked me questions!”

“More balanced approach to all disciplines - barely any Product Managers or Developers represented”

“It was one of the most insightful and productive conference I’ve been to. I love the more intimate feel, and made some great contacts and shared some interesting thoughts on my personal experience, as well as heard great stories from various fellow PMs.”

“I loved the size and the group of humans was inspired. The mix of skills was also intriguing. The organization was really nicely done!”

“Hemming and hawing over “are there enough business people?”. We’re fine.”

“…it was just the sort of interaction and conversation I feel we need more of throughout the product development world! It was something I had not even realized that I needed, until having experienced. I think there’s many more people like that… I was very happy to be captured into Balanced Team’s orbit.”

“great people all around - not sure how you screen for that but the quality of the people was exceptional”

LOVED IT! Incredibly valuable! Everyone who came contributed and that was key - no matter who I was talking to, I knew we had common values and that may be the biggest challenge as BT grows. Really wonderful, fulfilling, exciting event.

Check out what others had to say:

Alexa Roman - Shared Values, Common Culture

Kate Rutter - Balanced Team Pie Carbon Five Blog

Chris Nodder - Photo Slideshow

Twitter List - https://twitter.com/calexity/lists/balanced-team

Buy tickets on Eventbrite Submit a session proposal using this form For more information, see the event site.

Speaker list for Balanced Team London 2013 on Lanyrd

We’ll be giving more details of the outputs from the event soon. Some of the areas we covered included:

• What is a balanced team?
• Collaboration hacks
• “Data with soul” not “Data vs. soul”
• Fostering relationships in distributed teams
• Managing stakeholders

In the meantime you can see some photos and tweets from the event over on storify.

(If you attended the event yourself please feel to add to the above storify link)

And finally - a massive thank you to our sponsors - Mozilla, Method, & Neo - that made the event possible.

For more information and to RSVP, please visit our Meetup group.

Please write a topic (or two) of interest for today

• Embedding marketing

• Unicorns - what are they - do you need ’em?

• Product owner teams - report from the field

• Live style guides first movement

• Timing of design thinking vs. lean

• Making vs. thinking: pace & vanity progress

• If our currency is shared understanding, let’s talk about quality & values

• Lane’s “learn to code” trip report

• Product manager vs project manager?

• Product manager/owner think they are the customer (no research)

• Care & feeding of the engine of construction

• How to effectively bring designers into Agile/Lean development?

• Convincing management to build NEW products that solve a problem (aka not Facebook for pets)

• Josh, Giff, Jeff should buy a makerbot

• Convincing management that user research is good when they are scared you won’t come off as experts (B2B)

• How do we assess what is the “minimum desirable things” that will convince users and/or sponsors?

You can see a set of photos from the event on Meetup.

Then you should fill in this 3 question survey now.

Don’t know what Balanced Team is about? Go read the history of Balanced Team and check out the Balanced Team 2011 and Balanced Team 2012 conferences.

Basically - if you’re into Lean Startup, Agile, Lean, Agile UX, Lean UX, Devops, Customer Development - and anything else that values multi-disciplinary collaboration and iterative delivery focused on customer value - you’ll probably find this of interest.

Discussion on further details will happen on the Balanced Team mailing list. You should join the mailing list too.

Thanks - and hope to see you at Balanced Team UK 2013.

Many thanks to our 2012 event sponsors: IDEO, Carbon Five, Mutually Human, Proof, Atomic Object, Sapient Nitro, Groupon, { New Context }, UIE and Lean Dog. The event was much richer for your support and participation.

Conference Partner

Diamond Sponsors

Platinum Sponsors

Gold Sponsors

At the un-conference portion of the event, I facilitated an activity to collect learning resources the participants personally used and found helpful to broaden their skillset. Here’s the list for your reference and reading enjoyment!

Ways To Learn

• Pairing and working near pairs for getting context
• Find a front-end mentor so you’re not confused by what you read
• Code Academy, for an intro to JavaScript
• W3 Tutorials for getting unstuck with specific problems
• F orrst, a community of developers and designers
• nerdi.net, a web developer toolbox
• Rails Bridge, women coding together, power+energy
• Skillshare, esp. financial modeling for entrepreneurs with Taylor Davidson
• Stack overflow, for getting answers to code/dev questions
• Rails Tutorial, for learning rails
• Treehouse, Web training website with gamification elements (HTML, CSS, JavaScript, Ruby)
• Smashing Magazine(and books), general Web and design and UX and fontend dev
• A Book Apart, series for deep dives into current thinking
• Big Nerd Ranch, iOS programming
• UIE UI conference, full day workshops on UX critical skills
• UIE virtual seminars

UI/UX

• Inspired: How To Create Products Customers Love, Marty Cagan, good description of team roles
• Rosenfeld Media books, esp Web Form Design book by Luke Wroblewski
• Google search " UX Design Patterns"
• The Noun Project for icons and vectors
• Twitter hashtag #ux for finding resources on topics
• Yahoo design pattern library
• The Non-Designer’s Design Book, Robin Williams
• Follow Mike Lane ( @mlane) on Twitter. He posts lots of great design, UX and code resources

Typography and Graphic Design

• Kuler, browse color combinations
• Dribble, show and tell for designers
• 300 Mobile Icons, Bill Reid, great for quick icons (could not find a link, sorry!)
• What the Font, figure out what a font is from a sample, explore fonts by characteristics
• FFFFound, inspiration, has a great mobile app
• Pintrest for design and typography inspiration
• Evernote, keep track of your audio, pictures and notes anywhere
• Behance, online portfolio site, use for design inspiration
• Gimmie Bar, good for bookmarking things you like
• Lost Type, great, free typefaces

Front End Development

• CSS Tricks, how to take advantage of CSS
• Scout, tool for Compass, SASS
• W3C markup validation service
• Burlington Web App meetups and demos (could not find link, sorry!)
• Vandelay Design, curated resources, mostly Web design
• Susy, CSS framework for responsive Web
• Designing with Web Standards, Jeffrey Zeldman, explains the philosophy behind modern web thinking
• Twitter Bootstrap, for basic web templating
• Bootswatch, bootstrap themes
• CSS3 for Web Designers, Dan Cederholm
• JavaScript, the Good Parts, short, sweet, JavaScript resources
• CSS Mastery, Andy Budd
• Hack WordPress templates to experiment with PHP, HTML, CSS
• Use Firebug to edit HTML/CSS of any page
• Use Sass, Haml for saner coding

CULTURE

• Qualities of a company that can produce good UX: Vision, feedback loops, culture (per Jared Spool)
• Design the organization for balance
• Process leads to culture, culture is established by leadership
• Culture is what you make it. Culture your culture
• Leadership matters
• Designing the product means you have to design the business, which covers the end to end user experience

VISION

• Focus on output over outcome (referencing something Jeff Patton said)
• Experience defines features, and helps determine right MVP

INTERACT with USERS/CUSTOMERS

• It’s not enough to build process to know your users. It’s vital that people get to see it first-hand
• Kidnap the CEO and take him/her to see users
• Buyer goals and user goals are connected

POLY-SKILLED PEOPLE

• More skills, smaller teams
• Broken comb people (+3) [per Jared Spool’s presentation]

TEAMWORK

• I’m going to hire a designer so we can have a more balanced team
• Involve everyone in design thinking and focus on the product
• Experience is important to having a good product and interpersonal relationships. Focus on good experience leads to better work.
• How UX principles apply to the product and organization. Everyone is involved in the UX of the product
• The power of integrated thinking
• Bring developers on board early, help them see the big picture
• Designer-as-facilitator (+1)

HOW do we KNOW it’s GOOD?

• I will test my hypothesis and get validation
• How do we check for results as we try to make “better products?”

SERVICE COMPANIES and FREELANCE considerations

• People said there’s a transition in power as they go from consultant to in-house. Does this have to be true?
• As a service org, how can we manage the expectations of our clients and influence their decisions?
• Likes the idea of charging by feature (as discussed by 8thLight)

The BALANCED TEAM COMMUNITY

• I met like-minded people (+1)
• I liked learning about balanced team
• I’m not alone
• Nice to be with the other kool-aid drinkers
• We are fellow travelers who can help each other with day-to-day tactics
• I’m not crazy, other people think like I do
• There are people out there who can help me
• Your passion feeds mine
• Great to meet people who are doing it and have advice for other people in the group
• Appreciated the trust, respect and openness of the group

FUTURE of BALANCED TEAM group

• We’re going someplace together. Where next?

PERSONAL REFLECTIONS

• There are different solutions for different situations. It’s OK to move/change jobs/careers
• Lots to think about, thanks

The conference runs Friday evening, June 22 through Sunday afternoon, June 24 at IDEO’s offices at 626 W Jackson Blvd (thanks, IDEO!). See Lanyard.com for the conference schedule. We suggest that you book accommodations early, Chicago is full of summer conferences.

The theme of the conference is “Welcoming the Business Perspective to the Balanced Team.” At our last conference in 2011, Dale Larson gave an important talk, asking the group why there were no business people in the room. Who was selling and marketing all the great things we were designing and building, and why weren’t they a part of the conversation?

Together we will explore how the goals and activities of business, design and development can and should work together. We will move past the us vs. them thinking that holds us back. We will share ways for people with these skills to cross-pollinate within organizations.

The rough schedule is as follows:

• Friday afternoon optional event: Visit Chicago’s brand new not-for-profit startup community and co-working space, 1871, in Chicago’s Merchandise Mart
• Friday evening: Welcoming reception with food and networking (location TBD). Please try to make it to this, especially if you are new to Balanced Team, because we will help get you up to speed.
• Saturday morning: Several prepared talks
• Saturday afternoon: Fishbowl, then planning Sunday openspaces/unconference workshops
• Sunday morning: workshops
• Sunday afternoon: share outcomes of the workshops and close

If you are interested in giving one of the prepared talks on Saturday, please contact me at moses@humanpractice.com. We look forward to seeing everyone in Chicago in June!

Thanks to our fantastic sponsors, Adaptive Path, UIE, {new context}, Rosenfeld Media and LUXr!

To register for the event via Meetup, please use the link below. RSVP

Josh Seiden, LUXr " Balanced Team, September 2011"

Shawn Crowley, Atomic Object " Balanced Team Conference 2011"

Bo Campbell " Diplomacy, the greatest UX asset"

A collection of all coverage and resources.

General Presentations are up on Slideshare. Check out the #balconf search, and the Balanced Team channel. The Lanyrd page for the event has an overview of the schedule, speakers, and links to the coverage. Chris Nodder took great photos that you can find here on Flickr. If you took photos, please tag them with #balconf and add them to the photo group. People were tweeting funny and smart things - check out the Twitter search for #balconf.

We’re working hard to get the videos for all sessions up. In the meantime, you can watch the videos from the uStream Livecast. Below is the coverage and associated resources for each conference session.

What do we mean by ‘Balanced Teams’?

“My process journey - How I learned process isn’t what you think it is” by Jeff Patton (AgileProductDesign)

SlideShare | Notes “Lean UX Landscape” by Janice Fraser (LUXr)

SlideShare | Notes “Balanced Team at TheLadders.com” by Greg Jones (TheLadders)

SlideShare | Notes Fishbowl: Jeff Patton, Janice Fraser (LUXr), Greg Jones (The Ladders) Notes

Creating & sustaining Balanced Teams

“Lean UX Principles in Practice - SideReel’s iOS App Case Study” by Zach Larson (Side Reel/Rovi)

SlideShare | Notes “The client and us!? Applying a balanced team mindset in agencies” by Johanna Kollmann (EMC Consulting) SlideShare | Notes “Building a startup’s balanced team culture from day one” by Moses Hohman (Human Practice)

SlideShare | Notes Fishbowl: Zach Larson, Johanna Kollmann, Moses Hohman Notes

Cross-functional success

“Cross-functional Pairing: What it is and why you should be doing it” by Anders Ramsay (Independent), Jef Bekes (ThoughtWorks), Michael Long (ThoughtWorks)

SlideShare | Notes “Including Marketing & Advertising on Balanced Teams” _by Dale Larson (Startup Happiness)_Notes Fishbowl: Anders Ramsay, Jef Bekes, Michael Long, Dale Larson Notes

Balanced requirements

“Transforming UX integration from reaction to strategy” by Desirée Sy (Autodesk)

SlideShare | Notes “Test-driven design” by Joshua Seiden (LUXr)

SlideShare | Notes “Hybrid Interviewing” by Lane Goldstone (LUXr)

Hybrid User Interviews

SlideShare | Notes Fishbowl: Desirée Sy, Joshua Seiden, Lane Goldstone Notes

Balanced planning

“Story Maps & Backlog Co-ordination” by Shawn Crowley (Atomic Object)

SlideShare | Notes

Fishbowl: Shawn CrowleyNotes

Balanced skills

“Nordstrom Innovation Lab case study” by Jeremy Lightsmith (Nordstrom Innovation Lab) Notes “UX Coaching: Helping developers become better generalists” by Chris Nodder (Independent) SlideShare | Notes Fishbowl: Jeremy Lightsmith, Chris Nodder Notes

Multi-track sessions

“Design Charrette” by Michael Long (ThoughtWorks) and Anders Ramsay (Independent) “The UXI Matrix: An Information Radiator for Agile UX” by Jon Innes (UX Innovation) SlideShare “UX in an Agile Environment” by Jonathan Berger (Pivotal Labs) “Quick, Easy, Valuable User Testing of Design Concept” by Steve McKiernan (Health Net Inc.) SlideShare

• We’re on the Lanyard social conference directory.
• We’re streaming (and archiving) video from the event at UStream.
• Our twitter hashcode is #balconf

Update: Please see the resources page for a full list

To see the full event schedule, please check here.

Opening Panel: Balanced Team Perspective s  - Jeff Patton (AgileProductDesign), Janice Fraser (LUXr), Gregory Jones (TheLadders)

Each speaker will present a 10-minute overview of the work they are doing that relates to Balanced Team. We’ll then shift into fishbowl so individuals can respond and share their own stories. We need one or more visual recorder to take notes during this talk to collect themes and set context for future sessions.

Cross-functional Pairing: What it is and why you should be doing it - Anders Ramsay, Jef Bekes and Mike Long

Anders Ramsay will provide an overview of cross-functional pairing, with Jef Bekes and Mike Long presenting a case study from work done at ThoughtWorks Studios.  Topics discussed will include group sketching, use of a prototyping framework, and designing in the browser vs designing with PhotoShop/Wireframes.

Hybrid Interviewing For Effective Customer Conversations -  Lane Halley

Traditional UX process often includes a round of research to understand customer context, needs and motivations, followed by design work, followed by a round of usability testing of some sort of artifact (model, prototype, or product). Several startup teams Lane advises are successfully using a hybrid approach which combines research and response to an artifact in a single feedback session. In this talk, Lane will provide a brief overview of how some familiar UX techniques can be adapted for Lean Startup Customer Development and share some best practices for how Balanced Teams can plan, conduct and debrief customer feedback activities.

Managing Balanced Team Projects: Story Map and Backlog Coordination -  Shawn Crowley

Story maps easily represent releases of features that help users accomplish goals. Story maps help show what features should be delivered to create a compelling software experience. Agile projects commonly use task backlogs to manage scope and burn charts to track velocity and predict delivery dates. Simple backlogs and burn charts do not effectively show intermediate accomplishments of value. Expectations outside of the core product team can be more effectively managed by discussing functionality and delivery dates represented in a story map. Coordinating an integrated task backlog (both design centric and code centric tasks) with a story map allows for better scope management and team skills management aimed at hitting intermediate milestones. Disclaimer - This talk outlines thoughts on process and cites actual project examples utilizing several software and paper tools. A “silver bullet” software tool will not be revealed.

Balanced Teams - The Marketing and Advertising Team Member’s Perspective - Dale Larson

To date, Balanced Teams seem to have focused mainly on the product development side of the house: bridging gaps between programmers, designers and product managers and including all three as product owners. The larger divide in most companies, however, is between product development and marketing, sales and advertising. How can they be included and contribute their best talents from the start and made to feel that same sense of ownership for the overall user experience? How can they more effectively draw on the rest of the process and the team as they work to help not only the product but the business to be more successful?  Regardless of the titles of people who bring them, what are the skills and roles we want to draw on, and what’s the Venn diagram for how they most commonly intersect? (Perhaps we could make the list and draw that diagram together as a group.)

UX in an Agile Environment - Jonathan Berger

Jon will lead a discussion about various strategies of integrating UX practice and Agile Development, talk about pacing and mock-up techniques, and share his experience with three years of Pivotal-Tracker-oriented Test-Driven Development at Pivotal Labs.

Balanced Team in an Agency Context: Can it Work? -  Johanna Kollmann

Johanna will provide an introduction, based on her experience and stories that others told her, about working in a ‘balanced’ agile team in an agency context. She will discuss a) how it might work and b) why she’s skeptical. Following this introduction, she would like others who work in an agency context could share their stories. This could work well as a fishbowl or small-group discussion (if we have multiple sessions at the same time). A note-taker capturing the discussion would be helpful.

Introducing UX to Organizations: It’s About Organizational Culture and Decision Making -  Alison Austin

Large organizations are (typically) their own worst enemies; crippling potentially great products with dysfunctional processes and decision-making. In this context, embedding UX practice is not simply a matter of focusing on deliverables. Instead, I’d like to consider how far into an organization’s culture ‘agile’ thinking needs to permeate, as well as how agile/ux principles can be applied across organization departments to facilitate the breaking down of departmental silos.

Transforming UX Integration From Reaction to Strategy - Desirée Sy

Desirée recently taught UX practitioners new to agile a 1-day tutorial, and then was in a workshop with experienced agile UX practitioners–back to back. She saw patterns…To get to the next level of successful UX integration into balanced teams, UX activities need to do more than just path clearing (usability testing, rapid prototyping, fixing problems). They need to extend to path finding activities (user research, setting design goals, backlog planning, and defining ‘done’).

The Nordstrom Innovation Lab -  Jeremy Lightsmith

The Innovation Lab at Nordstrom starts an experiment every 1-2 weeks.  Each one has a learning goal, hypothesis, and expected outcome.  Because we start projects so often, we’ve gotten really good at doing it, and we want to share our process with you. Our goal is to quickly learn which ideas in retail technology are worth further investment (and what that might look like) and which ideas we should drop. Our makeup is also quite “balanced”.  We have 2 devs + 1 designer + 1 UX specialist.  We start together and then alternate between pairing, solo work, talking to internal / real customers, and bringing back new information to the team.  We’ve pulled ideas from Agile, Lean, Lean Startup, IxD, Design Thinking, and anywhere else we could find them, but we’re also quite young (6 months).  So we’d love to hear what ideas you might have for us that would help us innovate.

Building a Startup’s Balanced Team Culture From Day One -  Moses Hohman

Wearing many hats is typical in early startups, so you would think there would be no problem being a balanced team. But even at an early stage there are many opportunities for imbalance, and these can have long-term effects on company culture. Moses will present what some of these opportunities are, principles for counterbalancing them, and solicit your discussion.

Principles of a Successful Team - SideReel Case Study -  Zach Larson

Zach will discuss the 9 LeanUX principles and how his team used them as they built and exited a company. Few of the principles were intentionally picked but most became apparent once codified. He’ll specifically talk about a few key practices (Information Radiators and Vicious Prioritization) that helped make the SideReel team a phenomenal success.

Quick, Easy, Valuable User Testing of Design Concepts -  Steve McKiernan

User testing doesn’t need to be complicated to be effective.  When done right, it can help you catch problems early, get ideas for future enhancements, and increase customer loyalty.  Steve will share his experiences moderating external user testing sessions at Health Net, Inc. and offer tips on keeping testing simple but successful.

Write better stories with comparisons -  Austin Govella

“Any team’s biggest hurdle is communicating with a common language, so that when one person says jump, everyone else already knows how high. Adding interface and service comparisons to your user stories helps everyone on the team develop a clearer, more consistent image of what a user story entails, including defining what done means. And you can communicate complex interaction design without having to create a single sketch, wireframe, or prototype. Austin will go over two examples: one where we evaluate done for a story, and another where the comparison clearly communicated a complex rich, dynamic interaction.

Design Charrette - Mike Long

Rapidly generate design solutions while leveraging the various aptitudes and interests in your team. Charrettes are a form of “inquiry by design:” asking, examining, investigating, questioning and therefore learning through design.

The Balanced Team Conference is happening Friday Sep. 23 – Sunday Sep. 25, at the Hot Studio offices in San Francisco. I think you’ll agree this is going to be a special event you won’t want to miss. To apply, please register here.

Thanks to our generous sponsors!

Conference Theme: Getting Practical During previous retreats, our focus has been on gaining a big-picture understanding of how Agile and UX methods can be unified.  Now, we’d like to shift gears to exploring the nuts and bolts of what makes Agile, Lean, and other forward-thinking design teams happy, healthy, and successful.

Program The event will be a combination of pre-selected sessions and open spaces unconference sessions.  We will be encouraging everyone who attends to come prepared to either give a talk, do a workshop, or participate in a panel, to share practical techniques that have helped their teams be successful, as well as techniques that have failed and the lessons that were learned.

For an update on the program topics and speakers, please click here. Sponsors This is a volunteer run event, and we depend on sponsorships to help us pay for food and supplies.  We’re grateful to the following generous individuals and organizations who make this event possible.

Hot Studio | Jeff Patton |  LUXr |  DesignMap | Carbon Five

Innovation Games Online |  Lynda.com

When and Where The conference will take place Fri Sep. 23 - Sun Sep. 25, at the wonderful Hot Studio offices in San Francisco.

Registration

This event is now SOLD OUT. Information about the conference proceedings will be posted on this blog. You can also join the Balanced Team Google Group to join the conversation and learn about future events.

User-Centered Agile Method by Hugh Beyer

Four Steps to the Epiphany by Steven Gary Blank

The Entrepreneur’s Guide to Customer Development by Brant Cooper & Patrick Vlaskovits

The Back of the Napkin by Dan Roam

Unfolding the Napkin, The Hands-On Method for Solving Complex Problems with Simple Pictures by Dan Roam

101 Things I Learned In Architecture School by Matthew Frederick

Agile Software Development with Scrum by Ken Schwaber & Mike Beedle The book that formalized Scrum.

Extreme Programming Explained: Embrace Change by Kent Beck The book that formalized XP. Both the first and second editions should be read - they’re interestingly different.

Implementing Lean Software Development and Lean Software Development: An Agile Toolkit by Mary & Tom Poppendieck Early books that really looked into applying lean concepts in a software context.

Kanban by David Andersan

I believe it was in a conversation with Janice Fraser that I first started talking about DRY Documentation. It was certainly she (among others) who goaded me into actually writing this blog post. So I’m taking a moment on my WiFi-free (and generally amenity-free) United Airlines flight to SXSW to put pixel to screen.

DRYness is an age-old concept in the Agile space (to the extent that that’s possible in a space that’s only 10 years old itself) and it’s elegant in its simplicity. DRY simply stands for Don’t Repeat Yourself. The idea is that you should only do any one thing in code in only one place. If, for example, you are doing an interest rate calculation, don’t copy and paste the code from one place where you need it to another: instead, move that responsibility to an object that reasonably should be responsible for such things, and do that interest rate calculation only in that one place. The reasons for this being important are manifold, but perhaps the canonical reason is so that it’s easy to change: When the interest rate calculation changes, you don’t have to go digging through your code to find all the places you do it, and make sure you change them all consistently. Instead, you change the code in only one place.

Hopefully this is old hat for most coders now, and hopefully you, gentle reader, will forgive me my oversimplifcations and conflations. The point is one of simplicity.

So now, let’s shift focus to design documentation. The idea I’m trying to express when I talk about DRY documentation is one again of simplicity, though the drivers are perhaps a little different.

The mental model for truly DRY documentation is one in which every pixel on the page tells you something you didn’t know before. Of course, like DRY code, it’s worth being pragmatic. There are times when greater clarity can be gained by a certain amount of contextual restatement. But as a theoretical goal state, it’s still quite useful to picture a body of documentation in which every last line tells you something you needed to know about what you’re trying to build, and something you didn’t know from looking at any other line in the documentation.

What would we notice about a set of documentation that adhered to these principles? Well, first, and most obviously, it would probably be a lot shorter than the documentation we’re used to seeing. And that in itself is a benefit. Why? For a number of reasons. First, shorter documentation is in general easier to digest, and it’s generally easier to find the relevant bit of documentation in a shorter corpus, all else being equal. (And of course, document structure and readability play just as big a role in a short document as they do in a longer one.)

Shorter documents are also easier to revise and maintain. And it’s easier to find changes between versions, all else being equal. I talk sometimes about the 500 page PRD we got when we were developing one product, complete with two sets of revisions, also 500 pages each. Guess how easy it was for the developer to find the 2% of information that changed in each revision, and understand its implications to for the site? Guess how easy it was for the designer to be sure she’d changed everything consistently? In a DRY design doc, changes are more obvious, and more meaningful. Things jump out when they’re inconsistent. And they tend to be more consistent, because the designs implied are applied more consistently across the product in question.

This brings me to another favorite topic: Principled design. DRY documentation is a lot easier to develop (and it’s a lot easier to tell when your documentation is DRY) when your design is motivated by specific principles. For instance, when you decide, in the banking app you’re designing, that all checking account features will use Cerulean Blue for their accent color, and all savings account features will use Prussian Blue, a lot of nice things happen. First, design questions become much easier to answer. The new Maximizer Account we’ve just added is a kind of savings account. Great! We know it’s going to be Prussian Blue. (Or we can make a better informed decision that there should be a new point in the color family.) Second, it suddenly becomes a lot easier to document this fact. A one page style bible can capture this information, and when some new feature is implemented, it doesn’t take any intervention from the VxD to make sure the new bits have the right color choices. Third, when some new feature comes along, developers roughing it out can come up with a reasonable early approximation of what it should look like, because they have principles to apply, instead of PSDs to pore over, looking for a non-existent visual treatment for the new thing they’re just embarking on. This lets said VxD (and the IA) spend time tuning something that’s close, rather than restating the design principles they’ve got in their heads, in the form of some new PSD file.

A fourth virtue is that suddenly all these color choices (or typography choices, or IxD choices,) have consistency, a consistency that our dear End User can actually pick up on. They don’t end up feeling lost in a jumble of pretty colors, but start to associate the Prussian Blue with savings accounts, the Cerulean Blue with checking accounts, and, assuming the designer goes in this direction, that blue in general means cash accounts; green, stock and security accounts; reds and oranges, loans and credit accounts, or similar.

They may not be able to articulate why they know this, but they will perceive a solidity and purpose in the VxD, one that makes them feel safe and comfortable, and one that helps them use the application more effectively.

When coupled with a good domain model and a good information architecture, it suddenly gets a lot easier for the whole team to keep the design princples top of mind, and answer basic questions without having to consult a 500 page document, or even a 20-30 page set of wireframes and interaction designs. Hopefully they can answer most questions from a one or two page style bible, and by consulting the wireframe describing their grid system, and the one for the kind of module they’re working on.

Again, the point is not to pursue this ideal to an absurdist end, but rather to continually ask oneself: Could this documentation be simpler? Did I cover this already? Could an existing design concept apply to the new area I’m covering? Restatement in the service of clarity is always to be lauded. Unfortunately, in practice, most restatement in the form of long design documents is just waste: Waste in that the documentation must be produced; that it must be maintained; that it must be read; that it must be understood; and waste in that it tends to obscure the princples of the design in favor of the surface of the design.

And of course, another agile principle comes into play: Refactoring. Often a second use of a given design treatment exposes new boundary cases and new pressures on the design, and the initial design needs to be modified slightly to accommodate both the new and the old use case. This is usually a simplfying force, and one not to be resisted. Let the documentation live, and reflect the deeper underlying principles of the design you’re trying to express. Applied well, this rigor will help you to simplify and clarify your designs, and expose their essence.

When practiced well, DRY documentation will set you free, give you control and clarity, and communicate your design vision efficiently and clearly. It will also free your development team to do things more or less right the first time, and give them more time to work on the bits that need more love and attention.

In most academic programs, design, engineering and business are taught in silos, and the disciplines remain separate as students move into the world of work. Steve makes a proposal for more cross-disciplinary studies and industry engagement during education and mentions Philadelphia University’s new degree program, Design, Engineering and Commerce.

Check it out and let us know what you think!

With help from Hot Studio, Cooper, LUXR, SideReel and Atomic Object, about 70 people (thank you!) gathered at Pivotal Labs for BBQ, drinks, and an open discussion about how designers, engineers and product owners can collaborate better.

Great turnout!

The fishbowl format, an unmoderated, democratic panel discussion, was new to many of the attendees. The concept is simple:

• Pick a topic or question that everybody has an opinion on.
• Put four chairs in a central position. Only three people sit down and discuss, the fourth chair remains empty.
• Make sure that the discussion happens within the panel. If someone from the audience has a question or comment, she gets up and takes the empty chair. The person on the panel who has finished her point or has stayed on the longest leaves. Repeat.
• A good way to end a fishbowl is to discreetly remove the chairs.

For the deLUX fishbowl, we asked people what Lean UX means to them. What are the benefits for you in your work? What are the challenges? Attendees shared stories from in-house, freelance and consulting contexts, providing a hook for the conversations of the night.

Tim McCoy, Will Sansbury  and Lea Refice

The audience, ready to jump in

In his short lightning talk, Hot Studio’s Chris Jones explored the concept of debt, comparing a waterfall, agile and lean approach. How do you know that this idea, concept or design will work? You need to find out as early as possible if something is worth doing: Think-Make-Check. A rapid cycle of design, code, release can be applied to design work, with early feedback, prototyping, and ‘just putting things in front of other people’. Get out of the house!

Chris Jones

Cooper’s Tim McCoy presented views on “Lean UX, Product Stewardship, and Integrated Teams.” Product Stewardship builds on the notion of a multi-skilled product owner team. The responsibilities of a product owner are demanding. To avoid a bottleneck situation, a product manager is joined by a UX strategist, who assumes the role of a product steward. While the product manager represents the business goals, the product steward focuses on users and customers. This can create tension - healthy tension, aiding prioritisation and decision-making. Tim has shared a longer post and his slides here.

Tim McCoy

Powered by excellent food and a selection of different local beers, conversations continued until late. On Sunday, a small group got together for breakfast, over which we focused on one attendee sharing his story. I witnessed the magic of peer mentoring and am now keen to set up something similar in London.

The success of deLUX made it clear that there’s certainly a demand for opportunities to discuss collaboration and balanced teams. Finding someone in the same situation as you who has advice. The realisation that one’s team has come up with interesting practices that are worth sharing. Discussing one’s approach with developers who are surprised that there are designers who are passionate advocates of ’less ego’.

Let’s create more opportunities and get together again! We’ve already started planning a similar event for SXSW Interactive. We’re looking for hosts, sponsors, and attendees, so ping us if you can help, and keep an eye on the blog for updates.

There are four things I want to know about a candidate before I make them an offer:

• Skills: do they have the skills, knowledge, and experience to do the work you need?
• Behavior: will they behave in a way that benefits the team and helps it grow?
• Culture: will they be a good fit for the company’s culture?
• Desire: do they want to be on this team at this company, doing this work?

Most teams develop a reliable way of judging an interviewee’s skills; they might be asked specific questions about tools and languages, and then sit down to solve a real-life problem with other team members. And it’s reasonably easy to gauge someone’s desire by asking straightforward questions sydney warehouse. But once you establish that the person has the skills & desire to play the role that you need, how do you determine whether they will be a good fit for behavior & culture? I’m often surprised that people haven’t heard of Behavioral Interviewing, and are mostly interviewing for technical skills, and then just hanging out with the people to see if they’re “nice” or “cool.”

As the former VP of Engineering at Critical Path, I was personally responsible for hiring the first 50 technical people, which included developers, QA, designers, and technical managers. We ended up with a stellar team, and I think part of the credit goes to how we conducted interviews. For the last 5 years, I’ve worked as an executive coach for entrepreneurs, and I often end up helping clients refine their hiring practices. (BSP: You can learn more about my executive coaching practice, or check out my blog at StartupHappiness.com)

Why is it worth it to put this much effort into interviewing? First, firing someone who doesn’t work out is a huge hassle. Having someone who is the wrong fit, or not performing well, frustrates other team members, and takes up the team’s valuable time and emotional energy. Second, a company starts with the cultural DNA of the company founders, and every new hire that’s made can either amplify those values and beliefs, or not. Why not amplify the great parts of your culture with every new hire, if at all possible?

Basic Format of a Behavioral Interview Question

A Behavioral Interview question almost always starts with “Tell me about a time when you…” The goal is to have the interviewee describe a real-life experience that shows how they have behaved in a social situation, especially one where they were had to overcome some sort of difficulty that they might be likely to encounter in your organization.

One of my favorite behavioral interviewing questions is “Tell me about a time when you had an idea that you thought was really great, but other people on your team didn’t agree, and it didn’t end up being implemented.” What I want to learn from this question is how they handle a disagreement in the workplace, and how they roll with not getting their way.

Once I have a sense of the situation, I’ll ask them “Tell me about what you did, and what results you got.” I want to know if they strategized about who to talk to tian xiao cheng, what methods they used to influence others, if they gathered data first to support their position, and how things unfolded. I’m also listening for whether they talk about others as having valid points of view, or if they disdainfully talk about how stupid or inferior everyone else was. Did they go to anyone else for help, or fly solo? Do they still have respect for the manager in charge, even though things didn’t go their way? (Hint: this tells me if they will still respect ME if I choose to disagree with them someday.)

The second thing I’ll ask is “What did you learn from this, and is there anything you would do differently today in that situation?” Here I’m looking to see if they gained any insight after the fact, and some indication that they are growing and maturing as a team member. I can tell from their answer whether they’re likely to use social experiences at work as opportunities to learn.

How to Develop Behavioral Interview Questions

The best questions are taken from scenarios that actually occur within your organization. Think for a moment about what kinds of things might frustrate your current team (if you don’t know, I’m sure they will be happy to tell you). Those are the things you want to make sure a new hire can roll with. Don’t be afraid to get really specific.

When we were creating huge-scale telco-grade email infrastructure to host millions of email accounts at CPTH, one of my questions was “Tell me about a time when you got paged in the middle of the night to help a team fix an urgent problem on a production server.” By a candidate’s answer, I could tell (a) if they had any actual experience doing this, (b) how they performed when woken in the middle of the night, (c) how they communicated with other members of the team under pressure, (d) how they troubleshoot a problem, (e) what they learned about the system, themselves, and others, and (f) if they put any safeguards in place to prevent that particular thing from happening again. That is a lot of learning from one interview question!

It’s well worth creating some standard questions like this when interviewing for a position, so that you can compare different candidate’s answers. Ideally these questions would be drawn from the job description (ex: “resolve production problems as part of on-call rotation” leads to the question above), and from the team’s own experience.  A few candidates reacted very negatively to this question, and at that point their interview was essentially over: I needed people who could survive this uncomfortable situation with flying colors, get the system back on its feet, and do it a relatively cheerful attitude.

This is where “Culture” comes in; we were developing cutting-edge systems at huge scale. Everything was new, and we were moving quickly enough that we could never do enough testing to insure that the system wouldn’t fail. We were just trying to prevent it from failing the same way twice (this sounds cavalier in retrospect, but it’s true; Web 1.0 was the wild west, and we were building the kind of infrastructure for the first time that became the basis of cloud computing today). So someone who was super-disdainful of the fact that the system wasn’t 100% tested wouldn’t survive in our culture, whereas they would probably be welcome at eTrade, who was developing high-volume stock-trading systems.

Behavioral Interviewing keeps out the Assholes

One of the things that behavioral interviewing can really help with is identifying assholes: people who are likely to appear friendly on the surface, but harbor nasty traits like arrogance, backstabbing, not sharing credit for success, always blaming others for failure, and so on. It’s often easy for those kind of people to act nice during an interview, but when you ask them to talk about multiple difficult situations in a row, it’s much harder for them to maintain the veneer of kindness, and some of their more difficult habits start showing through.

Generally no one answers behavioral questions “perfectly”. Work situations are fraught with difficulty and frustration, but what I was looking for is an orientation toward curiosity, problem-solving, kindness, teaching, and learning: those were all things that our culture valued, and that I felt made technical teams very strong. So it’s fine if someone did struggle with not getting their way, or said that they didn’t love waking up in the middle of the night, as long as in the end they were able to pitch in and make it work anyway, and extra points if they did some introspection and learned something about themselves from the experience.

One important thing that I’m guarding against is someone who is still very angry or sad about a difficult situation after the fact, or who can’t stop themselves from complaining about former colleagues during an interview. If they don’t have enough self-control to speak kindly about others during an interview, they certainly won’t speak kindly about their colleagues once you hire them. Engineering culture often has a certain amount of inherent snarkiness, but I developed the ability to tell the difference between funny-snarky and mean-snarky. Funny snarky pokes fun at a difficult situation; it diffuses tension through humor. Mean-snarky is often about a particular person, and is meant to undermine their authority or credibility.

Behavioral Reference Checks

I particularly like asking behavioral interview questions of an interviewee, and then asking the same question when I check references. Then I am more likely to have the corroboration of their boss or peers: “PersonX told me about the time when they had to fix such-and-such production problem in the middle of the night with your team. Tell me about that…”  Because I have already talked about this with the candidate, the manager often feels more free to tell it like it really was."

While I’m on the subject of reference checks, my all-time favorite reference check question of a manager is: “We’re really leaning toward hiring PersonX. As his/her new manager, I want to create the best possible working relationship. Everyone has things that they like, and things that they don’t… Can you tell me what might frustrate PersonX, so that I can avoid that?” By establishing that I am close to hiring, but looking for ways to work better with the person, I’m more likely to get an honest answer, and in fact, I can use that information to help get that relationship off to a good start. Occasionally I learn something here that is a showstopper, or at least that I want to check out with the candidate before I move forward with the hire. I ask candidates the same thing about themselves, earlier, so I can corroborate the two answers. I want a candidate with enough self-knowledge and honesty to tell me what will upset them; someone who has no real answer to this doesn’t know themselves very well.

Behavioral Interviewing for Designers

Most of my hiring experience is choosing developers; what behavioral interviewing questions would you use to find great AUX designers? I’d love to hear responses in the comments!

• They start with a story that clearly defines the problem they want to solve
• They acknowledge that great ideas can come from anyone, regardless of role
• The entire team participates in the design process, typically kicking off with a design studio [PDF]

Note that the design studio influences all three points. As a result, we’re big fans.

This year, one of the goals of the Salesforce UX team was to increase our influence at an organizational level. Like many organizations, our execs were asking how the company can be more innovative and they were looking to the UX team for help.

Rather than working in isolation and hoping that we stumble upon some brilliant idea, we decided to get everyone involved. We knew there were probably dozens of great ideas locked in people’s heads, they just needed a venue to share them.

The design studio had been such a success at the individual team level, we thought maybe we could scale it up to accommodate an organization. We would involve our entire products and technology team of several hundred people rather than the typical 6-10 participants. We also wanted to tweak the structure a bit to focus on surfacing innovative ideas that we knew were already out there.

The Setup

Running a design studio at a large scale requires a lot of prep. Here are some of the items we felt were critical to the success of the event:

• Executive sponsorship If you’re going to rally an entire organization to participate in an event, you need an executive sponsor. Our executive sponsor was highly supportive. He personally sent the event invitation and committed to attending in person. More importantly, he provided a broad executive audience to review the best ideas and consider them for funding. We felt strongly that these ideas needed a chance to become real projects.
• Branding It’s hard to build momentum without a brand. We chose the name Cloudburst which felt a little silly at first but really helped people identify the event. The brand allowed us to produce promotional material such as posters, t-shirts and the like in order to increase awareness. Plus, if we were successful, we wanted a recognizable brand that could live on for the next event.
• Scope The primary purpose of this event was to surface innovative ideas. This meant that our scope needed to be fairly broad. A typical design studio explores one or two use cases. For this event, nearly any idea was fair game as long as it aligned with our company goals.
• Rules In order to keep everyone motivated we decided to structure the event as a friendly competition. Participants were asked to form teams of no more than three to maximize collaboration. Teams would work with pen and paper only and ideas would be judged on the following criteria: Creativity, Simplicity and Fun.

The Event

In the weeks leading up to the event, we set expectations and built excitement. Participants were welcome to bring ideas that they may have already had brewing. This event would provide them the opportunity to give their idea executive exposure. If they didn’t have an idea, no problem! They could help develop someone else’s.

Here’s how the day was structured:

1. Think What problem are you solving? Who are you solving it for? How will their lives be improved as a result of delivering this product? We provided each team with personas to help guide their work. The UX team canvassed the floor, reminding teams to tell a story from the perspective of their persona and asking probing questions to help flesh out their concepts.

2. Sketch Computers were not allowed. Just minds, pens and paper. This forced the teams to communicate verbally and visually, which is exactly what we wanted. Teams spent the bulk of their time collaboratively sketching.

3. Pitch At the end of the day, teams would have only two minutes to pitch their idea using a single sketch board for illustrative purposes. These constraints forced teams to really nail down their narrative. They had to take all of their sketches and consolidate them into one rapid-fire pitch that would help them sell their ideas to peers and executives.

4. Vote After all the pitches were heard, participants dot-voted on each other’s ideas. Three finalists were chosen from the group and moved on to the next round: pitching to executives.

The Outcome

After finalists were chosen, they were given a few weeks to refine their ideas and pitch to the entire executive staff. One winning team was chosen and their idea is now planned for development.

The executive pitches were a huge hit. Execs were wowed by the ideas generated and the level of energy and enthusiasm from both participants and executives was amazing. The execs were so impressed with the outcome that they immediately asked, “how can we apply this process to other aspects of our business?” We have since conducted similar events in the Marketing organization and with our customers and we’re planning more events in 2011.

Lessons Learned

Of course, it wasn’t all rosy. Here are a few challenges we ran into:

• Logistics are a challenge with such a large group. Planning and running these sessions is a huge undertaking, so make sure you are ready to commit the time and resources to make it successful.
• Some participants were uncomfortable with the dot-voting and felt that the group lost sight of the original judging criteria. We are considering electing a panel of judges for future events as well as providing more categories for winners such as best presentation or most creative idea.
• The vast majority of ideas will not get funded. Make sure you have an outlet for the ideas that people are really passionate about. At Salesforce we have a program called PTOn which is very similar to Google’s 20% time. Employees can use this time to pursue ideas they are passionate about.
• The concept may be too popular! We were flooded with requests to host more of these events. The problem, as mentioned earlier, is that they are very resource intensive. There is also the risk of participant fatigue. We think that 2 to 3 events of this size per year, within an organization, is the maximum.

Generating Change

Josh Seiden recently posted the following tweet:

Good designers generate great ideas; great designers generate change.

The Cloudburst event wasn’t perfect but, if nothing else, it generated the seeds of change. It was far more successful than we expected. We had nearly 100 participants who created dozens of terrific ideas. We unleashed pent-up innovation that engendered passion across the organization. By applying some of our Agile UX methods at a larger scale, we provided a tangible example of how a collaborative design process can help the organization innovate and solve challenging business problems. We look forward to generating more change. :-)

First, we must be realistic about our inability to predict the future, and therefore shorten and strengthen feedback cycles. We strengthen feedback by putting working software in the hands of real people, and by test-driving the process of writing code at multiple scales. We shorten cycles by delivering smaller changes more often. We stop trying to be blindly and perfectly proactive, and instead reconceive large projects as a series of rapid, highly effective reactions.

Second, we must stop thinking about building software as an activity centered around technology (machines, tools, processes), and instead appreciate that humanity and human communication lie at the heart of software making. Software is made by people for people, and those people better communicate and work well together if they have any hope of succeeding other than by dumb luck.

I’ve gotten tremendous value out of the principles and practices I’ve learned from other members of the agile community. At the places I’ve worked (generally small teams on long-term projects), we’ve applied them to great effect on the quality, malleability and maintainability of our code, our ability to release early and often, and the quality and “at-home-ness” of my team members (making our practices suit the people we are, etc.). It also bears pointing out that profound thinking continues to come out of the agile community (it never ceases to amaze me how deep the practice of TDD is), so it’s well worth continuing to pay attention.

At least as I’ve practiced agile, however, communication with those who use the software has always been wanting. The “on-site customer” has never really fully worked for me, either because it wasn’t feasible (in a product company) or because simply asking someone what they want isn’t the best way to make software design choices. I think these issues are not uncommon. And this failure goes to the heart of what agile is: We’re failing to communicate effectively with the people who use our software, and therefore failing to get all the right feedback.

There are people out there who’ve seen this for years (Jeff Patton and I’m sure many others), but I didn’t really get the message until I attended the first Agile UX/Balanced Team retreat early this year. I learned that the agile and UX communities, largely separately and in parallel, have been developing transformative ideas that, with a little increased awareness and mutual appreciation, go so much better together than they do apart.

From this agilist’s perspective, UX helps me understand how to connect with the people who might and do use my software, and to turn what we learn into a rich shared context across my team. It has also helped me realize that because my teams have always outsourced (or worse ignored) design activities, my teams have been out of balance (“on-site designer”, anyone?). I suspect similar ahas await UXers coming to agile.

• The project was run within an agile framework (focus on the customer, continuous delivery, team sat together, lightweight documentation, team ownership of decisions, shared rituals like stand-ups, retrospectives, etc.)
• The team contained people with a mix of skills (front and back end development, user experience and information architecture, product management and marketing, graphic design, copywriting)
• The people on the team generally performed in their area of expertise/strength, but were supportive of other specialties and interested in learning new skills.
• All the projects were early stage “green fields” projects where we were simultaneously trying to discover how it would be used, how it would look and behave and how we could build it.

My background is interaction design and product management, so I brought my toolkit of methods for problem definition, user research, modeling, storytelling, sketching and prototyping into the mix. Here are a few techniques that I found successful when working with balanced teams on projects like these.

Incorporate other team members’ ideas about the user experience

When I envision products, I think from the user’s perspective. What is a particular person’s objective, and what does the product show and do as they interact with it? The other people on my team have different, equally valid, perspectives of the system we’re building, for example data relationships or information architecture.

I found the most effective way to align our understanding was to ask other people to talk about (and sketch!) what was happening in the system and think about what the user would see along the way. I’d use that as a starting point for further conversation. When talking to developers, sometimes it was easier to start with a flow diagram and then build up from there. Once we built the model together, we could have productive conversations about the user interface because we all felt joint ownership and agreed on the experience we wanted to deliver.

Build shared physical artifacts

In my prior work as an agency interaction designer, I usually started by interviewing my client (one or more project stakeholders) to understand the business objectives. Then I did ethnographic interviews/contextual inquiry with users (or potential users) to understand their needs. Based on this understanding, I’d work solo, or with other designers to create scenarios, storyboards and/or prototypes, which would be validated with the stakeholders and sometimes the users.

When working with balanced teams, spending time away from the group advanced my understanding, but didn’t help the group develop a shared understanding of the product we were building. I found the most effective documents/artifacts I produced were the simple lightweight ones that encouraged conversation and participation. For example, quickly building a crude paper prototype the group could use to walk through a scenario to understand screen flows.

Create a shared vision of the product’s look and behavior

Before a product gains critical mass and has a visible framework, or many screens, it’s hard to work together in support of a shared goal. When just using story cards and conversation, I noticed teams spending a lot of time arguing about how things would work and what they would look like. I’ve seen teams spend a lot of time in debate about what stories should get built first and what could wait. There’s also tension around how long it will take to reach a minimum viable product (MVP) that people will use, love and depend on.

My observation is that these problems come from a lack of a shared vision about the product’s behavior and appearance. Most people find it difficult to imagine something they have not seen, especially if it involves complex interactions and state changes. It’s even harder to make sure that everyone in a team is holding the same complex interaction in their heads without making it real through detailed pictures or working software. There are people (and many of them are interaction designers) with a talent for imagining and communicating complex interactions. However, balanced teams don’t need a “rockstar designer” to hold the product vision and keep the team on track.  I found my role with balanced teams was to help the group envision, critique and agree on what we were building at a higher level than user stories.

Lead with conversation, trail with documentation

We were moving fast enough on these projects that my attempts to create a user interface specification or build a clickable prototype too early made me a bottleneck in the process. I realized that I didn’t want to create a well-crafted deliverable that I had to explain to other people, I wanted to make things with the team that advanced our understanding as a group.  I had better success when I started with conversation and group sketching and then built a lightweight paper prototype. We then validated the prototype as a group, and put it on the wall for annotations and additional detail created by the team. We continued to revise and extend the model over the next few days as we start to build out the product screens.

At this point, I was ready to translate the team’s decisions into documentation. I created a clickable prototype in Balsamiq to work start thinking about some positioning/screen layout issues and help further validate the product with people outside the team while we were building it.

Use personas and scenarios as back-story, not as deliverables

In my practice before I started working with balanced teams, I would often use personas and scenarios to help me understand the problem domain and frame the context of use while working through design concepts. I’ve found personas to be a very helpful method when working with other designers because they are useful shorthand for lots of information about people we’ve met. I find scenarios, by themselves, are a good tool for working with other people who are comfortable envisioning complex interactions, but they are less useful for people who need to see pictures to “get it.”

When working with balanced teams, I still often create personas and scenarios, but I do it in a more spontaneous way, when we reach a situation where they solve a problem we’re having.  If we’re having trouble figuring out what features matter, or what goes together, or how to present something, I’ll work with the team to create provisional personas that document our understanding of users, and then work towards validating those assumptions when we get a chance to talk to or show our product to actual people. I’ll create scenarios as a part of my own process for creating interaction designs, and then use it as part of the story I tell with through a sketch, paper prototype or more polished concept. “So, let me show you how Raj uses our product to do this…”

So, that was my summer vacation. From the buzz I’m seeing on #auxretreat and #agileux, it really feels like something cool is happening. We’re mixing things up and working in new ways for happier teams and better results. I’d be interested in hearing your stories. Are you working in a balanced team? What’s working for you?

For me, more so than with any of the earlier retreats that we have held, I had that same sense of the beginnings of a movement.  Certainly, the event had its fair share of  presentations of projects, techniques and case studies. Lane Halley gave a fantastic talk about the power of replacing traditional static design documents with paper prototypes that allow users to actually experience the product.  Alan Cooper used role playing, with some skilled help from Josh Seiden, to powerfully convey the complexity and importance of how to discuss and communicate UX to executives.   Desiree Sy offered insights into how to integrate UX into an Agile project framework with the UX Planning Board.  And Jeff Patton shared insights into lessons learned about story mapping, and offered a Scooby-speak version of describing a project failure as a Ruster-Ruck, which became a mantra for the rest of the retreat.

We also got a fresh boost of energy and new thinking from several of our first-time attendees, including Jeff Gothelf, Janice Fraser (the left arm of the Adaptive Path Voltron), Marcy Swenson, and Jeremy Lightsmith.  In fact, I had to keep reminding myself that they had not been part of this journey all along.

But all those very interesting talks and activities were really just the icing on what I felt was the real substance, the true take-away from this event.  The emergent theme of the retreat, at first imperceptibly bubbling up in the form of  between-talks “hallway” conversations, were about we can transform what we are doing into something greater than ourselves.

That sense of momentum reached a pinnacle when we began not just talking and musing about the idea of turning our retreats into a full-blown conference, but actually starting to make concrete plans for turning idea into reality.  There was a palpable energy in the room, a sense of common resolve.  Thanks to Lane’s brilliant facilitation skills, we forged what I believe will be an enduring vision for such a conference.  We are still ironing out the details, and I hope we can soon make an announcement and begin to promote this event.

On a separate note, and somewhat ironically, the spark that would eventually us to organize the first AUX retreat in San Francisco, was one of the retreats in Asilomar, the 2004 “Future of IA” retreat, where Christina Wodtke made fire-and-brimstone proclamations about how IAs should stop creating wireframes.  (If you’ve met Christina, you know she has a way of getting ideas to stick in your mind.)  It forced me to begin questioning some very fundamental ideas I had about what it meant to be a user experience designer and set me off on a path of discovery, in search of a better, leaner, faster way of working.  Not surprisingly, it would not be long before I discovered Agile.  I thought I had reached my destination.  Of course, what I would quickly discover was that this was just the beginning of new journey.  But with this amazing group people that have participated in these retreats, and in future events to come, I am honored and excited to be part of it. (Sob!)