Andy Nesling is the Product Manager for IoT Cloud at Dyson, global leader in innovative household appliances, where he is helping to rapidly grow the platform to support the increasing range of connected products.

He has been leading connected product development teams for over 12 years, in roles ranging from development to test and product ownership. Andy is an evangelist for lean software development, Continuous Delivery and its application to the often waterfall world of physical product development.

We spoke to Andy about his recent experiences with using agile software delivery approaches to span teams in mobile, cloud, and embedded software systems.

Q1 - What kind of challenges do you face at Dyson with flow for software delivery? Isn’t it quite tricky to work across IoT, embedded systems, cloud, and mobile?

A – It is quite tricky working across cloud, embedded systems, mobile and robotics, but that challenge is what makes it so fun! The other advantage of working with teams which span multiple disciplines is that you get a wealth of different perspectives on how to solve a particular problem which ultimately leads to much better and more ingenious solutions.

I think the challenges we are constantly looking at to increase flow, are probably no different to a lot of companies even in quite different industries or domains:

• What are the streams we should align our teams around to maximise flow through minimizing dependencies and  cognitive load. Then continually looking at how this needs to change as we grow in size and knowledge.

• What is the best way to get a collection of teams which have to collaborate close to their customer, so they know what to build and what not to build!

• What should form part of our platform? A number of teams will have dependencies on this (potentially reducing flow), but should ultimately help them to move faster if we get the balance right by leveraging common tooling.

• What is an appropriate way to automatically test user features covering key integrations which span multiple teams, technologies and hardware, without being fragile and a bottleneck.

• What is the best light weight process we can use allow collaborating teams the opportunity regularly sync.

Q2 - What kind of software engineering teams do you have at Dyson? In what ways do they work together? 

A - We have small cross functional teams of between 6-10 people, who have a broad range of expertise in development, test, platforms/tools, product management and lean/agile processes. Each of our teams is primarily aligned to one of 4 disciplines; cloud services, embedded software; Robotics/Machine Learning and Mobile Application development. We then have groups (or families) of between 7 to 10 teams who regularly synchronise on all aspects of their work. Currently these families are primarily made up of teams aligned to the same disciplines, however we anticipate this is likely to change over time as it becomes more important to regularly synchronise with teams along a different axis.

As a fair amount of our work integrates with physical products we have found that an integration cadence of every 10 weeks across all our engineering disciplines (software & hardware) works well. This is not to say that individual teams across disciplines do not integrate with each other much more frequently (often daily), wherever possible. However, every 10 weeks we will all get together and agree on the objectives and key results we all (approx. 50 teams across 4 countries) want to achieve over the next 10 weeks.

In addition to the regular integration cadence we also have communities of practice where people with particular expertise, passion or interests regularly get together to share ideas. These communities of practice currently cover topics including Product Management, Product Design, Architecture, Agile practices, testing & security.

Q3 - Have you seen Conway’s Law driving similarity between the team communication lines and the resulting systems? What challenges does this mirroring force present for you at Dyson? 

A - I think it is fair to say that we see this law in action every day, as in some ways it a law which describes human nature! As we have been expanding the number of software teams, this has been something that we have paid particular attention too, with regards to the responsibilities each team should take. We have seen this working for us when we have been looking to get clear separation of concerns between different systems and services with different release cadences and ensuring we have well defined APIs and communication protocols in place between them. We have also seen it working against us when we haven’t got the right teams in the room to solve a problem which spans multiple teams. Generally speaking I think we see it most when it is painful, and don’t fully appreciate it when it is working for us!    

Q4 - You’ve recently been reading the Team Topologies book which covers some situations with IoT and physical devices. How do the examples from Team Topologies resonate with you?

A - To be honest I would say that the whole of the Team Topologies book resonates with me and our experiences and not just the IoT Examples. One thing that is particularly refreshing in Team Topologies and in particular the IoT examples is the recognition of the impact on cognitive load should have on team design. It’s rare at the moment that you read much about this and for us it is very important.

We cannot have an effective single 6-10 person feature team which could be working on Cloud services, mobile apps, embedded software and robotics as the overhead in context switching would be unsustainable. This does bring its own challenges though, in that to deliver a feature for our users, involves collaboration between a number of teams. This is something we are constantly looking at how we improve and feel that there are a lot of techniques out there still to be tried, tested and tuned.

Watch Andy Nesling’s talk at Agile on the Beach 2019

Follow Andy Nesling at @andynesling and www.linkedin.com/in/andrewnesling/