As the demand for autonomous mobile robots (AMRs) continues to grow, both software and hardware development projects have become more complex and require effective management techniques. At arculus, we have adapted the popular Scrum framework to manage the development of our robot, the arculee. In this blog post, we’ll take a closer look at how we use Scrum for hardware and software development in robotics and highlight some of the key benefits of using this framework.

Understanding Agile and Scrum

Scrum and Agile are two frequent terms used in the Project Management world. Although they share a close relationship and are often used interchangeably, it’s important to understand their differences. In general, Agile is a mindset, a philosophy, and Scrum is a specific methodology that uses Agile to develop complex products and systems. The Agile mindset focuses on incremental delivery, team collaboration, continual planning and learning.

Many different frameworks use Agile as a basis, and Scrum is the most popular among them. It works by breaking down projects into smaller, more manageable chunks. Each part is then developed in short cycles, with each cycle building on the progress made in the previous one.

The basis of Scrum lies in empiricism and lean thinking. Empiricism is the belief that knowledge is derived from experience and practical observation, while Lean thinking emphasises efficiency by minimising waste and focusing on core elements. Scrum is also heuristic, meaning that it encourages continuous learning and adaptation to changing factors. It recognises that teams may not have all the necessary information at the outset of a project and will need to evolve through practical experience.

The arculus SCRUM playbook

The structured approach to Scrum is outlined in the Scrum guide. Although authors Ken Schwaber and Jeff Sutherland provide a set of roles, events, artefacts, and rules, the methodology is essentially flexible and adaptable, allowing teams and organisations to modify their approach to fit specific needs and circumstances. The Scrum’s versatility is a crucial advantage for organisations seeking to adopt the framework successfully. Here is how we use it at arculus.

The SCRUM Team

A Scrum team is a small group of people dedicated to working on specific segments of the product. At arculus, we divided our robotics department into six smaller groups: Enablement, Functions, Embedded Software, Electronics, Mechanics, and Project Engineering. Each Scrum team has three essential roles:

• Product Owner (PO): responsible for defining and prioritising the product backlog to ensure the development team works on the right tasks according to the business needs.
• Scrum master: responsible for ensuring that the Scrum framework is followed, facilitating the events and removing any impediments that prevent the development team from achieving its goals.
• Developers: The individuals in the Scrum Team responsible for producing any component of a functional product by completing items from the sprint backlog (more on that soon).

The Sprint

The guide defines sprints as “the heartbeat of Scrum, where ideas turn into value”. In more practical terms, a sprint is a time-box event during which the different teams work towards their respective targets. These so-called sprint goals provide a structured framework for teams to collaborate, plan, and deliver work predictably and consistently. At arculus, sprints have a set duration of two weeks.

The Events

Each sprint has a set of events. The first one is sprint planning, which officially begins the sprint. Scrum Master Rudolf Guth explains, “This is where the POs define the sprint goals according to upcoming product needs. The whole team can then negotiate which stories make sense and are achievable according to the sprint goals, always taking capacity or potential obstacles into account – and assuring delivery of value.”

Throughout the sprint, the teams also get together in short daily meetings. The group has 15 minutes to align on tasks for the next 24 hours, ensuring everyone is on track to achieve their defined goals by the end of the sprint.

At the end of the sprint, there is the sprint review. That’s where the team presents which goals it has achieved in the past two weeks. “Sprint reviews are also essential to ensure the Scrum pillars of transparency and inspection”, explains Rudolf. “The whole company and other important stakeholders are invited to see what the teams have accomplished during the sprint.”

The sprint ends with the sprint retrospective. In this event, the team inspects its own performance by examining the individuals involved, their interactions, the processes followed, and the tools used. This review then serves as a basis for improving cooperation during the next sprint.

Scrum of Scrums

Besides the official events described in the Scrum guide, arculus has one additional event for the teams: the Scrum of Scrums. In this meeting, each development team presents their sprint goals and focus. This helps them align on any unforeseen dependencies or potential issues which can prevent delays or conflicts. “One day after the sprint planning, one person from each team comes to this meeting to present their goals and ensure cross-team alignment”, describes Rudolf.

The Artefacts

In Scrum, artefacts are tangible and transparent representations of work or value. They are created and used to establish a shared understanding and effective communication among the Scrum Team, stakeholders and customers. The three artefacts defined by the Scrum guide and used at arculus are:

• Product Backlog is a list of work the Scrum Team needs to complete to improve or finish the product. The PO maintains this dynamic list of features, requirements, enhancements, and fixes, which serve as the primary input for the Sprint Backlog. It is essentially the team’s “To Do” list, and it is constantly reviewed, reprioritised, and maintained.
• Sprint Backlog is a selection of items, including user stories or bug fixes, chosen by the POs and development team to implement during the current sprint cycle. During the sprint planning, the team selects which items they will work on from the product backlog. While the sprint backlog can be flexible and may evolve during the sprint, the team’s fundamental sprint goal, which defines what they aim to achieve in the current sprint, cannot be compromised.
• Sprint Goal, or increment, is a concrete step towards the Product Goal. The teams can work on multiple increments during a cycle. These goals are then presented at the Sprint Review to showcase what the developers accomplished during the sprint.

Scrum For Robotics

Scrum was initially created for software development and is still primarily used in that context. However, the framework has become more flexible and adaptable, making it suitable for other types of projects. At arculus, we have adapted Scrum for robotics development, where both hardware and software are integral components.

This adaptation has allowed us to effectively manage our projects, improve communication between our team members, and increase overall efficiency. But it didn’t come without challenges. Rudolf explains, “while software can easily be iterated, hardware changes can be prohibitively expensive. That means that the hardware development teams must carefully consider the impact of any changes and plan accordingly to minimise disruption to the overall project timeline and budget.” This is typically where the iterative design process takes place in order to avoid significant changes later on in the development cycle.

Another challenge comes from one of the critical principles of the methodology: breaking down tasks into smaller chunks. “Finding a way to effectively dismantle hardware tasks and present progress to stakeholders can require adaptation on the story level. It’s a challenge that we are constantly working to overcome in order to ensure that we are transparently evolving with the product and effectively managing our projects.”, says Rudolf.

Values And Principles

Scrum is built on a set of values and principles that guide the behaviour and decision-making of its practitioners. Despite the adaptation of Scrum to the unique needs of robotics development, Rudolf explains that such values and principles should remain untouched. Only then can the teams really benefit. The values defined by the guide are:

• Commitment to achieving the goals and supporting each other;
• Focus on the work of the sprint;
• Openness to ensure transparency and honesty within the team;
• Respect towards other team members’ perspectives;
• Courage to take risks and make bold decisions that foster innovation.

Along with these values, Scrum also has a set of principles that guide the framework’s implementation at arculus. These principles are:

• Control over empirical processes → making decisions based on evidence, not assumptions;
• Value-based prioritising → focusing on delivering the most valuable features first;
• Collaboration → working together towards a common goal;
• Self-organisation → taking ownership and making decisions autonomously;
• Time-boxing → helps to create a sense of urgency and encourages the team to deliver results within a fixed timeframe
• Iterative development → continuously refining and improving the product over time.

Our Pro Tip

For Rudolf, our successful use of Scrum for both hardware and software development comes from the crucial understanding that it is not a one-size-fits-all methodology. As he put it, “we always need to understand our reality, and then we need to adapt the framework to fit it.”

In other words, while Scrum provides a framework and guide, it is ultimately up to each team to adapt it to their specific needs and constraints. By doing so, organisations can experience the benefits of Agile methodologies, such as increased communication, transparency, and efficiency. So, even though hardware development may present unique challenges, with the correct adaptation and mindset, Scrum can be a valuable tool for managing any type of project, including robotics.