Embracing Our Differences: Balanced Teams & Collaboration in Product Development
•
0 likes•60 views
This talk describes the value of working in a collaborative, cross-functional product development team, offering tips for improved collaboration and pitfalls to avoid.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Embracing Our Differences: Balanced Teams & Collaboration in Product Development
Similar to Embracing Our Differences: Balanced Teams & Collaboration in Product Development (20)
Recently uploaded
Recently uploaded (20)
Embracing Our Differences: Balanced Teams & Collaboration in Product Development
- 1. Embracing Our Differences: Balanced Teams & Collaboration in Product Development Wes Galliher Capital One Beyond Summit 2019
- 2. ● WHAT is a “Balanced Team”? ● WHY are they effective? ● HOW should they be implemented? @wesgalliher - 2
- 3. What is a “Balanced Team”? @wesgalliher - 3
- 4. A product team that values multi- disciplinary collaboration & iterative delivery focused on customer value as a source for innovation. @wesgalliher - 4
- 5. Let’s Build a Thing! Plan QA & Test BuildDesign Release Start Finish Following a plan, long feedback loops Months or Years @wesgalliher - 5
- 7. Agile Development is a set of principles that promotes iterative delivery, flexibility, teamwork, and communication Start Iterate Iterate Iterate Iteration 1 Iteration 2 Iteration 3 @wesgalliher - 7
- 8. How can you improve flexibility, teamwork, and communication when your team looks like this... @wesgalliher - 8
- 9. Designers Product Managers Testers Oftentimes Teams are Organized by Discipline StakeholdersDevelopers Legal Compliance Marketing @wesgalliher - 9
- 10. But They’re Still Geographically Siloed Designers Product Manager Developers Support Roles Users Testers Stakeholders @wesgalliher - 10
- 11. Avoid Knowledge Silos @wesgalliher - 11
- 12. Multi-Discipline, Autonomous Teams are More Effective Product Team Designers Product Managers Developers Testers Organized by Discipline Stakeholders Legal Compliance Marketing Multi-Discipline @wesgalliher - 12
- 13. Can we build this? Successful Products DESIRABLE FEASIBLE VIABLE Product Management Development Design Will our users use this? Will this help the business? @wesgalliher - 13
- 14. What are the Benefits of a Balanced Team? @wesgalliher - 14
- 15. Benefits of Balanced Teams for the Product Product Management Understand the Business Development Understand the technology Design Understand the Users Successful Product ● Ensures it delivers user value ● Aligns with business goals ● Is built in the best way possible @wesgalliher - 15
- 16. Benefits of Balanced Teams for the Product Diversity of perspectives enables more Creativity & Innovation @wesgalliher - 16
- 17. ● Eliminate blind spots ● Shared leadership (not ownership) ● Autonomy ● Minimize time blocked ● Shared cross-domain knowledge & empowerment Benefits of Balanced Teams for the Team Product Management Understand the Business Development Understand the technology Design Understand the Users Successful Product @wesgalliher - 17
- 18. Tips for Better Collaboration & Pitfalls to Avoid @wesgalliher - 18
- 19. Don’t Fall For the Hand-offs Trap @wesgalliher - 19
- 20. Hand-offs = Efficiency in Disguise “Hand-offs feel efficient, which is why we are attracted to them. We assume they’ll go well. But far too often, they don’t. So skip the hand-offs and work together.” - Teresa Torres @wesgalliher - 20
- 21. How do you get anything done if everybody is collaborating together on everything? How are roles and responsibilities defined? Who is in charge of what? @wesgalliher - 21
- 22. Activity Type Determines Level of Collaboration Product Management Development Design ● Strategy & planning ● Ideation ● Sharing vision & context ● Execution ● Function-specific discussions Design + Development + Product Management @wesgalliher - 22
- 23. How Do We Make Decisions As a Team? Do We Have to Reach Consensus on Everything? @wesgalliher - 23
- 24. Collaboration is NOT... ● Consensus Decision-Making ● Advocating For Your Own Opinion Good Collaboration IS... ● Decisions To Be Made Driving Who Needs to Collaborate ● Exploring All Individual Perspectives ● Coming Together as Human Problem Solvers ● Co-Creating a Shared Understanding @wesgalliher - 24
- 25. Let’s Embrace Our Unique Differences & Build Products Together More Effectively! @wesgalliher - 25
- 26. Thank You! Wes Galliher Manager, Product Management Pivotal Labs Twitter: @wesgalliher LinkedIn: /wesgalliher
Editor's Notes
- Let’s take a step back and review the decision making process of software development and what the so called improvements of agile are. Before the agile revolution, Someone would says “we need to Build this thing!” Gather Requirements on thing building. Debate and modify thing building requirements: this thing needs to do these these things
- Agile tried to fix this lose of ownership and accountability by creating shorter feedback loops and shorter iterative cycles. Agile is a set of principles that promotes iterative delivery, flexibility, teamwork, and communication. By Remove the silos, the feedback loops get shorter, Shorten the iteration cycles, you get to production sooner. Focus in an agile team becomes the delivery of the working software and not the delivery of the artifact
- Agile tried to fix this lose of ownership and accountability by creating shorter feedback loops and shorter iterative cycles. Agile is a set of principles that promotes iterative delivery, flexibility, teamwork, and communication. By Remove the silos, the feedback loops get shorter, Shorten the iteration cycles, you get to production sooner. Focus in an agile team becomes the delivery of the working software and not the delivery of the artifact
- Then key members of a team are assembled to become a product team yet they are still geographically sioled
- So now you have an agile team in place ready to iterate on build/measure/learn but the team is still Physical and geographical organized by discipline. Organization still might look like this even for companies that are now seeing themselves tech companies they still might look like - In this world, Product Managers and Designers sit outside the Agile development, yet PMs have the complex job of representing the product to the rest of the org, Designers are asked to be hero designers and do everything without being involved in the business need or implementations. And developers in many traditional organization sit off in separate floors or even separate buildings. Historically, this model builds up tension and creates conflict even in agile development. The struggle to represent and make decisions on product delivery becomes a part of the day to day interaction.
- In AgileWell if you look at traditional organizational structures, teams are organized by discipline. it means devs sit there designers sit there PMS sit there stakeholders are together etc and so on A multi discipline team say in order to produce a shared goal, we can take core disciplines and assemble them into a team that makes sense. For product develpement, it usual means developers, managers, designers, testers and stakeholders that work towards one product or shared goal. So this team becomes the product Team
- Our solution is what we call A balanced Leadership Team, coined by Janice Fraser. It is built based on the idea that if we parse out the disciplines and give the team members equal weight within their discipline, we will eliminate some of the internal conflicts within the disciplines. And by letting the 3 core discipline own their domain, we are create co-owners or leaders within that team, within that domain. and also creating an atmosphere of communication and collaboration. In addition, we are building and balancing this team on the premise that people are smart enough and respectful enough and responsible enough to help track their decisions making process [CLICK] and when they don’t have the information they need to make a decision, that they are able to the track the people who can help the team make these decisions.
- Shared Leadership - creates a sense of shared leadership when everyone is at the table for all the decisions when anyone can talk about the success of the product. And how what they are working on is related to that roadmap for success. When things go wrong, its on us. When things go right, the team shares the responsibility for the success of the product. How we work together and understand each discipline will define our success and failure. Shared leadership and not ownership. Ownership implies blame, leadership implies empowerment. It’s a mindset. It’s not about heroes, ininjas or rockstars, its about leaders. So PMs can take input from the business understand the user, understand the business and understand the technical domain, Then they have to Imagine the experience, prioritize the work, simplify the details, untangle the architecture, implement the code design, write the tests. And the have to do this all in a rapidly changing environment. Designers will lead the user need. Development leads implementation and the PM leads the business viability. Design and Development are vertical functions that are aout craft and craftsmanship and commitment to understanding the technical details The PM is a horizontal function, the PM has to understand the breadth of these competing needs interests that go into making these complex decisions.