Agile AIoT

Abstract

Being able to address the complexity and volatility of AIoT product/solution development in an agile way is a key success factor. This chapter first takes a look at some of the key challenges to achieve this, then discusses the Agile V-Model as a way to get there, followed by a discussion of the agile AIoT organization.

Being able to address the complexity and volatility of AIoT product/solution development in an agile way is a key success factor. This chapter first takes a look at some of the key challenges to achieve this, then discusses the Agile V-Model as a way to get there, followed by a discussion of the agile AIoT organization.

1 Agile Versus AIoT (Fig. 23.1)

Fig. 23.1

AIoT and agility

1.1 Agility Versus AIoT: Impediments

With the emergence of Internet- and Cloud-based development, Agile software development has risen to become the de facto standard for many organizations, even though there are still many (sometimes religious) debates about how to implement Agile correctly. Software projects are usually plagued by very high levels of complexity and highly volatile requirements. Agile development is addressing this issue by combining collaborative efforts of self-organizing and cross-functional teams with a strong sense of customer-centricity and focus on value creation. Agile promotes continuous exploration, continuous integration and continuous deployment. Scrum — as probably the most prominent Agile method — is based on an adaptive planning approach, which combines higher-level epics with a more detailed requirements backlog. Detailed requirements (“user stories”) are typically only created for the next 1–2 sprints ahead. Successful Scrum organizations are very thorough and consequential in their Scrum rigor while still supporting adaptive and flexible planning.

Unfortunately, in most AIoT projects, there are some impediments to a fully Agile approach, including the following:

• Cultural differences between Cloud-native developers and product/manufacturing type of engineers

• Scalability across multiple, often distributed teams (e.g. AI development, cloud and edge/embedded software development, hardware and network engineering)

• Sourcing and external dependencies which require more documentation and long-term planning

• The integration of teams working on Artificial Intelligence, which does not yet have a proven agile method to support it

• Hardware and embedded software engineering, that play by different rules than cloud-based software development

• Components/features which have to be “First Time Right”, e.g., because they will be deployed on assets in the field and can no longer be easily changed afterwards

• Functional Safety requirements, which often do not play well with an agile approach

The following will look at each of these impediments in detail, followed by a recommendation for how to address them in an AIoT product organization (Fig. 23.2).

Fig. 23.2

Agile inhibitors

Impediment 1: Cultural Incompatibility

The first impediment for the adoption of a pure agile approach in an AIoT-driven product organization is the cultural differences typically found in heterogeneous teams that need to work together. Developers who are used to work with frequent, Cloud-enabled updates have a very different approach to project management than manufacturing-centric engineers who know that after the SOP (Start-of-Production) any change to a physical asset after it has left the factory involves a costly and painful recall procedure. As shown in the figure below, different types of organizations typically have different types of cultures - even within the same company. Applying one-size-fits all methods to such a cultural mix will be difficult (Fig. 23.3).

Fig. 23.3

Corporate cultures and agile setup

Depending on the culture found in the organizational units involved in the development of the AIoT product, a matching agile approach must be chosen. Approaches such as Scrum of Scrums (SoS) or Large Scale Scrum (LeSS) could be a good fit for an entrepreneurial culture, which permits a “pure” agile approach. The Scaled Agile Framework (SAFe) could be a good fit for organizations that come more from a “Command & Control” background, often combined with elements of a more matrix-like organization.

Impediment 2: Organizational Scalability

The second impediment is organizational scalability: most “pure” Agile methods such as Scrum work best for single, colocated teams. Chances are that an AIoT project will be larger, involving multiple teams that are dealing with AI development, on-asset components (Edge software, embedded, hardware), the IoT network, the backend business logic (cloud or on-premises), and the integration of existing enterprise systems. Given the diversity of these tasks, it also seems likely that the teams and team members will be distributed across multiple locations.

Consequently, most AIoT projects will require an Agile method that can be scaled beyond a single team and potentially a single location. In the discussion above, different approaches for scaled Agile development were introduced, including Scrum of Scrums (SoS), Large Scale Scrum (LeSS) and the Scaled Agile Framework (SAFe). We will discuss later how they can be adapted to overcome some of the other limitations of AIoT development.

Impediment 3: Sourcing & External Dependencies

Many AIoT-enabled products have a complex supply chain, often using different suppliers for cloud software, edge software, embedded hardware and software, AI, and telecommunications infrastructure. The combination of technical complexity and supply chain complexity can be difficult to manage in a purely agile setting. Sourcing can already be a complex topic in normal software projects. With the added complexities of an AIoT project, any form of Agile organization will have to be closely aligned with the sourcing process.

In some organizations, Agile teams will have a high level of autonomy over the sourcing process. In a matrix-type organization as described above, a central sourcing team will have a high level of influence and potentially little experience with this type of project. If the AIoT product is a large-scale, strategic product, it is very likely that procurement will dominate the first one or even two years of development. In addition, lead times for hardware acquisition can be much longer than those of software components.

Most likely, the greatest challenge from an Agile perspective is that most sourcing projects require extensive documentation of requirements or even solution designs. Many procurement organizations still see fixed-price offers as the preferred way of sourcing complex solutions. The level of documentation detail needed for most fixed-price contracts runs directly diametric to the low-documentation mantra of the Agile world.

Consequently, the product team and the procurement team will have to find ways to satisfy both of their needs, e.g., through creative solutions such as “fixed-price agile contracts” (e.g., a time-and-material contract with a performance-based compensation component based on individual sprint performance).

Finally, another major issue is SLAs (Service Level Agreements) and warranties. The buyer typically wants this fixed as early in the development cycle as possible (ideally as part of the contract), while the supplier will have a hard time agreeing to any SLA or warranty if the requirements are not fixed.

Impediment 4: Artificial Intelligence

While AI is quickly becoming a popular element of modern product development, there are currently no well-established methodologies for AI development. Some teams are applying methods such as CRISP-DM, KDD, or CPMAI to AI projects. However, there is not yet a well-documented and established method available that explains how to combine agile and AI. Which is not to say that it cannot be done, but the lack of proven agile methods for AI development is certainly an inhibitor for AIoT & Agile.

Impediment 5: Hardware/Embedded

Most AIoT projects require a combination of traditional (back-end) software development with some form of edge or embedded software development. In many cases, custom hardware development and manufacturing will also be a requirement.

If the edge platform is a powerful, server-like system, e.g. running Linux and C++ or even high-level languages, the difference from an Internet or enterprise software project might not be as high. However, in many cases, AIoT projects also require custom embedded software and hardware, which is a different animal all together, and many Agile principles cannot be directly applied. Embedded software is typically very technical, e.g., focusing on hardware-specific drivers or controllers, running on specialized real-time operating systems. In Addition, hardware development follows its own rules. Some differences include:

• Software in general is easier to change than hardware designs

• It is not possible to change hardware after it has been manufactured

• Higher-level hardware designs must often incorporate existing, standardized lower-level parts

• The lead times, acquisition times and feedback loops for hardware components are much longer

• Time to first full integration test with custom hardware usually significantly longer than with software

All of the above does not mean that an Agile mindset cannot be applied to embedded hardware/software development. However, an Agile embedded approach will have to take these specifics into consideration and adapt the methodology accordingly.

Impediment 6: First Time Right

Most AIoT-enabled products have some components and/or features which have to be “First Time Right”, e.g., because they will be deployed on assets in the field and cannot be easily changed afterwards. This can make it very difficult to apply agile principles: in the magic project triangle, the agile approach usually aims to fix the time and budget side of things, while the features/scope are seen as variables. For First Time Right features, this approach does not work.

Impediment 7: Functional Safety

Finally, if the AIoT-enabled product has Functional Safety requirements, this can impose another significant impediment on agility. Many Functional Safety standards are based on a “requirements first, code later” philosophy, while Agile is focused on continuous delivery of working software, but not on extensive documentation and detailed requirements management. The Agile V-Model introduced by the AIoT Framework addresses this by providing a bridge between the two worlds.

1.2 Conclusions

As seen from this discussion, adopting an end-to-end agile approach in an AIoT project or AIoT product development organization will not be straightforward. The question is - does it make sense at all? An interesting tool to get some answers to this question is the Stacey Matrix [21], which is designed to help understand and manage the factors that drive complexity in a project (Fig. 23.4).

Fig. 23.4

Stacey matrix

The Stacey matrix is based on two dimensions: uncertainty of requirements (WHAT) and uncertainty of technology (HOW). The matrix has different areas, from “simple” (high level of certainty in both dimensions) to “anarchy” (far from certain). The matrix is often used to position different methods to these areas. For example, simple tasks can be addressed by a basic processing approach. Lean methods can help optimize well-understood tasks and eliminate waste in these standardized processes. Standard project methods can be utilized up to a certain amount of complexity. After this, agile is recommended. For near-chaotic or early-stage project phases, design thinking is recommended. This might be slightly black-and-white, but you get the picture.

However, the point with many AIoT initiatives is that they will have tasks or sub-projects across the entire Stacey matrix. Take, for example, the manual labeling of one million images as input for an ML algorithm. This is a highly repetitive task with low tech and clear requirements. It seems unlikely that this task will benefit hugely from an agile approach. Or take the retrofit rollout of sensor packs to 10,000 assets in the field. Again, something with clear technical and functional requirements. On the other hand, take a “We will use AI to address xyz” statement from a management pitch. This will be in the upper right corner and again require a completely different approach.

Based on his experience as Project Management Process Owner at Bosch, Stephan Wohlfahrt has come to the following conclusions: Use Agile wisely, not only widely! Always be aware that a plan-driven or hybrid approach might be the better fit for a particular project phase or sub project.

An organization that has a lot of experience with both traditional project management and agile methods is the Project Management Institute (PMI). To address the challenges described above, the PMI has developed Disciplined Agile (DA) [22], which is a hybrid tool kit that harnesses Agile, Lean, and traditional strategies to provide the best way of working (WoW) for a team or organization. DA aims to be context-sensitive: rather than prescribing a collection of “best practices”, its goal is to teach how to choose and later evolve a fit-for-purpose “WoW”, which is the best fit in a given situation.

Scott Ambler is the Chief Scientist of Disciplined Agile at Project Management Institute. His advice on AIoT is as follows: To succeed with AIoT, or any complicated endeavor, your team requires a fit-for-purpose approach. AIoT teams address complex problems, often ones where life-critical regulations apply and where your solution involves both hardware and software development, so you must be pragmatic in how you choose your WoW. You want to be as effective as you can be, and to do that you must choose an appropriate life cycle and practices that support it. AIoT teams face a competitive market and a rapidly evolving environment, so you must improve continuously via an experimentation-based, validated-learning strategy. Unlike agile frameworks that prescribe a collection of “best practices” DA instead teaches you how to choose the practices that are best for you – DA helps you to get better at getting better. You want your teams to work in a manner that is best for them, which implies that all of your teams will work differently and will constantly evolve how they work.

The following introduces the Agile V-Model, which is a combination of agile practices and the V-Model, designed to specifically address many of the challenges discussed before. Since the Agile V-Model focuses on the project/product level, it can be combined with enterprise practices such as DA.

2 Agile AIoT Organization (Fig. 23.5)

The AIoT product organization must combine scaled agile methods with those methods that are better suited to address the aforementioned impediments to agility. As outlined in the book The Connected Company [23], companies which successfully address the fast speed of technical innovation must be more like complex, dynamic systems that can learn and adapt over time. The following provides an overview of how the Digital Playbook suggests addressing agility in the context of AIoT.

Fig. 23.5

Agile AIoT organization

2.1 Industry Best Practices

Many of the Cloud hyper-scalers have adopted best practices for customer-centric, agile product innovation. There are many examples from companies like Apple, Google, and Amazon. Some of the core elements of these best practices include a culture which is open for innovation, agile organizational structures and effective support mechanisms.

The organizational culture of these organizations is often described as being centered around a strong - if not obsessive - customer focus. Empowerment of employees with a strong “builder” mentality also plays an important role. Another point is calculated risk taking, which often goes hand-in-hand with a “fail early, fail often” mentality. Especially the latter is a point which is often very difficult to handle for companies with an industrial or manufacturing focus.

Another point are organizational structures which support agility. Again, often a weak point of large, industrial incumbents. Companies like Amazon are promoting small, empowered teams. The term „2 Pizza Team" was coined by Jeff Bezos himself - referring to the fact that a team should not include more people than can be fed by 2 pizzas. Another important point is single threaded ownership. This means that leaders should be able to focus 100% on a single deliverable - without having to worry about dependencies to other parts or the organization. This comes along with decentral decision making: Avoiding large decision-making bodies as they are known from many industrial incumbents, and instead empowering the teams and product owners.

These agile organizational structures must be supported by effective mechanisms. Again, looking at an Amazon example, which is the “Working backwards” process. In this process, the team starts with creating a press release which describes the outcome from the end customer’s perspective, including information about the problem, how current solutions are failing, and why the new product will solve this problem. Other methods include Design Thinking, Lean UX and Customer Journey Mapping.

Finally, the agile organization must be supported by an architecture which is flexible and scalable to support growth and change. For many cloud organizations, this means a clear focus on microservices with well-defined APIs as the only means for access. In addition, these services must be made available as self-service platforms, to ensure scalability without depending on human administrators or gatekeepers. For many organizations which are not cloud-native, this is also an issue. Furthermore, combining hardware with software in AIoT-enabled products or solutions can also make it very hard to find flexible and easily changeable architectures (Fig. 23.6).

Fig. 23.6

Industry best practices

2.2 Scaled Agile Organizations and AIoT

There are a number of different agile frameworks designed to address the issue of scaling agile to a level where it can support larger organizations and multiple teams with complex dependencies. Examples include SAFe (the Scaled Agile Framework) and Less (Large Scale Scrum). The basic idea of most of these scaled agile approaches is to establish a leadership team that usually consists of a lead architect, a product manager (or chief product owner), and an engineering lead. Together, they help orchestrate the work by agile teams, which usually work relatively independently within a loosely coupled, agile organization.

This approach makes sense in general and is followed by the AIoT framework. To address the specifics of AIoT, two additions are made:

• A dedicated product coordinator is added to the leadership team. This role will be responsible for ensuring that all dependencies are properly managed, both internally and externally.

• Two types of agile teams are introduced: Feature Teams and AIoT Technical Workstreams. The Feature Teams take end-to-end responsibility for functional features, and the Technical Workstreams provide the foundations. Sometimes the Technical Workstreams are the home for experts with different technical skills (cloud, edge, mobile apps, etc.), which are then assigned to different Feature Teams, depending on the demand.

Figure 23.7 shows the difference between a standard Scaled Agile Organization and the Agile AIoT Product Organization.

Fig. 23.7

Scaled agile organization vs AIoT organization

2.3 Feature Teams Versus Technical Workstreams

An AIoT product usually requires a technical infrastructure that includes cloud and edge capabilities, IoT communication services, and an AIoT DevOps infrastructure. In addition, many cross-cutting topics, such as end-to-end security, OTA (Over-the-Air Updates), etc. must be addressed. This is what the AIoT Technical Workstreams will need to provide and maintain.

The Feature Teams are then responsible for building end-to-end functionality based on the technical infrastructure. For this to occur in a coordinated way, the product manager must work closely with the product owners of the different feature teams (to map the end-to-end epics from the story maps to user stories that are managed in the backlogs of the different feature teams). The lead architect must ensure that the different feature teams contribute to a consistent end-to-end architecture. The product coordinator, the engineering lead, and the different product owners should collaborate to manage key dependencies and meet global milestones (Fig. 23.8).

Fig. 23.8

AIoT feature teams vs. technical workstreams

2.4 Minimum Viable Teams

When setting up a new team — whether a feature team or a technical workstream — a key question is how to staff it. This is why the concept of the Minimum Viable Team (MVT) is so important. The purpose of the MVT is to make the initial team as lean as possible, and allow the core team to pull in additional resources when needed.

Always keep in mind Conway’s Law, which describes the phenomenon where the organizational structure becomes the blueprint for the architectural structure. For example, if you have a database expert on the team the final design will probably include a database, regardless of whether one is needed or not. As soon as organizations decide who will be on the team, they are in effect designing the system.

This can be addressed by the concept of the MVT. The only caveat is that (especially in larger organizations) it can be difficult to obtain additional resources on demand. This is the reason many team leads have a tendency to acquire resources when the opportunity arises.

2.5 Leadership Roles

The following describes the key leadership roles in the Agile AIoT Product Organization: AIoT Product Manager, AIoT Product Engineering Lead, AIoT Product Architect, and AIoT Product Coordinator.

AIoT Product Manager

Product Management for smart, connected products can build on existing good practices, which are summarized in Fig. 23.9.

Fig. 23.9

Product management

AIoT Product Engineering Lead

The Product Engineering Lead is effectively responsible for ensuring that the different AIoT product teams are together continuously delivering integrated product increments. Depending on the chosen setup — loosely coupled teams or a more hierarchical organization — they will directly or indirectly coordinate and orchestrate the delivery of the product increments.

Some of the key tasks include:

• Management of end-to-end product engineering roadmap

• Alignment of product vision with product roadmap and backlogs

• Facilitation of cross-team planning events

• Oversee continuous delivery pipeline and efficient AIoT DevOps - covering edge and cloud, as well as code and AI models

• Coordination/support of technology and resource acquisition

• Escalation and tracking of road-blockers

• Ensure UX principles are followed

• Ensure establishment of Quality Management - including QM for the AI-elements of the system

• Creation and tracking of key engineering metrics - including metrics for the AI-part of the system

• Coaching and guiding the engineering staff - ensuring that hardware development, traditional software development and AI-development are working hand in hand

• Collaboration with a product coordinator on dependency management, risk management, and cost management

AIoT Product Architect

The AIoT Product Architect must define and maintain the end-to-end architecture and design of the product. They must work closely with the different AIoT development teams and other key stakeholders, focusing only on architectural decisions that are of relevance from a cross-team perspective. Architectural decisions that have no impact outside of an individual team should be made by the team itself.

It is important to note that the AIoT Framework does not propose an excessive, RUP/waterfall-style model depth, as can be seen when looking at the individual templates. The general scheme of collaboration between the different project stakeholders in the architecture management process is shown in Fig. 23.10.

Fig. 23.10

AIoT solution architecture process

The key to success is to keep the AIoT Solution Architecture on a level of detail where it is meaningful, but not overly complex. The agile teams must be able to apply their own mechanism (e.g., demand-driven design spikes) to derive requirements for their backlog and provide feedback to the overarching architecture in return.

AIoT Product Coordinator

To support the Product Manager, Engineering Lead and Product Architect in their work, AIoT recommends installing an overall Product Coordinator in a back office management role. The key tasks of this coordinator are summarized in Fig. 23.11.

Fig. 23.11

AIoT project management

PMI PMBOK provides a good description of the different knowledge areas that a product coordinator must be able to support.

3 Agile V-Model (Fig. 23.12)

The V-Model is a software development method often found in areas with high requirements on safety and security, which are common in highly regulated areas. Combining the traditional V-Model with a disciplined agile approach promises to allow as much agility as possible, while addressing the issues often found in AIoT initiatives: complex dependencies, different speeds of development, and the “first time right” requirements of those parts of the system which cannot be updated after the Start of Production (SOP).

Fig. 23.12

1.0 Agile V-Model.png

3.1 Recap: The V-Model

The V-model is a systems development lifecycle which has verification and validation “built in”. It is often used for the development of mission critical systems, e.g., in automotive, aviation, energy and military applications. It also tends to be used in hardware-centric domains. Not surprisingly, the V-model uses a v-shaped visual representation, where the left side of the “V” represents the decomposition of requirements, as well as the creation of system specifications (“definition and decomposition”). The right side of the “V” represents the integration and testing of components. Moving up on the right side, testing usually starts with the basic verification (e.g., unit tests, then integration tests), followed by validation (e.g., user acceptance tests) (Fig. 23.13).

Fig. 23.13

V-Model

When applying the V-model to AIoT, it needs to take different dimensions into consideration; usually including hardware, software, AI, and networking. In addition to the standard verification tests (unit tests, integration tests) and validation tests (user acceptance and usability tests), the V-model for AIoT also needs to address interoperability testing, performance testing, scalability testing and reliability testing. The highly distributed nature of AIoT systems will pose specific challenges here.

Test automation is key to ensure a high level of test efficiency and test coverage. On the software side, there are many tools and techniques available to support this. In the AI-world, these kinds of tools and techniques are only just beginning to emerge, which makes it likely that a more custom approach will be required. In the embedded and hardware world, simulation techniques such as Hardware-in-the-Loop (HIL), Software-in-the-Loop (SIL) and Model-in-the-Loop (MIL) are well established. However, most AIoT products will also require testing of the actual physical product and how well they perform in the field in different types of environments. Again, this will be a challenge, and some ingenuity will be required to automate testing of physical products wherever possible.

3.2 Evolution: The Agile V-Model

The AIoT framework aims to strike a good balance between the agile software world and the less agile world of often safety-critical, complex and large(r)-scale AIoT product development with hardware and potentially manufacturing elements. Therefore, it is important to understand how an agile method works well together with a V + V-centric approach such as the V-model. The logical consequence is the Agile V-model. Combining agile development with the V-model is not a contradiction. They can both work very well together, as shown in the figure following:

• Agile methods use story maps including epics, themes, features and user stories for logical decomposition. This maps well to the left side of the V

• Continuous Integration / Continuous Test / Continuous Delivery are inherently agile methods, that map well to the right side of the V

• The key assumption is that the V-model is not used like one large waterfall approach. Instead, the Agile V-model must ensure that the sprints themselves will become Vs according to the V-model (Fig. 23.14)

There are two options to implement the latter:

• Each sprint becomes a complete V, including development and integration/test

• The agile schedule introduces the concept of dedicated integration sprints.

• One V becomes 2 sprints: one development sprint, one integration sprint

• There are pros and cons to both approaches

• The complexity and scale of the project will surely play a role in determining the best setup

For most projects / product teams, it is recommended that development and integration are combined in a single sprint (“v-sprint”). Only for projects with a very high level of complexity and dependencies, e.g., between components developed by different organizations, is it recommended to alternate between development and integration sprints. The latter approach is likely to add inefficiencies to the development process, but could be the only approach to effectively deal with alignment across organizational boundaries.

Fig. 23.14

Agile V Model

3.3 The ACME:Vac Vacuum Robot Example

To illustrate the use of the Agile V-Model, the realistic yet fictitious ACME:Vac example is introduced. This is a robot vacuum cleaning system that combines a smart, connected vacuum robot with a cloud-based back end, as well as a smart app for control.

Modern robot vacuum cleaners are very intelligent, connected products. Even the most basic versions provide collision, wheel, brush and cliff sensors. More advanced versions use visual sensors combined with a VSLAM algorithm (Visual Simultaneous Location and Mapping). The optical system can identify landmarks on the ceiling, as well as judge the distance between walls. The most advanced systems utilize LIDAR technology (Light Detection and Ranging) to map out their environment, identify room layouts and obstacles, and serve as input for computing efficient routes and cleaning methods. For example, the robot can decide to make a detour vs. switching into the built-in “climb over obstacle”-mode. Another example is the automatic activation of a “carpet boost” mode. IoT-connectivity to the cloud enables integration with user interface technology such as smart mobile devices or smart home appliances for voice control (“clean under the dining room table”). Edge AI algorithms deployed on the robot are used to control these processes in advanced models. A complete design of the ACME:Vac is provided in the Product / Solution Design section (Fig. 23.15).

Fig. 23.15

Example: robot vacuum cleaner

3.4 Applying the Agile V-Model to ACME:Vac

The following provides a description of how the ACME:Vac example is developed using the Agile V-Model. This discussion will start with a look at a “Sprint 0”, where the foundations are laid. Then a “Sprint n” is discussed in detail, with an outlook on the transition to the next sprint (“Sprint n+”).

Sprint 0

Many scrum masters are starting their projects with a “Sprint 0” as a preparation sprint to initiate the project (ignoring the quasi-religious discussion whether this is a good practice or a "cardinal sin" for the moment, since we have to start somewhere...). In the case of ACME:Vac, two working results arise: the initial story map and the initial component architecture. These will be important elements for the planning of the subsequent sprints (Fig. 23.16).

Fig. 23.16

Sprint Zero

Initial Story Map

According to the story map structure proposed by the AIoT Framework, the story map for the vacuum robot system includes epics and features on the top level. The epics include Human/Machine Interfaces, the actual cleaning functions, management of the maps for the areas to be cleaned, navigation/sensing, system configuration, and status/history (Fig. 23.17).

Fig. 23.17

Example: initial story map

Initial Component Architecture

The Component Architecture for the ACME:Vac highlights the key functional components in three clusters: the robot itself (Edge), the cloud back end, and the smartphone app. On the robot, two embedded components provide control over the robot functions, as well as access to the sensor data. Higher-level components include the control of the robot movements (based on AI/ML, potentially with a dedicated hardware), the robot configuration, as well as remote access to the robot APIs. The cloud services include basic services for managing map data, status/history data, as well as user and robot configuration data. The robot control component enables remote access to the robot. Finally, the smart phone/mobile app provides components for robot configuration and map management, all accessible via the main screen of the app (Fig. 23.18).

Fig. 23.18

Example: initial component architecture

Note that — in line with the agile “working code over documentation” philosophy — the component architecture documentation does not need to be very detailed. Only the main functional components are listed here. Depending on the project, usage dependencies can be added if such levels of detail are deemed relevant and the maintenance of the information is realistic.

Sprint n

Next, we want to jump right into the middle of the ACME:Vac development by fast-forwarding to a “Sprint n”, which will focus on a single feature to illustrate the approach in general (Fig. 23.19).

Fig. 23.19

Agile V-Model

The example will show how a sprint is executed in the agile V-Model, including:

User Story & Acceptance Criteria

In this example, we are focusing on the ACME:Vac Epic “Configuration”. This includes features such as “Cleaning Mode” (e.g. silent, standard, or power mode), “Cleaning Schedule Management”, “User Account Management”, “WiFi Configuration”, as well as “Software Update Management”. The Definition of Done provides higher level acceptance criteria.

In our example we focus on the “Cleaning Mode” feature. This contains a Use Story “change cleaning mode”, including some acceptance criteria specific to this user story. The intention is that the user can select different cleaning modes via his smart phone app, which will then be supported by both the ad-hoc as well as the scheduled cleaning modes (Fig. 23.20).

Fig. 23.20

Example user story

Mapping User Story to Components and Feature Team

Having defined the user story, the next step is to identify which components are required for the story. The “Change Cleaning Mode” story will require a robot configuration component on the smartphone. This will need to interact with the robot configuration component in the cloud. In order to record the change, an interaction with the status / history component is required. Finally, the remote service component on the robot will receive the selected mode, and configure the robot accordingly (Fig. 23.21).

Fig. 23.21

Mapping user story to components and feature team

Based on the analysis of the functional components, the required members of the feature team for this user story can be identified. They include a domain expert, an embedded developer for the components on the robot, a cloud developer, a mobile app developer, and an integration/test expert. Note that some organizations strive to employ full-stack developers. However, in this case it seems unlikely that a single developer will have all the required skills.

Implementation and CI/CT/CD

Implementation in an AIoT initiative can include many components, including software development, AI/ML development, data management, HW design and engineering, or even manufacturing setup. The various tasks often have to be executed at different development speeds, e.g., because hardware is usually not evolving as fast as software. Because of this, it might not always be possible to create a potentially shippable product increment. The Agile V-Model recommends that if this is a case, at least mockup implementations of the public interfaces should be provided for integration testing.

Each sprint needs to fully support Continuous Integration, Continuous Testing and Continuous Deployment (CI/CT/CD), with the limitations just discussed in mind. A key element of CI is component integration, which usually should be done with a focus on different user stories, i.e., it should focus on integrating and testing the set of components required for a particular user story. This often means that these components are embedded into an environment which simulates auxiliary components and/or production data. This should be handled automatically by the CI (Continuous Integration) infrastructure.

If the component integration including tests was successful, the components can be integrated into the entire system. This means integrating all components which are changed or created by the current sprint need to be integrated in order to create the next, potentially shippable increment of the system.

Verification & Validation

For some people in the agile community, Verification & Validation (V&V) is considered to be an outdated concept, while for many people with an enterprise and/or functional safety background, it is good practice. The Agile V-Model aims for a pragmatic view on this. Componentization (see the Divide & Conquer section) must support an approach where functional components with different levels of QM/functional safety requirements are separated accordingly, so that the most suitable V&V approaches can be applied individually.

Traditionally, validation is supposed to answer the question “Are we building the right product?”, while verification focuses on “Are we building the product right?”, even though the boundary between these questions can be blurry.

In the Agile V-Model, verification differentiates between the micro and the macro-level. The micro-level is defined by the Acceptance Criteria of the individual user stories, while the macro-level is focusing on the Definition of Done, which usually applies across individual user stories. Validation, on the other hand, focuses on user acceptance. In AIoT, this can involve quite laborious lab and field tests (Fig. 23.22).

Fig. 23.22

V&V details – explanation

Sprint n + 1

At the end of a sprint, the sprint retrospective should summarize any key findings from the sprint’s V&V tasks that need to be carried over to the next sprint. For example, findings during User Acceptance Tests might require a change to a user story. Or a feature team might have decided on an ad hoc change to the planned component architecture. These kinds of findings must either be reflected by changes to the backlog (for user story definitions), or by updating the architecture plans and documentation.

Summary

In summary, the Agile V-Model is designed to support the adoption of agile practices in an AIoT environment, where we usually find some significant inhibitors of a “pure” agile approach. Each v-sprint combines a normal, agile sprint with a sprint-specific planning element. This allows us to address the complexities inherent to most AIoT initiatives, as well as the typical V&V requirements often found in AIoT.

At the end of each sprint, the sprint results must be compared to the original sprint goals. Story maps and component landscapes must be adapted according to the results of this process. The updated version then serves as input to the planning of the next sprint (Fig. 23.23).

Fig. 23.23

Verification and validation – details

3.5 Decoupling Development

To master the complexity of an AIoT product or solution, it is important to apply an effective “Divide & Conquer” strategy. This requires decoupling both on the development and on the technical level. In order to decouple the development, an interface-first strategy must be implemented. This will allow for the development and testing of components independently of each other, until they have reached a level of maturity so that they can be fully integrated and tested.

This will also be especially important in AIoT because it will not always be possible to test all components in the context of the full system. This is why many AIoT developments utilize different test simulation approaches. These can range from simple interface simulations (e.g., via REST tools) to sophisticated virtual simulations (e.g., allowing us to test an algorithm for autonomous driving in a virtual world). Since field tests can be time-consuming and expensive, this is important in AIoT (Fig. 23.24).

Fig. 23.24

Decoupling development

3.6 Stakeholders and Collaboration

The Agile V-Model aims to support collaboration between different stakeholders who are involved in the execution. Very often, this will involve cross-company collaboration, e.g., if certain parts of the AIoT system are developed by different companies. It is important to think about which tools should be used for efficient stakeholder collaboration, both within individual stakeholder groups and between them. The figure following provides some examples. Finally, on the technical level it is important to note that the Agile V-Model must support the different AIoT pipelines, as introduced earlier (Fig. 23.25).

Fig. 23.25

Agile V-Model: stakeholders and toolchain

3.7 Agile V-Model and AIoT

Finally, this discussion should conclude by mentioning what is probably the biggest difference between a “normal” software project and an AIoT project: the Start of Production, or SOP. This is the point in time when mass production of the smart, connected products is starting, and they are leaving the factory to be deployed in the field. Alternatively, the start of the roll-out of retrofitting the AIoT solution to existing assets in the field. Any required changes to the hardware configuration of the product or solution will now be extremely difficult to achieve (usually involving costly product recalls, which nobody wants). In a world where manufacturers want to utilize the AIoT to constantly stay in contact with their products after they have reached the customer, and provide the customer with new digital services and applications — rolled out via OTA — it becomes extremely important to understand that the V&V process does not stop with the SOP, at least not for anything that is software. With software -defined vehicles, software-defined robots, and software-defined everything, this is quickly becoming the new normal (Fig. 23.26).

Fig. 23.26

Agile V-Model and SOP

3.8 Issues and Concerns

The proposed Agile V-Model approach has provoked intense discussions between advocates of the different worlds. Some of the arguments against the approach have been captured in Fig. 23.27. Some comments and counterarguments are included as well. We hope that the discussion will continue, and we will be able to capture more pros and cons (Fig. 23.27).

Fig. 23.27

Issues and concerns regarding the Agile V-Model

3.9 Expert Opinion

Sebastian Helbeck is a VP and Platform Owner Power Tools Drive Train at Bosch Power Tools. The following his summarizes his thoughts on this topic.

• Dirk Slama: Do you see the agile world (cloud, etc.) and the waterfall world (e.g., embedded) currently working well together? What are the issues?

• Sebastian Helbeck: What I am seeing is that many projects are currently developed parallel in these two worlds. This is based on the fact that in many cases either the embedded or the non-embedded part already exists, and the other part needs to be developed. In the future this needs to be done more seamlessly.

• DS: How much do these worlds need about each other, and how can we ensure this?

• SH: Currently everybody is focusing on understanding and fulfilling their own contributions and the interfaces around. In the future, the interfaces will change and will be even more complex. Edge computing will be a key driver here. Consequently, we need to have better knowledge about our own contributions and how they relate to the other side. As an analogy, FPGA technology can be used, which has tremendously changed the interfaces between HW and embedded SW.

• DS: Can the different methods coexist, or do we need a common approach?

• SH: Currently, they coexist and it works, but it is not ideal. This is why as the next step, we need to bring the different approaches closer together due to the different maturities of the product parts. To unleash the full power of AIoT, we need to rethink this and have to adopt a more holistic approach.

• DS: Which role can the Agile V-Model play here?

• SH: It can potentially play an important role here. It will combine the two worlds with a holistic view to give all the included stakeholders a transparent overview of the complete system. For the future, we might need to think about a new name since the combination of the worlds will bring us to a new dimension of understanding of our AIoT systems.