Agile@scale: How to coordinate development through multiple teams

Popularized by tech giants such as FAGA (Facebook, Apple, Google, Amazon) that have tremendously impacted society in such a short timespan, startups such as Security and Safety Things take inspiration from these giants that once were small startups and try to mimic this new way of working, not only in technology but also in business.

Agile principles we live by

At its core agile is a series of principles that act as an umbrella under which multiple methodologies can be applied both at team (Scrum, Kanban, Scrumban, XP, etc.) as well as at scale (LeSS, SAFe, Spotify model, etc). Here we live the agile principles as follows:

1. Individuals and interactions over processes and tools: while we take time to establish a minimum necessary process to avoid chaos and the tools needed to perform with the highest efficiency, we understand that the key to success relays on our talent. The best solutions to solving the pain points of our customers result from having the best talent collocated working together face-to-face to understand the problem and come up with the best solution.

2. Working software over comprehensive documentation: customers won’t care about how detailed your documentation is if your product is released already outdated to the market. The priority is to develop a minimum viable product that can be tested in a pilot phase and to quickly iterate based on customer feedback.

3. Customer collaboration over contract negotiation: customer satisfaction is only achievable when customer’s input is considered along the idealization and development process. We apply design thinking, user testing on a weekly basis and recurrent communication to understand the pain points of the different personas (e.g., integrators, third party app developers, end-customers and camera manufacturers) that take part in our ecosystem. 

4. Responding to change over following a plan: as part of a fast-paced environment with frequent communication loops and customer feedback, it is crucial to being able to quickly react to change rather than getting lost in bureaucratic processes. We receive weekly feedback from user testing and iterate on every sprint cycle. This requires very streamlined communication between design, product and engineering teams.

From a product and technology perspective, the ecosystem consists of an AOSP-based operating system running on the camera and surrounding services like a cloud-hosted app marketplace and a device management portal.

At team level, the preferred agile methodology at Security and Safety Things is Scrum. At present we count with seven agile teams, each focused in the development of one component, running in a synchronous 3-week sprint cycle.

Nonetheless, as is normal in such a complex ecosystem, there are lots of cross-team dependencies. For example, the operating system has to provide mechanisms and interfaces to allow the installation of an app from our marketplace.

From an agile@scale perspective, there are no recipes to agile and we rely on our particular take on the Scaled Agile Framework. The SAFe-framework, is based on Lean practices and is (similar to LeSS) an agile framework to support alignment, collaboration, and delivery across multiple agile teams. 

From an agile@scale perspective, there are no recipes to agile and we rely on our particular take on the Scaled Agile Framework.

While SAFe is regarded the least agile out of the agile@Scale frameworks, it is a good starting point for a startup that not only operates in such a conservative space (security), but that is also born out of a corporate environment. As our teams become more mature in agile, we simplify processes to become more nimble.

Security and Safety Things agile road-map

We are planning here concretely for half a year, initially have high level features that are not yet fully detailed but already aligned with our stakeholders and T-shirt size estimated by the component teams. The features are prioritized via the RICE scoring methodology (Reach, Impact, Confidence & Effort) while we take into consideration the known boundary road-map conditions, such as trade fairs.

The product owners break these high level features down for their teams into epics and stories. We thus have the milestones for the stakeholders, but can adapt the requirements and functions over time. For example, if we realize that a particular feature is critical and extremely important for a particular partner, we can prioritize it to make it available at a particular time, such as a developer hackathon.

Reliable timelines are an important factor in any organization. Delivering on-time and budget while innovating is crucial for our customers, partners and investors. Agile artifacts such as burn-down charts at sprint and MVP levels as well as weekly status meetings help us track the status of each component in order to steer as needed either in scope, talent or timeline.

Security and Safety Things agile road-map

While we reiterate that there is a particular take to SAFe, the Scaled Agile Framework brings a level of predictability that we can leverage to orchestrate and coordinate our component teams, which develop complex tasks at different locations.

SAFe enables us to outline a reliable road-map that we can also communicate to our stakeholders. It is important in this long-term planning that we give the teams sufficient room for bug fixing and the addition of unpredictable challenges.

In the process of development we have learned how important it is to obtain the necessary requirements from all relevant teams. This applies to internal departments such as User Experience (UX), Sales and Marketing as well as to external partners such as integrators, app developers and camera manufacturers. 

One of our most important lessons is to iterate and refine the features and requirements with the product owners and component teams at an early stage. If you don't go into such detailed considerations at an early stage, you may notice at a late stage of the project that certain tasks are more complex to implement than expected. It is well known that the development effort in high-tech environments is often underestimated.

Releasing early and often brings valuable feedback

Continuous integration and delivery is also an advantage for our platform, the marketplace and the Integrator Portal, because we can ideally release a new version of our product every three weeks. This has the benefit that we’d receive regular feedback, which in turn can be incorporated immediately into further development.

In the current situation, in which the products and the OS are used by early adopters and camera manufacturers, this strategy of direct release is completely okay. Later, we will certainly summarize releases and offer them at least as an alternative to continuous delivery, so that the customer does not have to update too often.

In addition these bundled releases allow for better coordinated marketing announcements. This new situation will become an exciting challenge, which we will become most in the interest and for the benefit of our integrators, app developers and customers.

About the author: Tobias Gruber works as Chief Product Owner at Security and Safety Things GmbH, managing several agile component teams developing an IoT ecosystem. Prior Tobias was working as Scrum Product Owner at Bosch Security and Safety Systems planning and delivering cloud-based IoT services.

Did you like this article? Follow us on LinkedIn and Twitter to get all the latest information about Security and Safety Things including when and where to meet us at our event days.