More...More...More...More...More...Hardware.exeMore...More...More...More...More...More...More...More...Agile AIoT Organization

AIoT Product Organization

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

TBD: Reference to https://www.oreilly.com/library/view/the-connected-company/9781449336622/

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 orchestrate the work by the 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. 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; both 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, 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.

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 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 which are managed in the backlogs of the different feature teams). The lead architect must ensure that the different feature teams are contributing 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.

AIoT Feature Teams vs Technical Workstreams

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 get additional resources on demand. This is the reason many team leads have a tendency of acquiring resources when the opportunity arises.

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 following.

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 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, 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 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 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 figure following.

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

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 back office management type of role. The key tasks of this coordinator are summarized in the figure following.

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

AIoT Project Management

References

Cite error: <ref> tag with name "concomp" defined in <references> has group attribute "" which does not appear in prior text.