Team Ownership through the UX Design Studio Approach

A few weeks ago I was added to a new team that had already spent some time working on the technical challenges for the project but had yet to do much UX work. One of the first things the team asked me to help with was to create the User Interface design. I think what they expected was for me to ask some probing questions, go draw some pretty pictures in Visio or some other tool and then present (and dictate) the results. I've certainly taken this approach on previous projects. However, in this case I went to my agile improvement backlog and decided to try the Design Studio approach I had learned at Agile 2010 in a session by Todd Zaki Warfel.

The Design Studio approach is a team approach to UX design. When I first asked the team if they would consider doing the UX design as a team, they were surprised and delighted to be asked (cool!). I had high hopes for this approach because I was excited to see the results of using the collective imagination of the team to create a cohesive and well thought out design. Before I share the results, here are the details of this technique:

Prerequisites: You should have already created your initial backlog of user stories. Creating other artifacts like personas and user scenarios first would also be useful. In our case we had the stories and some scenarios, but no personas yet. You will also need to print out several 8up sheets like the one in the image below and bring along several pencils. You can download the 8Up here or create your own in Excel. 

Steps:

1. Gather team members for the exercise. Not everyone needs to participate, but you should have willing participants from each role including developers and client.
2. Decide on a focus for your UX design. This could be a specific release, user scenario, or some grouping of user stories.
3. Hand out 8up papers and pencils to everyone on the team.
4. Ask everyone to create 6-8 sketches of the different pages/screens in the app (see tips below).
5. Once you start, tell them they only have 5 minutes to complete their 6-8 sketches.
   • You could tell them this before, but it seems to help crystalize their thoughts when they hear this.
6. After 5 minutes, review each set of drawings:
   • Each person has 3 minutes to pitch their drawings to the team.
   • The team then has 2 minutes to identify 3 things that worked and 2 things to change.
7. Repeat steps 3-6 until the team reaches a consensus on the design.
8. Once your design is complete, keep the final sheets as your UI reference model.
   • You won't likely need to transfer this to Visio or any other tool. The model should contain enough information and brief notes so that you can develop straight from the paper and make final adjustments in your development tool while having a conversation.

Some tips:

• Gloss over details in your drawings. You need just enough detail to communicate your design.
• Aim for quantity not quality.
• When doing this for the first time, don't tell your team they only have five minutes until after they start.
• Do steal ideas from each other.
• As always, include your client in these sessions.

Results

Four of us met in a conference room to try out this new approach. For a user scenario that included about 10 stories, we executed three rounds. As a team, we were very pleased with the results and how quickly the final design emerged. Despite starting with very different ideas, we discovered that by the third round our drawings were nearly identical and represented the best work of the team. Using this approach helped generate ideas none of us would have thought of individually and resulted in team ownership of the design. We also found that we identified a few new 'excitement' user stories to add to and enhance our existing backlog. Additionally, as we walked through each other's drawings we discovered one or two basic stories that we had missed while generating our initial backlog. Time will tell if the resulting UX design will be successful, but as a whole the team is confident in both the approach and the result.

In summary, this approach was fast, promoted team ownership, and produced a great result. You can learn more about the Design Studio approach here: http://unify.eightshapes.com/page-pattern/sketching-design-studio-page-patterns/

I thought the success of this team approach was appropriate to write about on a day where this quote was found in @ThisIsSethsBlog - "I'm not going to believe that only a few people are permitted to be gatekeepers or creators or generous leaders". Indeed.

Update April 1, 2011: I introduced this approach to a larger group of my fellow employees this week. Someone asked "why we should continue with round 2, 3 etc - why not just have the group consolidate the good ideas and produce one design together after round 1?" 

My answer: If you consolidate your ideas after round one then you are risking two things: 1) That the 'loud' voices will be the one driving the ideas and design. The practice of having everyone re-drawing the design allows each person's ideas to be incorporated. 2) As you repeat the process of re-drawing your design, the ideas from your team members will seep into your ideas and birth new ones. If you consolidate your design too early, you risk losing those new ideas that can only form in the act of putting your ideas down with paper and pencil.

Agile Winnipeg Inaugural Event - "Shorten the Distance"

It was pretty exciting for myself and the other organizers to see a packed room of over 60 people attend the first Winnipeg Agile User Group event on Thursday, March 10, 2011. After a quick meal from Homers and some furniture re-organization, we kicked off the event with a word from several of our sponsors. Wadood Ibrahim spoke on behalf of Protegra and recalled giving a presentation to the local PMI group 10 years ago about agile techniques that was not well received and was delighted by the turnaround of opinions and interest 10 years later.

For the main presentation, Doug Kok and I split the attendees into groups of about 15 people and led them through the ball point game. The ball point game is a simple and fun exercise that allows teams to think about process * people through team decision making and the power of reducing hand-offs. Here are a few images from the event:

Team 1 Discussing their strategy



The scores of the game. Notice the significant improvements from most teams. Team 3 forgot to count during the last iteration, but based upon the process they were using, I think they would have surpassed their estimate of 160



And, thanks to Doug - here is a brief video summary of the teams playing the game: 


So how does the ball point game relate to agile? In both the ball point game and in software development, improvements in speed can be gained in similar ways:

• Focus on reducing hand-offs by having face-to-face conversations, dedicated teams, shortening the distance between a requirement and its implementation, a question and its answer, etc.
• Stop frequently to determine how to go faster.
• Measure your experiments through velocity and frequent feedback.
• Value and encourage cross-functional, de-centralized, self-organizing teams.

Homework: To take this further, read the 12 principles in the Agile Manifesto and think about how each of the 12 could be re-stated as a way to reduce handoffs, or as shortening the distance between [A] and [B]. Also, to see how these ideas can work in the 'wild', read this case study on facebook.

To close the event, we held a short open Q&A session. Some of the questions we discussed were:
 1. Can you do agile without TDD (Test Driven Development)
 2. When/how do you do requirements?
 3. How do you control scope creep when you aren't defining the requirements up front?
Lively discussion continued over drinks at Triple Bs on Scurfield.

Based on the survey responses, the top 3 categories for future event topics were Agile Testing, Agile Adoption, and Agile Estimating.

Finally, on behalf of the organizers I would like to thank you for participating and thank the sponsors for allowing this event to occur. To register for future event notification, please click here.

What I learned about agile teams from 8/9 year old girls basketball

I am a very fortunate daddy. I am one of the coaches for my eldest daughter's basketball team. The community league she plays in has a rule designed to promote team work that at first glance may seem counter intuitive - "No double teaming". This means that in most circumstances when playing defense each girl must cover her own 'check' and can not help out her teammate. To explain this a little more, I'll give you two examples.

Example 1 - double teaming:

Mary is new to basketball and is tentatively dribbling the ball over half court. Ann is playing defense on Mary and is doing a pretty good job of limiting where Mary can go and who she can pass to. Laura is a very strong player on Ann's team and notices that Mary is struggling and that she has an opportunity to make a play. Laura leaves her own check, runs over to Mary (who is now double teamed), steals the ball and races to her own basket where she scores an easy two points. Her team cheers loudly.

Example 2 - helping:

Amber is an experienced basketball player and is dribbling the ball over half court. Kari is playing defense on Amber but is having trouble limiting where Amber can go and who she can pass to. Deanna is a very strong player on Kari's team, but because she is not allowed to double team, she does not immediately race over to help Kari. Amber makes a quick move that allows her to get past Kari and race towards the basket. At this point, Kari knows she is in trouble and yells 'help'. Deanna races over and gets in front of Amber to slow her down just enough so that Kari can catch up. Once Kari has caught up, Deanna races back to her own check and Kari resumes playing defense on Amber. No baskets are scored and mild applause is heard.

The nature of community led basketball leagues is that there is a combination of inexperienced but willing coaches and inexperienced but willing referees. This means that most times example 1 occurs without the ref or the coach interfering. While our team has been mostly executing as example 2, many of the teams we play against have been executing mostly as example 1.

Over the course of the season, the result has been interesting. Teams that were beating us at the beginning of the season by taking full advantage of the skills of their best player through double teaming are now struggling to even have a chance to score against our girls. The girls on those teams are trying just as hard, but the double teaming strategy that worked so well early in the season is no longer effective.

We have a team of 10 girls who have each improved. Some of the girls are more skilled than others, but each girl has improved noticably from the beginning of the season. The net effect is that our team has also improved noticably from the beginning of the season. Maybe more importantly, this team supports each other, learns from each other, and trusts each other.

Note: It would be easy to credit our brilliant coaching strategy, but that would clearly discount the effort, teamwork, and skill of the girls on our team. They are a wonderful group.

The parallels for agile teams are pretty clear to me. If you expect your team to perform at a high level, you need to let them improve at every role and reinforce team ownership of the project.

• If you are the PM, don't take sole responsibility of the budget, tasks, project goals etc. Make these visible to your team and help your team own them and make decisions about tasks and priorities together.
• If you are the DBA, don't get upset when the database design is insufficient, teach the team how to improve their design the first time. Work with them rather than 'fixing' their work later.
• If you are a tester, don't assume full responsibility for testing, teach your team how to be better testers by testing every day and pair testing with the developers.
• If you are the UI expert, involve your team when designing the UI. Lead the exercise, but don't steal the design for yourself.

Of course, the converse of all of these is also true:

• If you are a developer, take responsibility for the budget and priorities
• If you are a tester, learn how to code a little
• etc.

There are other lessons to be learned from 8/9 year old girls basketball, like how to ask for help when you need it, but those are for another day.

Occasionally I meet former co-workers who inevitably ask me what I'm doing. When I announce my agile and lean passions and talk even briefly about the differences between traditional teams and agile teams, I often am greeted with a response something like "But someone still has to manage the team and the budget right?" My answer is usually "Yes, but it doesn't need to be you anymore. It should be the whole team."

As the African proverb says, "If you want to go fast, go alone. If you want to go far, go together."