Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Intro to Balanced Teams
Similar to Intro to Balanced Teams (20)
Recently uploaded
Recently uploaded (17)
Intro to Balanced Teams
- 1. Balanced Teams Introduction - Yesterday and Today Jeana Alayaay August 2016
- 4. What’s this all about?
- 5. Today’s Assumptions You want to deliver value to users, today. You believe an iterative approach is better than its alternatives. Working as a team is not always easy or smooth. You’re familiar with the Agile Manifesto and Lean Startup concepts.
- 6. 😣😖😫😩😱 “Ahhhhhhhhhhhhhhh! This hurts and I’m afraid! “ -Everyone
- 7. What is often true
- 8. And this… The Heroism Model “A unicorn is someone who can take on and perform the tasks of a UX Designer/Architect, Visual Designer and Developer (typically front-end).” UNICORN/GURU DESIGNER ROCKSTAR DEVELOPER “Makes complex problems disappear” “Mini-CEO” ROCKSTAR PRODUCT MANAGER
- 9. “Balanced Team is a group of people who are interested in furthering processes and methodologies to create great things. We welcome people who wear many hats (design, development, testing, product management, marketing and sales) and we value multi-disciplinary collaboration and iterative delivery focused on customer value as a source for innovation.” What is Balanced Team?
- 10. A Brief History
- 11. A foundation for building on
- 13. The ‘user-experience’ is end to end, it includes all parts of the experience, not just software UI A proposal:
- 15. Why is 3 the number? n(n-1)/2
- 17. Product teams at work
- 18. Balanced Team Patterns Empathy Trust through suspension of disbelief Mutual respect of each other’s crafts One Product Team “5 whys” as the basis for process
- 20. Design,“Empathizer-in-Chief” Obligation to the Team: 1. Understand the customer at an expert level. 2. Translate high-value needs into product. 3. Hone your craft. 4. Facilitate balance within the team. One Important Responsibility: Prioritize customer problems.
- 21. Development, “Raise high the roofbeams” Obligation to the Team: 1. Envision the best solutions based on available technology. 2. Commit to the customer outcome. 3. Hone your craft. 4. Facilitate balance within the team. One Important Responsibility: Make sure the technology serves the problem-solution set.
- 22. Product Management, “The scales of justice” Obligation to the Team: 1. Make fast concrete decisions despite inadequate evidence and conflicting priorities. 2. Identify the business value in customer needs. 3. Hone your craft. 4. Act in service to the team. One Important Responsibility: Shepherding decisions.
- 23. “Courage to speak truths pleasant or unpleasant fosters communication and trust.” “Courage to discard failing solutions and seek new ones encourages simplicity.” “Courage to seek real concrete answers creates feedback.” Leveling-up Kent Beck Style
- 24. The takeaway -- “Beyond talk of design or agile, beyond talk of design and agile, the talk was of what the organization can be—and must be—when everyone in it is committed to the principles of user- centered, collaborative, iterative teamwork.” - Alan Cooper
- 25. Tweet at me! @jmalayaay, @pivotallabs Work better with less stress and more awesomesoness!
Editor's Notes
- This is not the key to better/faster deliverables (though that might be a byproduct). This is part of a greater discourse about if and how people processes should evolve to meet market demands. For folks at Pivotal Labs - This might help you help your clients understand why they’ve struggled in the past and what they can do to improve their future efforts.
- This is what your team looks like when it’s heading down the waterfall… Let’s talk about Balanced Team ANTI-PATTERNS for a second
- Another familiar model….ANTIPATTERNS
- Balanced Team grew from the contributions of many people over time. Here is a brief review of some key events and activities that led us to where we are now. August 2009 “Agile Evolution” - spent a lot of time talking about how to blend agile and UX. Lane and Anders wanted to see the two communities communicate better, and include other disciplines as well. They decided the best way to advance this mission was to bring together like-minded people in a retreat format and see what happened. The first Agile UX retreat was a two day event at Cooper - Key insight: No more “Us and Them” thinking worked on “Humanifesto,” and Problem statement(s) July 2010 “Agile UX Retreat” in Grand Rapids, MI - Brainstormed new names, “Balance” was chose December 2010 “Agile UX Retreat” in New York, NY “Lean UX” concept brought to group by Janice Fraser, LUXr
- Role specific
- Not first to market, but best in market Growing access to technology has changed consumers expectations about ‘product experiences’ Consumers have a lot of options. Multi-part products and services (phone, body, web, in-store) Multi-platform (web, mobile, tablet, wearables) Complex value chains (e.g. a just-in-time clothing manufacturer based on facebook likes)
- Amazon PrimeAir Athena by ROAR http://www.roarforgood.com/ Google Self-Driving Car Project Software is part of a larger experience
- Decision-specific participants Data science, manufacturing, different types of engineer, different types of designers, etc.
- The Handshake
- Prioritize the work Imagine the experience Foster improvement Execute the plans Understand the people Reconcile the details Untangle the architecture Disambiguate everything
- We talk a lot about having empathy for our users. This is important. The best way to build this into the process is by being empathetic toward your teammates. Remind yourself - Their job is hard. They’ll have bad days. They’ll make mistakes. They ARE trying their best. “I believe that right now you’re making the best decision you can make with the information that’s available to you.” Sometimes, you won’t understand or agree with their decisions. That’s OK - They can’t know all the things. And neither can you. Think about how this might change your verbiage - Avoiding voicing opinions as statements of fact. “ I believe..., I feel..., I can imagine....” are often better for starting conversations, especially when you think you might disagree This is not just someone’s hobby. Your colleague has devoted their career to honing a particular craft. It’s not as simple as they may make it look - This is often a problem with how other roles view designers’ work. Because most human beings are empathetic...unless their sociopaths...because they have feelings about what looks good, design feels more accessible than code or the work of PMs. Remind yourself that that interface is just an output. All the work that happens before it’s manifested is hard and designers spend many years getting good at it. Also, instead of focusing on what makes your crafts different, think on what makes your crafts similar. Your work is probably interesting to your teammates. Try finding common language with them. The PRODUCT TEAM does not just refer to the PM and designers. Everyone devoted to delivering value to the user is part of the product team. Get excited, stay interested! Your teammates are doing cool shit. Root Cause Analysis - A tool straight from the Agile handbook - Try not to jump to conclusions about what the ‘problem’ is. Ask yourself 5 whys.
- Leadership You’re a facilitator, You’re not a dictator, nor are you a hero or martyr. You’re pragmatic, not dogmatic. You have philosophical conversations about why we are here and why we’re doing the things we’re doing Don’t strive for consensus or democracy. Decisions are made for the purpose of moving the team forward. Facilitation Don’t go into a corner and come back with decisions. Get the right minds into a room, extract the best available knowledge, and help the team imagine all of the possibilities and solutions. Sometimes someone has to make a call, This is a call made in service to the team, so the team can move forward with confidence Process Facilitate processes that serve your team’s goals and engender trust. Processes should change as your goals change. The team does not serve the process, the process serves them.
- The foundation => Kent Beck, the father of Xpreme Programming, believes that the ability to build great software is not a function of the process, but a team’s values and mentality.