Product teams need a family too! @ Agile Coaching Dortmund, Feb 2020 Meetup

Editor's Notes

• #2: As a father of 2 small boys / 1 small girl, I sometimes see similarities between them growing up and certain organization dynamics in the workplace.
• #3: what are great products, follow John Cutler
• #4: rising movement from project-oriented to product-oriented org actually quite hard ---> changes in financing, budgeting & planning, human resources, office layout, etc
• #5: this is from the DevOps Topologies catalog of patterns and anti-patterns that me and Matthew Skelton curate this is the original problem DevOps tried to solve - silos, teams communicate via formal requests and documents only
• #6: basic DevOps premise was simply to get teams to collaborate, to actually know each other and work together on deployment, monitoring, performance, integration issues faster and higher quality and morale
• #7: Why? Research in Accelerate book and 2018 State of DevOps: high performing teams are twice as likely to be developing and delivering SW
• #8: with product team we take that even further, to the point it’s a single team
• #9: Seen a few examples where teams were working almost as independent startups.Problem is that this type of full collaboration at scale is not possible, especially in established orgs. On the other hand, growing startups often abandon the product team model completely and move to silos. With DevOps for e.g. we can make it worse actually by assuming we need a team of DevOps experts.
• #11: But there’s more to fast delivery than high performance alone. What are other obstacles to continuous flow? In our experience consulting with orgs worldwide, we have found these common obstacles which we talk about in the book we just finished writing called Team Topologies.
• #12: today we are going to cover superficially how to overcome these in the bottom half teams pulled in many directions: test more, understand infra, monitor perf in production, move security left, all while being asked to deliver more features faster - hard to make sense of what to prioritize and how to get things done painful/confusing re-orgs: now Agile, next DevOps...
• #13: When we say flow is blocked we’re talking essentially about handovers between teams. Wait time until work is scheduled, prioritized and done by the other team. Their schedule is often out of our control, sometimes leading to escalation wars to push teams to work on “my bit”. This is not only inefficient, it’s tiring, leads to blame culture and kills morale.
• #14: if cloud team = infra on cloud then same problem but if cloud team focus on the macro infra, allowing dev teams to quickly and independently set up new environments with adequate policies (security, cost) without handovers then it can actually speed up flow team names are a very weak / ambiguous way to understand capabilities and responsibilities
• #15: The idea of shared component teams is good in theory. In practice it blocks flow.
• #16: Are feature teams good? Depends on maturity, discipline. We can and we should put a lot of effort in to make feature teams deliver fast (test coverage, pair/mob programming, etc). But the flow could be hampered later in the cycle, during release and support especially if we can’t quickly debug and bring in the people to fix issues.
• #17: "Handovers kill flow so let's kill handovers!"
• #18: it’s interesting to see BMW point out specifically that they want end-to-end responsibility to avoid handovers.
• #19: able to take a piece of work from idea to delivery fast, rich feedback loops from users to the teams serving them
• #20: The Amazon 2-pizza team model is an example of stream-aligned teams: the teams are substantially independent, have ownership over their services, and responsibility for the runtime success of the software they write. Amazon has been using this model for over 17 years!!! shows how effective it can be.
• #21: There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. It doesn’t matter what technology they use. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world.
• #22: *joke* ended with a very diplomatic … My saying goes: “Everything is a dependency and expectations management problem.”
• #23: allowing great products to emerge like John said…
• #24: but this is the elephant in the room *read quote*
• #26: but now you also need infrastructure as code skills...
• #27: CI/CD understanding deployment pipelines, criteria to deliver to production
• #28: operational skills… how the app performs live
• #29: security… at minimum vulnerability scanning, static code analysis for secure code, OWASP top 10
• #30: But.. At this point you’re still only building and delivering the product in the right way…
• #31: you also need a range of product skills… need to actively seek feedback from ops/support/customer (the closer the better)
• #32: so you can iterate until you get the right product that your customers need and are willing to pay for effectively too much cognitive load for teams.
• #33: We’re saying we want to increase autonomy of teams so they can go faster…
• #34: but you also need competences, otherwise they will actually go slower having to discover all these new ways of working they’re not familiar with. Competences are the building blocks to enable autonomy
• #36: Product Teams need a family too! They need a support system that helps them navigate, learn and evolve. Without it product temas will ironically become less efficient, having to worry about all aspects of delivering and running systems
• #37: Help reason about organizational landscape, which teams exist and what do they do at a 10000-foot view? Understand what are the org capabilities and where to improve. Clarify team purpose (product and others), responsibilities and interaction modes. If each team is identified simply by name or generic role (e.g. dev, ops) it’s quite hard to get a sense on whether the right teams exist for the work the org needs to get done or at the speed they would like it done.
• #38: so this is our product team
• #39: blurry definition of product and/or product delivering value to clients means multiple parts with different tech & change cadence involved. instead we talk about streams of work that align to business areas or needs
• #40: A stream can be a single product, but also a service, or a set of features within a larger product. Streams can be aligned to business areas, or specific customers, user personas, or even compliance (in highly regulated industries). A stream-aligned team is funded in a long-term, sustainable manner as part of a portfolio or program of work, not as a fleeting project
• #41: Software development inside business units is the most effective, because it moves at the speed of the business units. Any centrally controlled software can only move at the slower speed of the org as a whole. Reduce cognitive load it’s all about balancing cognitive load for the team and minimizing dependencies on other teams, setting clear:- Responsibilities- Expected behaviors- Warning signs
• #42: kids are like product teams - able to do amazing things but need help to evolve and become independent it can get messy...
• #43: can help them out with other topologies reducing cognitive load... *joke* so they have more capacity to mess up on germane aspects? leaving more capacity for germane cognitive load (which is where the “value add” thinking lies)
• #44: Provide good abstractions for lower level services that stream teams need, so they can focus their efforts on the business side of delivery. Distinguish users from owners.Stream team should not have to know internals of provisioning, deployments, monitoring but rather how to use them.close collab with stream teams for discovery, X-as-a-service for execution
• #45: parents are the platform - provide essential needs for kids like… feeding-as-a-service
• #46: A whole other talk... Not the “black box”, imposed platform of “old” “Create a path of least resistance. Make the right thing the easiest thing to do, and try to make the wrong thing or the old ways to be a little bit harder." A good platform makes services simple to adopt and use, instead of mandatory - not just because it’s a “nice” thing to do, but mostly because it forces good dev practices, focus on UX, reliability, etc. We also want the platform to be as small as needed and more importantly to be as much used as possible. Not legacy services of old not used and eventually not understood. Like a Thinnest Viable Platform.
• #47: Platform is the smallest set of APIs, tools, documentation and support. Small number of highly compelling services that are reliable and easy to use, rather than a large number of services that are unreliable and do not match stream teams needs accurately. (Make the right thing the easiest thing to do). Not the bloated, black box, hard to use platform of “old” that actually requires more of the dev team as it’s hard to use/understand, requiring many workarounds. There are plenty of examples of orgs investing in modern platforms, from Mercedes to ITV, Twilio, ING, Adidas. More case studies in the book. Platform must be built and run as a product or service itself, with Stream-aligned teams as internal customers, using standard Agile and DevOps practices within the Platform itself. Avoid too-common trap of building a platform disconnected from the needs of teams.
• #48: Orbits around stream teams, team of experts to help upskilling stream teams but largely reducing the learning curve and avoiding common mistakes.
• #49: like training wheels - they guide teams towards new areas of knowledge and provide the building blocks for them to thrive: training, tool and framework selection, examples, research and guidance in the area
• #50: complicated, PhD level algorithms or niche technology basic premise is that it’s unrealistic to ask stream team to take on a complicated subsystem which requires 100% effort. The decision is driven by team cognitive load, not by a perceived opportunity to share the component.
• #51: 90-95% of systems should not need one, but there are exceptions - face recognition, video codec processing, trading algorithms
• #52: can’t ask my 4 year old to tie his shoelaces, unrealistic expectation for his current knowledge level
• #54: example of how teams might be interacting stress this is a snapshot of a point in time, needs to evolve over time
• #55: Fundamental topologies act as “behavioral magnet”. effective org design approach
• #56: today we covered only partially this 4 fundamental topologies for aligning behaviors and understand capabilities how teams are expected to interact the need to evolve continuously these topologies to meet tech and market challenges, instead of discrete re-orgs every few years
• #57: More things are needed such as effective software boundaries, alignment with support for organizational sensing
• #58: Happy to talk about this after the talk!
• #60: we think these three books together will help you move to a product-oriented, high performance organization