Blog-Posts

We we asked the registered participants of the Balanced Team Conference to propose topics for the event. These are some of the proposals that attracted the most interest from the community. The list below contains a rich and interesting mix of facilitated conversations, stories, best practices and hands-on techniques from some of the leading practitioners in this space. To see the full event schedule, please check here. Opening Panel: Balanced Team Perspective s - Jeff Patton (AgileProductDesign), Janice Fraser (LUXr), Gregory Jones (TheLadders) ...

We’re pleased to announce the first Balanced Team Conference. This event builds on our previous Agile UX retreat events, and represents the continuing growth and energy surrounding the balanced team thinking and movement, of cross-disciplinary whole-team work for healthy and successful teams. 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. ...

Here are some books recommended by members of the Balanced Team Group. They cross a variety of disciplines and methodologies. Think something should be added? Let us know in the comments! 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 ...

(Reprinted from Ian’s blog at Pivotal Labs.) 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. ...

I’ve enjoyed reading Steve Blank’s blog, and think the recent article " College and Business Will Never Be the Same" nicely articulates one of the reasons it’s so hard to bring different disciplines together to focus on collaborative solutions. Working in silos is baked in from the start. 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. ...

I wanted to share my presentation from the deLUX event a few weeks ago in Boulder. In the time that has past since the event I’ve update the presentation the help illustrate the term spoilage. It’s a term I’m introducing, and it’s intended to be provocative. The lost opportunity from design debt is a real tragedy. I’m hopeful that what we talk about in the group can help designers avoid having their efforts wasted working on the wrong priorities. ...

At the end of the December retreat in NYC, the Balanced Team group felt that it was time to reach out and share our thinking with a wider community. Last week’s Interaction 11 conference in Boulder, CO, provided an ideal opportunity to throw a party with activities and talks sprinkled on top. 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. ...

One of the best ways I’ve found to create high-functioning teams is to interview well. (The other is to create a company & culture that great people voraciously want to join, so that when you find someone terrific, they say “yes.”) 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.” ...

Salesforce.com has been practicing Agile for several years now and we’ve had a lot of success making user experience a critical part our process. When we take a step back and look at the teams that are most successful, from a design perspective, there are a few attributes that stand out: 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. ...

“if you want to succeed, double your failure rate.” (Thomas Watson, IBM Founder)