- 1 Agility vs. AIoT: Impediments
- 2 Conclusions
- 3 References
Agility vs. 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.
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.
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 diametral 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.
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, which is designed to help understand and manage the factors that drive complexity in a project.
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 sightly 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 1 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), 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.
- Strategic management and organisational dynamics: the challenge of complexity. 3rd ed., Stacey RD., Prentice Hall, 2002
- Disciplined Agile, https://pmi.org/disciplined-agile
Authors and Contributors