Agile AIoT Organization: Difference between revisions

No edit summary
Line 83: Line 83:


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


It is important to notice that the AIoT Framework is not proposing an excessive, RUP/waterfall-style model depth, as can be seen when looking at the individual templates. The general idea of collaboration between the different project stakeholders in the architecture management process is shown in the figure below.
It is important to notice that the AIoT Framework is not proposing an excessive, RUP/waterfall-style model depth, as can be seen when looking at the individual templates. The general idea of collaboration between the different project stakeholders in the architecture management process is shown in the figure below.

Revision as of 23:07, 18 August 2021

More...More...More...More...More...More...More...More...More...More...More...More...More...More...Agile AIoT Organization

AIoT Product Organization

The AIoT product organization must combine scaled agile methods with methods which are better suited to address the aforementioned impediments to agility. The following provides an overview of how this can be addressed.

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 which usually consists of a lead architect, a product manager (or chief product owner), and an engineering lead. Together, they help orchestrating the work by the agile teams, which usually work relatively independently within a loosely coupled, agile organization.

This approach in general makes sense, and is followed by the AIoT framework. In order 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 - between internally as well as 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, which 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 below shows the difference between a standard Scaled Agile Organization and the Agile AIoT Product Organization.

Scaled Agile Organization vs AIoT Organization

Feature Teams vs. Technical Workstreams

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

The Feature Teams are then responsible for building end-to-end functionality based on the technical infrastructure. For this to happen in a coordinated way, the product manager has to 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 which are managed in the backlogs of the different feature teams. The lead architect has to ensure that the different feature teams are contributing to a consistent end-to-end architecture. Product coordinator, the engineering lead, and the different product owners have to collaborate to manage key dependencies and meet global milestones.

AIoT Feature Teams vs Technical Workstreams

Minimum Viable Teams

When setting up a new team - be it a feature team or a technical workstream - a key question is how to staff the team. This is where the idea of the Minimum Viable Team (MVT) is important. The idea of the MVT is to make the initial team as lean as possible, and allow the core team to pull additional resources when needed.

Always keep in mind Conway's Law, which describes the phenomenon where the organization 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 get additional resources on demand. Which is why many team leads have a tendency to acquire resources when the opportunity is there.

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

The Product Management for smart, connected product can build on existing good practices, which are summarized in the figure below.

Product Management

AIoT Product Engineering Lead

The Product Engineering Lead is effectively responsible for ensuring that the different AIoT product teams together are continuously delivering integrated product increments. Depending on the chosen setup - loosely coupled teams or a more hierarchical organization - he 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 DevOps
  • Coordination / support of technology and resource acquisition
  • Escalation and tracking of road-blockers
  • Ensure UX principles are followed
  • Ensure establishment of Quality Management
  • Creation and tracking of key engineering metrics
  • Coaching and guiding the engineering staff
  • Collaborate with product coordinator on dependency management, risk management, cost management

AIoT Product Architect

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

It is important to notice that the AIoT Framework is not proposing an excessive, RUP/waterfall-style model depth, as can be seen when looking at the individual templates. The general idea of collaboration between the different project stakeholders in the architecture management process is shown in the figure below.

AIoT Solution Architecture Process

The key to success here 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

In order to support the Product Manager, Engineering Lead and Product Architect in their work, AIoT recommends to install an overall Product Coordinator in a backoffice management type of role. The key tasks of this coordinator are summarized in the figure below.

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

AIoT Project Management