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 , 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.
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.
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.
The diagram following shows the difference between a standard Scaled Agile Organization and the Agile AIoT Product Organization.
Feature Teams vs. 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.
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.
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 the following figure.
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 the following figure.
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 the following figure.
PMI PMBOK provides a good description of the different knowledge areas that a product coordinator must be able to support.
- The Connected Company, Dave Gray, Thomas Vander Wal, O'Reilly Media, Inc., 2012