Agile Coaching

Agile Coaching

October 25, 2017 Agile 0

Today I want to write a bit about Agility in Business. During the last few years I’ve experienced various mature and immature forms of it and it always stood out to me how people perceived what it meant to be “Agile”.

To start off, agility is just a type of value supply chain. I’ve explained this more in-depth in a previous post. In its most basic form, it’s nothing more than saying “Instead of checking with Stakeholder in at the end of the project, let’s do it every two weeks and adjust according to what they find most valuable.”

The complexity lies in implementing these shortened feedback loops in a large corporate environment without it degrading into uncoordinated chaos. This feeling of chaos is often why people “don’t understand” agile. It’s the job of the Agile-coach to convince the business that “being agile” is not a nearly mythical “mode of being” that is near impossible to ever get right but a clearly defined structure that can be implemented in a repeatable fashion.

The Agile Coach achieves an Agile transformation by identifying and breaking down the value chains of the business into sections. Like a factory line, the first section will take raw materials and provide a fully independent, working product. Any subsequent section can decide to take that product and build their own product on op of it. This continues all the way until it reaches the client.

In return, each team that uses a product becomes the customer of the previous section and has a say on how the product should develop. The teams Product Owner then decides which items have highest priority and therefore should be included. This feedback loop repeats every two weeks to ensure that only the most valuable items are included.

So, by continuously looking at the most valuable course of action (and promoting it via coaching) the Agile-coach creates an environment that’s highly-suited for iteration-based progress. Since all agile transformations lead to the same end-result (capacity for high variety, but low volume), all agile transformations can follow roughly the same roadmap.


The Roadmap

The Agile Roadmap consists out of the following sections:

  • Setting a Goal
  • Analyzing the Environment
  • Establishing Order
  • Starting transformation
  • Guiding Transformation
  • Closing transformation

If you’re unfamilliar with any terms, check out my post “Agile, Scrum, Jira”


Set Goal

Before we can start, we need to set a goal.

  • Does agility actually fit with your business situation?
  • Do you have any value chain management issues?
  • Do you have the correct, high variety/low volume product for agility?
  • What are the desired end results?


Analyze Environment

Once you’ve decided that agility is a good fit for the organization, you can start analyzing the environment.

  • Who do you have to work with?
  • What are the value chains?
    • Goal of value chain
    • Details of value chain
    • Why is this value chain important to the company
    • How much is this value chain worth?
  • Do you understand the overall business strategy?
  • Which KPI’s are needed by management?
  • Are the decision-makers on-board?


Prepare for Transformation

The goal of this section is to establish what the end-result of the transformation will be. The idea is that once you’ve hammered out how exactly you want the teams to act during and after the transformation, you’ll end up with a checklist of achieved and not-yet-achieved items.


Self-Sufficient Squads

Creating self-sufficient squads are the cornerstone of agility as they will be the sole owner of the numerous sections in the value chain. If working Scrum, self-sufficient would mean that the team has a Product Owner and a Scrum Master present. This unit is then able to independently decide what to do based on customer input


  • Are the teams in place?  (If not, identify teams)
  • Does each team have a goal?
  • Does each team own a section of the value chain?
  • Does each team have a SM, PO, Dev? (if not, Get Scrum Master & Product Owner per DevOps)

More about teams can be found in my post “Creating a Team”


  • Are all facilities in place?
  • Are there enough rooms, tables, chairs, pc’s


I believe identity is an important part for each DevOps Team. It allows the team to be proud in their section and it gives clarity in the organization regarding who is doing what. You can print all this information on an A3 Poster and post it somewhere public.

  • Does every team have a teamname
  • Is the value chain & end-product clear?
  • What are the teams values?
  • What is the teams contact info?


Establish One Way of Working

A One Way of Working allows team-members to switch from one team to another with relative ease. It involves T-Shaping, best practices and common frameworks such as Scrum.



Metrics provide an easy overview for decision-makers.

  • Metrics for Teams
  • Metrics for Product Owners
  • Metrics for Stakeholders
  • Metrics for Managent

For example, you can set KPI’s via Jira for Management and Stakeholders. Furthermore, in the case of DevOps, these metrics should include uptime, latency, storage, time-to-deploy, testing


Communication Plan

How do you want to communicate these changes in the environment?

  • Publicize One-Way-Of-Working and Jira Standards
  • Create Sticky Wall in Public room
  • Publicize Transformation Roadmap
  • Kick-off Scrum Teams & create first Scrum Board



What is the baseline tooling required for each team?



Plan and prepare workshops for the new Scrum Masters and Product Owners so that teams can start quickly


Establish Order

After analyzing the environment, you can begin. First off, you need to create a strict sense of order in the environment.  You do this by creating a “Strategy Room” (preferably in a public place). This room will host the wall on which you keep track of the latest information on a per-team basis.

The Wall

Team 1 Team 2 Team 3 Team …
  • Scrum Master
  • Product Owner
  • Team (DevOps)
  • Facilities
  • Coach
  • Management Introduction
  • PO Trained? (Basic, Advanced)
  • SM Trained? (Basic, Advanced)
  • Team Trained? (Basic, Advanced)
  • Jira Metamodel Implemented?
  • Dev Tool (Jira) Implemented?
  • Ops Tool (Topdesk, Gitlab Issues, Email) Implemented?
  • First Definition of Done?
  • Burndown Chart?
  • Product Backlog?
  • Scrum Maturity Scan?
  • 2 weeks rhythm?
  • Definition of Ready done?
  • T-Shape Profile?
  • Use Basic Target Tools?
  • Build Automation?
  • Deployment Automation?
  • Test Automation?


Start Transformation

Time to implement the Roadmap! Now it’s time for the Agile Coach to kick-off the meetings, workshops, conversations and remain active for any value-improvements that will pop up. Keep track of the transformation on The Wall!