Managing agile from technology to business

 This how I tend to look at management ownership in agile development (see previous blog entry for more on the alternate views of agile):

Where:

• The CTO owns technology and most often engineering teams.
• The Engineering Manager may be an inwards looking CTO and also own technology and engineering teams, but is often less owning technology and more owning agile processes and engineering teams.
• The Product Owner owns the team's product vision and possibly the customer strategy. She/he is a member of the development team or has a representative that is part of the development team.
• The Technical Product Owner owns the customer view of technology, may be a full fledged product owner, or may be a support member of a larger product owner team.

Individuals become more and more key enablers as your product and technology base become more advanced. A Servant Leader is then a manager (e.g. engineering manager) that helps individuals contribute in independence yet within orchestrated flows. This figure illustrates where the servant leader provides critical guidance (the red corners!):

Here, from the central diagonal outwards:

• The team iterates a technology and product development and review cycle, again, and again.
• In parallel, the team learns and explores productivity and innovation. Product does the same with their customers and market segment.
• Productivity issues are monitored. In a physical model of agile processes 'high momentum' is high productivity. Servant Leaders help monitor for issues such as unsustainability, diverging focus, low or over capacity, and help teams and product avoid or resolve these issues.

 My experience is:

• Product Owner and CTO have too much "skin in the game" to be effective servant leaders. Therefore engineering managers and technical product owners (when they have only partial ownership) have a critical servant leader role to play to help all deliver better.

All original content copyright James Litsios, 2022.

Agile from business to technology

This is how I scale agile towards business and towards technology.:

Where:

• In the center we have an agile process that blends team process and product process.
• To the right we have a business process that ties into the product process.
• To the left we have a technology process (expertise process to be general) that ties into the team process.

To be honest, this is my minimal theoretical business to technology agile process. In practice, a specific agile process is chosen, with process steps and process artefacts. People like to say that agile is about people, not process. Yet people need to communicate, and the common vocabulary for that is given by a process.

Deepening in to the product business view (right side above):

Where:

• The core agile process (blue) delivers features and deliverables that are part of a product and business goals.
• These deliverables are picked-up by customers
• The features and deliverable sustain (or not) the customers competitivity within its market segment
• The product owner (in scrum terminology) is the expert that guides the product with regards to the customer needs.

We can do that also for technology/engineering (left above):

Where:

• The core agile process (blue) includes experts within the team.
• The experts enable/produce the technical/engineering needs of the features and deliverables.
• The expert individuals may be experts in different domains.
• Coordinating technology/engineering frameworks allow experts to work both as individuals and in coordination (within their team).

Many domains of technical expertise are possible. Above are the ones closer to my experience.

Note:

• The complete process above needs to coordinate at least SIX streams.
  A minimal agile process only presents three streams (team vs product vs customer). 
• Each of these (six) streams will naturally be driven at their own different rate!
• Your job, as CTO / engineering lead is to work with individuals, teams and product to pace work within these different streams to achieve an optimal throughput!
•  Think laminar flow! Productive is as fast as you can go before things become turbulent!

I wrote this up as a (much longer) slide deck, and am always happy to share my experiences!

All original content copyright James Litsios, 2022.