agile@scale: how we´re coordinating development through multiple teams using agile methodologies

Tobias Gruber, chief product owner, explains how SAST applies agile methodologies to coordinate development across multiple teams to build the SAST ecosystem.

At SAST we apply agile methodologies to coordinate development across multiple teams in the plan and delivery of the different OS and platform components that come together as pieces of a puzzle to build the SAST ecosystem.

As different industries are disrupted primarily through digital channels, agility becomes the new norm to respond to what is known as VUCA environments (volatility, uncertainty, complexity and ambiguity). While the agile manifesto was written in 2001, agile methodologies (e.g., Lean) have disrupted industries since the 50’s.

Popularized by tech giants such as FAGA (Facebook, Apple, Google, Amazon) that have tremendously impacted society in such short timespan, startups such as SAST 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). At SAST 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, at SAST we understand that the key for 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 coming 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 at SAST 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 ideation and development process. At SAST 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. At SAST, 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 SAST 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 SAST is Scrum. At present we count with seven agile teams at SAST, 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 the SAST marketplace.

From an agile@scale perspective, there are no recipes to agile and at SAST 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 at SAST 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.

SAST agile roadmap

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 roadmap 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.

SAFe - the Scaled Agile Framework

While we reiterate that there is a particular take to SAFe at SAST, 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, as applied at SAST, enables us to outline a reliable roadmap 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.

Would you like to know more about SAST and the workflows in developing an ecosystem for safety and security cameras? Are you open to new challenges as a developer? Find our open positions here or for business get in contact with us and let us show you how we can cooperate in developing a platform for the future of safety and security!