Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Maximising teamwork in delivering software products
Similar to Maximising teamwork in delivering software products (20)
More from Ryan Dawson
More from Ryan Dawson (13)
Recently uploaded
Recently uploaded (20)
Maximising teamwork in delivering software products
- 1. Maximising Teamwork in Delivering Software Products
- 2. Ryan Dawson Seldon ML Tooling Developer 12 years working in the Development scene in London Laura Edwards Hotels.com Product Manager 10 years working in Financial Services and e- commerce
- 3. Not finance. Not strategy. Not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so powerful and so rare. Patrick Lencioni The Five Dysfunctions of a Team
- 4. 1. What is Teamwork? 2. The 5 Dysfunctions of a Team 3. Agile and Teamwork 4. How can Product Managers bring most to the team? 5. How can Developers bring most to the team? 6. How can Scrum Masters bring most to the team? 7. Being a High Performance Team
- 6. Taskwork ● Taskwork is what a team is doing ● Team’s individual interactions with tasks, tools, machines and systems ● Task execution tends to be individual but may not be so Schmutz JB, Meier LL, Manser T, BMJ Open 2019
- 7. Teamwork ● Teamwork is a process of interaction among team members who combine collective resources to resolve task demands. ● The sum of taskwork and teamwork is team performance i.e. what the team actually does. Schmutz JB, Meier LL, Manser T, BMJ Open 2019
- 8. Teamwork in Action ● Roles working together to common goal. Individuals shifting roles. ● Could be more autonomous and self-directed!
- 9. 2. The 5 Dysfunctions of a Team
- 10. Great teams do not hold back with one another. They are unafraid to air their dirty laundry. They admit their mistakes, their weaknesses, and their concerns without fear of reprisal. Patrick Lencioni
- 11. Patrick Lencioni
- 12. Trust is knowing that when a team member does push you, they're doing it because they care about the team. Patrick Lencioni
- 13. Making a Safe Space for Feedback ● Criticise actions, not people ● Do call out behaviours ● Time and phrase it carefully ● Situation, Behaviour, Impact
- 14. Goal-setting ● If everything is important, then nothing is ● Make trade-offs ● Goals should be observable and near-term
- 15. Tackling the Dysfunctions ● Culture of openness ● Collective decisions ● Disagree and commit ● Challenge one another to reach goals
- 17. Agile Alone is Not Enough ● Sprints = clear goal-setting ● Small iterations = progress towards goals ● Events = voice issues and encourage buy-in Simply following agile practices in itself does not guarantee good teamwork. Visual Paradigm CHAOS
- 18. Collaboration Matters ● Easy to overcomplicate designs. ● Can burn enormous time. ● Need to start simple and iterate. ● What does simple even mean?
- 19. The most successful development occurs when developers talk directly to customers or are part of business teams. The biggest cause of failure in software- intensive systems is not technical failure; it’s building the wrong thing. — Mary Poppendieck, Leading Lean Software Development
- 20. Specialization allows us to handle ever-growing complexity, but the benefits of specialization can only be fully realized if the silos that it creates can be connected effectively. — Mik Kersten, Project to Product
- 21. Roles & Responsibilities Not a Scrum Alliance diagram!
- 23. The Product Vision is the Team’s Problem ● The Product Vision is for the whole team ● Everyone should be trying to see, shape & deliver it ● The product manager is the guide
- 24. ● Development team should not be a feature factory ● Get the team to feel the customer’s perspective ● Listen and incorporate The Customer’s Problems are the Team’s Problems
- 25. Assumptions are the The Team’s Problems ● Beware the unwritten assumptions! ● Use examples & scenarios ● “Open door” policy for questions between product & tech teams To assume makes an ass out of u and me!
- 26. Tech Problems are the Team’s Problems ● Product: Understand what tech is for ● Developers: Explain & advocate tech debt
- 27. It’s about Balance and Trust ● Vision is good. Deliverable vision is better ● If developers don’t see value, then they only see the cost ● Not signing the team up without agreement ● Backlog is shared ● Don’t mistake features for user benefits
- 28. 4. Developers
- 29. Success is not delivering a feature; success is learning how to solve the customer’s problem — Eric Ries, The Lean Startup
- 30. Feel the Customer’s Perspective ● Ask why ● Raise problems. But not excessively ● Demo
- 31. Perfect is the Enemy of Done Most common bias: over-attention to software internals to the exclusion of software purpose.
- 32. It always takes longer than you expect, even if you take Hofstadter's Law into account. Douglas Hofstadter
- 33. Estimation and Trust Estimation is hard because the work is creative and complex. Accept that. Explain it. Hero behaviour and defensive behaviour undermine team unity.
- 34. Empowerment ● Seeing big picture ● How to get the team to its goals ● Feeling safe raising concerns ● Taking criticism constructively
- 35. 6. Scrum Masters
- 36. Conflicted Loyalties ● Scrum Master often accountable for delivery in the eyes of stakeholders ● Want to be spotting problems and facilitating resolutions ● Promote the scrum team’s role in the organisation
- 37. Individuals and interactions over processes and tools
- 38. Teamwork and Trust ● Defensive behaviour undermines trust ● Being too strict with process can be defensive behaviour ● Have to make commitments to stakeholders ● Overcommit and you undermine scrum team trust
- 39. 7. Being a High Performance Team
- 40. Team is Not an Island ● Great teams need to be adaptive ● Outside politics can divide a team ● Get into open, face together ● Protect trust within team
- 41. Teamwork Red Flags ● Everyone sticks rigidly to their roles. ● Timelines and goals set from above, not agreed (or explained) ● Posturing and empire building ● Nobody voices ideas/concerns beyond their rigidly-defined role
- 42. Teamwork Nirvana ● Everyone contributes to discussions ● Team adapts to and drives change ● Mistakes called out, not individuals ● ‘We’ used more than ‘I’ ● Successes collectively appreciated
- 43. The Challenge of Teamwork Good Problematic Teamwork Trust. Openness. Challenge each other. Defensive/political. Empty/vague agreements. Agile Customer problems. Self- organising. Adaptive. Feature factories. Regimented.
- 44. Conclusions ● Success requires committing to a vision. People can’t buy in without empowerment and teamwork. ● Foundation of teamwork is trust. ● Specialisation is good but also creates barriers that we hide behind. ● We have to be comfortable challenging each other in order to overcome barriers.
- 45. Thanks for listening. Questions? Like so many other aspects of life, teamwork comes down to mastering a set of behaviors that are at once theoretically uncomplicated, but extremely difficult to put into practice day after day. Patrick Lencioni
Editor's Notes
- Thanks for having us and thanks everyone for coming. We’re going to talk about Maximising Teamwork in Delivering Software Products. Should take about 30 mins and then we’ll take questions.
- You may be wondering why we’re self isolating together, we’re married & live together.
- R READ QUOTE. 5 Dysfunctions is a classic on teamwork. It really gets into how important teamwork is and what’s so hard about it. It’s an inspiration for this talk and we’re going to cover some of its insights. Then we’ll apply to software teams.
- L
- R
- L - To understand teamwork, we first need to distinguish teamwork from taskwork.
- L Team work in contrast is…(read first bullet point) Taskwork can be an important part of teamwork, but it doesn’t make the whole - (read 2nd bullet point)
- R. So teamwork is individuals working together to common goal. Individuals may have different roles. In more sophisticated teamwork they might also shift roles. In the game Lemmings the individual lemmings work together as a team. Their goal is get out the door to exit the level. Individuals get allocated roles. They can also shift roles. Could be more sophisticated if individuals were more autonomous. But they are lemmings. This is a simple example after all. Sports teams provide classic examples of teamwork as there you have a clear common goal and individuals playing their roles to reach that goal. Sometimes shifting roles and sometimes with more or less autonomy.
- R. So let’s learn more about teamwork within a business context from Lencioni’s Five Dysfunctions of a Team. For teams in office work some of the key aspects of the work relate to exchange of ideas and agreeing a course of action. It’s a more conceptual environment than, say, a sports team, for which the objectives are more physical.
- R. Patrick Lencioni makes a key observation about top teams. Top teams in business have a culture of openness and challenge each other. READ QUOTE.
- L. So what does Patrick Lencioni say are the 5 dysfunctions of a team? You can see them here on the slide, on the left we have the anti-patterns, Lencioni’s dysfunctions, and on the right we have the positive behaviours that high performing teams display. You will notice that they are laid out in a pyramid, and the dysfunctions are indeed hierarchical. The foundation is Trust. There’s little hope in tackling the other 4 dysfunctions if the team doesn’t trust each other. Once trust is established, we can build into other areas It’s important that trust is not seen to be synonymous with agreement, and that’s where the next dysfunction, Fear of Conflict comes in Diversity in thought and opinion helps high performing teams make the best decisions. Conflict can feel uncomfortable, but debate helps to make sure that everybody is heard. Debate allows teams to “disagree and commit” . It’s important for concerns to be aired in order to the team to buy into a goal or direction. Healthy debate then, leads to Commitment. So the whole team agrees on the goals and are determined to achieve them. Commitment and healthy debate together combine into Accountability When the team are keeping themselves accountable for reaching their goals, they are much more likely to identify risks and issues early on and work together to mitigate them And finally, once all four of trust, healthy conflict, commitment and accountability are in place, we will almost naturally come to driving off Results and a focus on meaningful outcomes.
- R. READ QUOTE. It can be hard to criticise peers or even seniors constructively. It’s subtle. Constructive criticism does not have to mean understated. It’s about finding a balance of being direct and honest without being personal.
- L. https://www.bustle.com/articles/165434-9-ways-to-give-constructive-criticism-that-are-actually-helpful Continuing to look at the dysfunctions around lack of trust & avoidance of conflict, how can we make a safe space for feedback? The most important thing is to concentrate on actions & behaviours and not the people themselves Allow people time to digest feedback - not everyone can fully understand and react positively to feedback when they hear it. Some people can be defensive, but that doesn’t mean you should stop trying to give feedback Make sure that timing is appropriate - calling a behaviour out in front of a room full of execs is unlikely to promote trust. But do try to give feedback as soon as possible after the event has happened. Lastly, you can use the Situation, Behaviour, Impact model to help frame your feedback. For example: “In that last presentation (situation) , you spoke very quickly (behaviour) and it made some of your points difficult to understand (impact)”
- L. Now having spent some time on trust and conflict, we’d like to mention goal setting. Team needs to form and buy into a goals together Shaping goals should be hard - if everything is important, then nothing is It should be hard. Make trade offs If you could only achieve one thing, what would it be? Make sure you have the right metrics to measure progress against your goals Having goals makes it easier to articulate trade-offs, and to say no!
- R. Bullet points make it sound easy. It’s not. Particularly as that foundation in trust can take time to build and can get shaken. Team has to recognise the right culture and police itself for it.
- R. Let’s apply Lencioni’s ideas to agile software development.
- L. Data shows that Agile practices lead to better project outcomes, but Agile doesn’t guarantee good teamwork. Agile, (and in our examples here we’re talking specifically about scrum) has frameworks that can help with good teamwork. Sprints help with goal setting & measurement towards those outcomes at the top of the pyramid. The Events such as sprint planning and especially retros allow the team space to voice issues and encourage feedback. With the right amount of trust and feedback, there is a lot of opportunity for Plan, Do, Study, Act/Adjust cycles. However, there is a danger of just going through the motions, and these events alone don’t create a top performing team.
- R. Let’s make sure we have a feeling for why collaboration and feedback matters so much with Agile. Example design, all seen something like. Imagine somebody talks to a department manager and comes up with this. Spend ages building. Then users on ground say it’s over-complicated. They don’t even all the details the page is throwing at them. Could make roles & permissions complicated and find users don’t need. Could come up with a complex way of handling addresses and then find text box is fine. Need to be Agile and get to simplest thing that can be put in front of real users and establish a good feedback loop. That crosses lots of role boundaries. Who can best say what’s the simplest thing to put in front of users first? Who will find out about the other systems involved? Who can get the feedback going with the users? Who can communicate the user needs? How will competing needs be prioritised? It’s a range of roles and some tasks that might not fall clearly under a particular role.
- R. Using Agile practices can be very powerful. Projects can even take an initial vision that’s vague or problematic and reshape it to solve business problems. Waterfall projects that started going in a bad direction would likely carry on with that path and fail. With Agile you can shift course through lots of cycles of adjustment to detailed feedback. For best results everyone should be part of that process of evolving the vision. Developers in particular can be at the end of the chain. But the developers are well-placed to see what’s easy to do and what’s hard and that lets you experiment effectively. More developer involvement also reduces the risk of misunderstandings only coming out at the implementation stage. But getting that level of collaboration requires an open and trusting team. It also requires individuals to go beyond just exercising their core skills. ---- There are surveys that suggest commitment correlates highly with success - https://pdfs.semanticscholar.org/94bf/13ac20c00008952b0792197ce84a20a6fb8b.pdf And that people on failing projects know they are failing early on - https://www.geneca.com/why-up-to-75-of-software-projects-will-fail/ Much bigger topic. Raises organisational questions not just team questions. Point is collaborative vision-setting is what we should aim for.
- L. Within Agile teams we have roles that promote specialisation. Specialisation is an enabler but can also lead to camps and “us” and “them” divisions. These divisions can undermine teamwork.
- R. Everyone knows these. One of the first things people think of about Agile, together with backlogs and standups and story points. Sometimes people forget that none of that is in Agile Manifesto. Just suggested by Scrum Guide. Self-organising means team shapes itself to meet the problems. But what can happen instead is roles become regimented and collaboration breaks down. People fixate on process and numbers and it becomes about rate of delivering features rather than delivering the right thing. Happens a lot - some agile founders have called it ‘Fake Agile’ or ‘Dark Scrum’. Have used this diagram from the internet because it shows the roles in a sharply defined way. For example, here only the Product Owner talks to Stakeholders. The Scrum Guide doesn’t say that. Probably the author was simplifying for ease of understanding. But you also find these kinds of barriers getting erected in the real world. Regimentation of Agile can happen quite easily as the teamwork required for good Agile is quite delicate. What we’ll do next is to see what biases each role falls into and what the barriers commonly look like. As a result we’ll be better placed to break down those barriers. Our aim in this presentation is not to understand the specific causes of Fake Agile or Dark Scrum. So we’re not going to talk about bad cultures or bad training or top-down organisations - that’s a whole big topic in itself. In this presentation we are going to try to explain how easy it is for people to get pigeonholed into narrower interpretations of their roles. People can even be inclined to pigeonhole themselves because we fall into biases through specialisation. So we’re going to explain the characteristic behaviours of these biases and see how to correct for them. The diagram makes it clear that the Product Manager is a bridge to stakeholders. Focal point for vision-setting. So that’s a good place to start.
- L. The Product vision is important. Helps to set goals Helps to get the whole team to understand what they’re working towards Should not all be on the product manager to communicate the context and vision. This comes into the commitment and accountability dysfunctions we saw earlier, the whole team needs to feel committed for the vision to be delivered. Product Vision is a living thing, not a one-time presentation that then gets forgotten
- L. I’m hopeful that they product vision is partly a result of studying customer problems Product Managers need to make sure that adequate time and discussion is allowed so that the whole team understand and empathise with the customer problems Thinking of that Mary Poppendieck quote from earlier, if you don’t know what problem you’re trying to solve, how will you know if you’ve been successful? Read from slide
- And while we’re talking about user stories, I’d like to take a moment to think about Assumptions it’s also important to consider communication between the product managers, product designers (if you have them) and developers. How do you make sure that assumptions about the requirements are explicit? A source of tension between product & tech can be when what is delivered does not meet the requirements. Except it does meet the requirements, just not the extra assumptions that were between the lines of the requirements and not written in the ticket, or discussed in planning. One way to solve this can be to include examples and mock ups in the stories and planning meetings. Another way is by using Gherkin or some scenario driven tool. But I think most importantly, it’s to make sure there’s a really open line of communication between the dev team and their product owner. If either side can check seemingly random thoughts, assumptions or asides about the feature in development at any time, then it’s much more likely that everyone will be happy with the end product.
- L. Tech debt is a nexus of “us and them” thinking But much like the whole team understanding the customer problems, it’s important for the whole team (including product managers) to understand and be able to advocate for tech debt solutions too Product Managers don’t need to understand all of the tech (I’m never going to be passionate about the complexities of deployment pipelines) but understanding costs, latencies and dependencies in the stack will help to understand the impacts of tech debt on the products and users Afterall, the product is a sum of its tech and its function
- L. https://www.mindtheproduct.com/how-to-spot-a-partial-product-manager/ In summary…(read from slide)
- So let’s talk about the biases of the Developer specialisation
- R. READ QUOTE. Bad code is unlikely to sink the project. Could lead to some rework but you can deal with that. Delivering features that don’t solve the business problem is much more likely to sink the whole project. Have to keep working towards the key business problem, even though it’s hard and there are barriers and ambiguities.
- R. This picture is a stereotype but there’s a lot behind it. There is a temptation for management to measure dev teams by quantity of output. And devs can judge themselves by quantity too - it’s tempting to focus on code delivered as productivity. It’s more tangible and more focused on a dev’s core skills than figuring out how to structure features to work best for users. This doesn’t mean devs need to be BAs or PMs. Coding may be a developer’s core competency but a developer also needs to see the bigger picture to ensure that the system delivered works for users. It’s about using a mix of primary and secondary skills.
- R. Getting feedback means dealing with ambiguity and experimenting. Have to put stuff out there that may not last. That means first iteration may not be perfect and may get rewritten. This can be hard for a dev because it’s their baby. Doesn’t have to be that way though - focus on the why.
- R. Estimation can be a delicate area that can lead to conflict and divide teams. Even with planning poker, there still tends to be a need for long-term planning.
- R. It has to be ok for things to overrun. And ok to ask why and ok to apologise for not anticipating something. Estimates aren’t going to be accurate. Need to trust each other to understand that. Build that trust by explaining.
- R. The point of talking about these biases is not to criticise developers as a group. The point is there are certain behaviour patterns we have to watch for and guard against, in ourselves as well as others. Sticking rigidly to one’s own core expertise can be sticking to a comfort zone. Specialisation is great. Producing code is great. But the end goal is delivering on business objectives and that needs to be visible. We have to keep making it visible even if others in the team don’t see it that way. Even if others above the team don’t see it that way. This is an organisation culture thing too, even though our focus today is on the team.
- L. And that brings us to the biases that scrum masters can fall into.
- L. A scrum master is often a defacto project manager. This is not necessarily a bad thing & can help the team to keep themselves accountable to their goals. But It’s a difficult line to tread to have the team as a whole keep themselves accountable, and not become the person who imposes outside deadlines. In a high performing team, the scrum master can help to facilitate the good team behaviours that we saw on the 5 dysfunctions pyramid & help promote the team’s role within the organisation.
- L. As the Agile manifesto says… Individuals and interactions over processes and tools It’s important that the scrum master understands all that we said before about shared visions and problems This will help to organise the team towards success and not boilerplate agile processes Goes back to the “plan, do, study, act” cycles we mentioned earlier
- R. Don’t become scrum police, enforcing the laws of scrum. Team needs to be evolving its way towards something that solves the customer’s key business problems. That is all that matters. It should self-organise however it needs to. That is what Agile is about. Regimentation is what has annoyed the manifesto signatories about Fake Agile. Really allowing teams to self-organise requires a lot of trust, both from the organisation and within the team itself.
- R. So let’s reflect on what we’ve learned and how to apply it.
- L. So you have your 5 dysfunctions nailed. The team is on fire and seen as a role model for what great teamwork looks like. You’ve excelled at your targets. Congratulations! But it’s likely that within any organisation it’s impossible for the team to be a completely independent entity. Teams are affected by the company culture and other teams around them. And there may be times when aggressive stakeholders shouting too loud. Or dependencies that are hard to manage. Or a hierarchical culture that makes it difficult to raise problems. A great team will need to be adaptive to suit the situation they are in. Obstacles can divide a team. Especially if it’s unclear what influence the team can have or who will take what action. Have to talk about it and face together.
- L. Good teamwork behaviours need to be consistently worked on. It’s not something that can be done once in an offsite and forgotten about when you’re back in the office. And team dynamics can change over time, especially if the wider organisation changes. What things should we be looking out for within our teams as signs that we need to go back to the 5 dysfunctions and make sure that we have the foundations covered?
- R.
- R. Let’s come back to what we learned from Lencioni about how hard teamwork is. Building the trust to debate openly without getting defensive is challenging. That trust does have to be built. We also have to learn to be on the losing side of an argument and accept that and move on. A top team will be constantly moving on and challenging each other on the next point. That’s hard work and is part of why great teamwork is rare. Good Agile is also hard work and can require us to fight some of our own instincts. We all want to see features being delivered and can naturally think of that as productivity. Churning out features is more tangible than really tackling unstructured business problems. We’re all more comfortable exercising our core skills than thinking on our feet. That’s not to say this is all individuals and comfort zones. The drivers for bad teamwork can be bigger than the team, it could come down to bad organisational structure. But teams can fall into self-limiting behaviours even without organisational factors holding them back. Tackling ambiguity and working outside our main competencies is hard. Have to keep challenging ourselves and challenging our colleagues and trusting our colleagues to see why we’re pushing them.
- 2 each.