Recommended
More Related Content
Viewers also liked
Viewers also liked (16)
Similar to Dependencies cause organisational friction
Similar to Dependencies cause organisational friction (20)
Recently uploaded
Recently uploaded (20)
Dependencies cause organisational friction
- 1. "reinvent public broadcasting for a new generation in order to compete against giants such as Netflix and Amazon" BBC Director-General Tony Hall (2017) The Last Kingdom - BBC Two
- 2. How do you ensure teams act in an Agile way, yet still deliver to deadlines and co- ordinate their activities. BBC Proms – BBC Radio 3
- 3. SMP
- 4. Board
- 5. Mobile Platforms - Salford
- 6. Dependencies between teams cause friction, which slows down the release of customer value Special Forces: Ultimate Hell Week - BBC Two
- 7. Ensure your roadmaps are aligned Top Gear Series 24 – BBC Two
- 8. Embed your expertise upstream Planet Earth ll – BBC One
- 9. Develop your organisation al empathy Silent Witness – BBC One
- 10. Close collaboration to avoid surprises Comic Relief – BBC One
- 11. Be an enabler for others, don’t restrict forward progress Line of Duty - BBC Two
- 12. We are the guardians of our components not their guards Porridge - BBC One
- 13. Doctor Who - BBC One 1. Communicate at all levels on a regular cadence 2. Integrate early and often to identify dependencies 3. Involve the whole team at each stage 4. Be an enabler to others
- 14. Delivering mobile across the BBC Matt Thornhill - Senior Delivery Lead Mobile Platforms Thank you. Murder in Successville – BBC Three
Editor's Notes
- "reinvent public broadcasting for a new generation in order to compete against giants such as Netflix and Amazon" That's quite a statement from Tony Hall We have a target of doubling the number of visitors and quadruple the time a user spends on iPlayer by 2020. This ambitious target requires a lot of work to be completed across the BBC. As an example of the number of teas involved, iPlayer alone is split into 3 divisions - mobile, web and TV. Each of these divisions is split into several smaller groups (crews) of around 10-15 people. There are further teams running the backend systems, servers and managing the encoding and distribution of programs. That’s a lot of people across multiple locations in the UK. That will all need to work closely together
- How do you ensure agility whilst coordinating many threads of activity? This is a challenge for any organisation regardless of size. In this presentation I will focus on some of the tactics we employ as Mobile Platforms to ensure we and those around us remain Agile. Why are Mobile Platforms an ideal case study? We are responsible for building and maintaining a variety of core native mobile components that are used throughout the BBC estate. We manage 19 components in our single team, which are currently used in 14 native mobile apps, each app is then developed by its own crew.
- These components are used across the BBC and we are often the central pivot point and the glue between a number of teams. This places us at the center of that co-ordination effort The highest profile of our components is the Standard Media Player or (SMP as we refer to it) – If you have ever used iPlayer on your mobile, tablet or used cast to watch on your TV then you were using SMP. To give you an idea of the importance of mobile, in the week following Christmas just gone, SMP in iPlayer mobile had over 7 million program views, that's over 10% of the UK population watching at least one program a week.
- How do we work - As a team we strive act and work in an agile way, we imit our work in progress to ensure a very narrow focus, We slice our work thinly and look to release our components weekly with a focus on delivering value in each release. With weekly releases we ensure that the scope of change is small which helps simplify testing and provides high confidence in the quality of our releases. With the regular release we enable other teams to plan based on our predictable cadence of value.
- How Else – Pair Programming – having engineers work together on a ticket ensure we have less work in progress and two heads are better than one for solving problems Our testers are embedded with the engineers rather than in a separate team (same for other disciplines UX etc), Engineers also stay on a ticket until it has passed regression meaning we don’t have a costly handoff or delays whilst we wait to get a problems fixed. The upshot is that we can quickly deliver small features and change direction easily to address new opportunities.
- So what is the biggest challenge we face to achieving the 2020 target? Dependencies cause organisational friction which slows down release of customer value. It is that value that will drive audience engagement. Fast feedback is essential to any organisation as it provides data which you can use to improve future deliveries. I’m going to talk about four tactics we have adopted that help us reduce challenges to agility.
- Tactic No.1 - Ensure your roadmaps are aligned Seems obvious – but all too often organisations and teams discuss roadmaps at the start of the year and then squirrelling themselves away, chances are something major will shift within the first month that will derail the well laid plans. All the teams we work with have their own products, each one with its own product owner, stakeholders and executives who all have their own agendas and ideas of what is most valuable to the audience. How do we mange that? Meetings get a bad wrap and rightly so in many cases – however with a clear focus and outcome they are worth more than a 100 emails in maintaining alignment. Set a regular cadence for this communication so that you get into a rhythm of sharing: monthly roadmap - look to the future, next quarter and beyond Weekly project specific meetings - now and next, coordinate dependencies, close alignment of objectives across teams Cross team daily standups that bring together multiple stakeholders working towards a common goal and the focus is on now with an eye to removing blockers. This stand-up is following the normal team standup. It is critical you invest substantial amounts of energy in communicating at all levels within your organisation to ensure you remain aligned.
- Tactic No. 2 to reduce friction between teams - Embed your expertise upstream If you have a deliverable that will form part of a bigger system, then take steps to ensure that the integration further up the value stream (closer to the audience) is as smooth as possible, we do this in a number of ways: When delivering a component to say iPlayer or BBC news we will pair with people in that team or even on occasions work with their entire crew: This enables us to learn about the challenges they might face using our components – So we can improve future releases. Possibly even making changes there and then to reduce friction.
- Tactic No.2 cont. Our intimate knowledge of the feature/component, coupled with the other teams knowledge of the product, reduces the time it takes to integrate. Allowing a smoother process and cutting time to release and therefore deliver value to the audience Another favorite technique is for us to spike the system end to end, this is a quick prototype that allows us to test out and validate assumptions. Enabling us to understand the challenge in more detail which we share with other teams. Once completed and we will also wok with other product teams to add our spike into their product, which means that both teams to learn really early in the project what integration obstacles we might face. By Building organisational empathy in this way you ensure team members have their heads up and outward focused, they are more considerate of their actions and more likely to see challenges coming early
- Tactic No. 3 - Close collaboration to avoid surprises There is nothing worse than delivering a feature only to realise you solved the wrong problem. The impact of this can derail even the best laid plans across multiple teams. For that reason we invest time to ensure that everyone on a project is included along the way: Daily standups everyone is present and we discuss progress and challenges ensuring fast feedback to all. When Kicking off new tickets we ensure people present from product, engineering and test to ensure the requirements are clear and considered. If you miss out a discipline at KO then you run the risk of delivering a sub optimal solution i.e. missing test result in engineers not considering how the work will be validated and this causes costly rework work and delays. We also regularly hold pre project workshop for other teams to attend. Here we present our proposed solution for a ticket or project and provide them with the opportunity to feedback. Many times this has paid dividends when together you identify a missed opportunity or highlight a potential roadblock. TOP TIP - ensure the attendees understand that this is an opportunity to iron out any creases and not for them to dictate a solution to your team
- The final one - Tactic No. 4 - Be an enabler for others, don’t restrict forward progress Teams are of a fixed size, it takes time to add more people and bring them up to speed. As is the case in any team where components need to be maintained there can often be a lot of demands on our time. How to prevent a team being dominated by incoming requests, or swamped in a see of context switching unable to progress with the critical path? New for this year - We have a pair of engineers (on rotation) who are entirely outward facing, and by that I mean they are focused on helping other teams work with our components – this pair look to educate and empower others outside our team.
- Tactic No. 4 Cont. We have rigorous set of guidelines that others follow if they want to amend one of our components: We ask that other product teams engage with us upfront and discuss the change they might want to make. Teams often think about a solution to their own challenge and we need to broaden the perspective to include everyone who uses a component, that way the most value can be derived across the BBC. By enforcing certain standards around automated and manual test coverage we also ensure that these components remain manageable, by which I mean we have confidence in releasing and maintaining them. We are the guardians of our components not their guards.
- So how will we reinvent public broadcasting for a new generation? Details still to be decided – but we must Communicate regularly at all levels to ensure you maintain alignment Integrate early and often to identify dependencies and flush out problems that will be more costly to fix in the future and could derail a project. Involve the team at each stage of the process - it's a false economy to miss people out, the later you make a change the more it costs Be generous with your knowledge and an enabler to others.