How to structure your agile coaching
The Agile Coaching Backlog
A practical guide on preparing midterm interventions as an Agile Coach
Since agile coaching still is a profession under development people all over the world having this role are constantly figuring out how to best organize one’s working approach. As far as I can tell there is no one-size-fits-all that suits everyone out there. We can perceive that the personal traits and types of personality heavily influence the way Agile Coaches prepare and organize themselves. So let me put my way of doing it into the mix.
This blog post covers how I and some of my colleagues organize and prepare their work as an Agile Coach. But be aware, I consider myself being rather ‘well-organized’ and in love with work supporting structures as you can tell by this blog post. So this description might not suit your working style.
Focus on deliberate actions and close collaboration
Before I can dive into the nitty-gritty details of my Agile Coach backlog I need to put some words of context upfront. The Agile Coaches’ intention at idealo is to strengthen and support the people in charge. We aim for high-aptitude professionals that can use agile principles and practices to create the best product and outstanding user experience. Our way of Agile Coaches primarily targets the enabling whenever this is appropriate given the challenges and the level of experience at hand. This has a significant impact on the way we structure our work. By default we don’t offer the full-service ‘agile babysitter’ support which usually comes along with a high load of ‘team-maintenance’. Instead we take deliberate actions to increase the capabilities of teams, organizations, and individuals to cope with the challenges in an uncertain environment of product development at a high pace. We want to step out of the rat race of agile busy work as often as possible. A sound Agile Coach backlog with a deliberate intention and clear actions helps to achieve this most of the time.
The actions to be taken may result from suggestions by the Agile Coach itself, as a solution experiment to an identified problem by the team, a challenge of the organization’s Head Ofs, or a mix of all. Every deliberate action aims at a certain goal that is usually defined together with the team and the organization’s management. Moreover, Agile Coaches at idealo do pair coaching for a decent amount of time which helps to come up with effective actions to be taken.
The facets of deliberate action may stem from one of the following competencies:
- Agile-Lean Practitioner
- Professional Coaching
- Facilitating
- Teaching
- Mentoring
One: The agile coaching backlog items
I suggest separating three different types of backlog items.
- The Epic
- The Task
- The Problem Statement (this will not be covered in this post)
I like using terminology that is common for product development teams. You might notice that I don’t mention the user story. I’ve experimented with that type of backlog item for quite some time but did not find all too much value in it. But before you work yourself up on that not being agile, hear me out… I think I got the intention of a good user story covered in the epic backlog item.
The Epic
The epic is the cornerstone of my work as an Agile Coach. It guides me over a longer period. My kanban flow time-tracking tells me that working on an epic took me on average 77 days over the last 12 epics (the median was 75). It may take up to 150 days or can be done after a mere 30 days.
Depending on the context it might be appropriate to have more than one epic ‘in process’ at the time. However, as always with too much work in process, context switches are inevitable and they decrease the Agile Coaches’ effectiveness and responsiveness. Moreover, having too many epics open simultaneously can increase the feeling of stress and anxiety. I have the experience that having more than three epics started at the same time is a bad idea.
The structure of every epic is the same. It consists of five elements that are documented together.
- The Goal
- The Desired Observable Behavior / Target Condition
- The Acceptance Criteria
- The Constraint
- The Definition of Done
Let’s drill down into the different elements and consider their respective value for the preparation as an Agile Coach.
Built on solid observation and an (often) model-based interpretations — together with the people I’m working with — I define an (emotional) goal as the headline for an epic. This goal should have a certain ‘gravity’ to support you withstanding all the luring distractions in an Agile Coaches’ working day.
This may sound like
Team XYZ got the demand under control and picks up the incoming work in a controlled flow.
or
Team ABC employs inspect-and-adapt-practices to constantly improve its delivery flow (in terms of reducing disruptions, shorten lead times, increase throughput).
I avoid making those goals SMART. The sentence is more like an emotional compass than a precise goal. The precision comes with the next element of the epic.
The desired observable behavior or the target condition often stretches colleagues being new in the role of an Agile Coach. We try to imagine what success in the sense of the goal would look like. It’s important trying to be precise since this will help you recognize improvements along your way.
There is quite some buzz in the agile community about whether or not the effect of agile coaching can be measured. And while I’m a fan of ‘hard metrics’ that show that the application of agile and lean principles has a positive impact on the way we develop products for our users there is also a more subtle way to determine the effect of what we are doing. We can simply observe the change in people’s behavior. I’ve covered that in more depth here.
Anticipating the behavior we aim for may sound like
The team’s product owner names the sprint goal at the beginning of the iteration within the sprint planning meeting.
In the backlog refinement meeting the team derives the stories for the upcoming two iterations naming their relevance for the current epic.
The team uses the retrospective meeting to take a look at their defined flow metrics and comes up with experiments to improve those metrics repeatedly.
The practice of anticipating the behavior we consider suitable for the challenge at hand has some positive effects.
- It forces us, Agile Coaches, to be precise on what we want to achieve. Vagueness impedes achievement. This practice also slows down our thinking when considering an intervention and reduces the risk of impulsiveness.
- It makes it easy to determine whether an intervention may be considered fruitful or not. We can tell if we are on the right track.
- It allows us to recognize progress. It can be frustrating if a change takes some time and progress is hard to be seen. Checking in from time to time and compare observations made some time ago with current observations and the anticipated observations give a good indication of progress and helps to keep the calm if things somewhat feel stuck.
- It helps to describe achievements to others. ‘Mirror’ someone’s behavior with explicit descriptions of observable behavior makes it easier for people to digest what has been achieved.
- It tells you when to stop. This is a really important one. Agile coaching is a messy process and it can take forever if you have not described upfront what will be a good point to rest and let your interventions sink in for a while.
Moreover, anticipating an observable behavior or a target condition allows you to ‘reverse engineer’ the systems’ structure that supports the behavior we would like to see more often. Following the prime directive and considering system dynamics, we can recognize that we have to alter the structure that supports certain behavior instead of bluntly requesting ‘different behavior’ from people around us.
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” — Norm Kerth, Project Retrospectives: A Handbook for Team Review
This leads us to the …
Acceptance criteria help me to determine if I have done the best job I could do from a professional perspective. Defining those help me to think about measures I consider essential to allow the desired behavior to emerge. When I come up with acceptance criteria I answer the question “What has had to happen so that I have done my job right?”.
This might be
I’ve facilitated a workshop to allow first-hand experiences with flow and flow metrics.
I’ve made a proposal on a change for the current workflow of the team.
I’ve visualized the conflict between the two teams by using the ‘conflict resolution diagram’ and discussed it with representatives of both teams.
I’ve modeled the situation as I’ve understood it and received a cross-check by three more people from the product organization.
Don’t confuse those acceptance criteria with the tasks that I’ve mentioned above. Task, as you will see below, are more fine-granular and describe the way forward in tiny steps.
Constraints are things that I consider as a given for the work on a particular epic. I don’t try to alter those constraints for the time I’m dealing with the epic. You could call those ‘boundary conditions’ to not confuse them with ‘the constraint’ in the Theory of Constraints (TOC).
Those constraints might be
The budget for external facilities is limited to 5.000 Euro.
The intervention shall only affect team A directly.
The management team has 2 days per month available.
Like in product development it is of enormous value to make constraints explicit. This helps to avoid running into dead ends and fosters creativity.
The definition of done collects all the things that I think needs to be done to close the epic. Those items are usually related to the process of my work and not to the context of the epic.
A definition of done might consist of some of the following elements
A final review with the people involved has been conducted.
A blog post with the key learnings has been published.
A documentation of all the workshops and inputs have been handed out to the team.
An impulse talk has been given to the other Agile Coaches in my team.
What I describe here is my current state of practice based on several years of experimentation. It’s going to evolve and I don’t claim this being a ‘best practice’. It simply helps me to be an effective Agile Coach.
The Task
The item type ‘task’ in my Agile Coach backlog is pretty straight forward. Tasks describe all the steps that I think need to be done to come closer to my epic goal.
Inspired by David Allen’s Getting Things Done I like to have my tasks actionable stating a real (physical) change in my environment. That makes tasks more meaningful to me which in turn helps me to get them done quickly.
This may read like this
The invite to the workshop has been sent to the team.
The flipcharts for the retrospective are prepared.
The concept for the first part of the flow metrics training is published on confluence.
I want to emphasize that I constantly add and remove tasks to the epics. It’s impossible to anticipate all the tasks that need to be done and it’s not necessary.
I like to have “The Weekly Ritual” that has been introduced by David Allen. This helps me to maneuver towards the shared goals with my colleagues and ‘clients’.
When working as an Agile Coach pair I find it helpful to have this weekly ritual together. In my calendar, I call those meetings “Weekly Tactical” as suggested by Patrick Lencioni in his leadership fable “Death by Meeting”.
Two: The Tool
It’s quite common for people to ask me what my “tooling” looks like. Although I don’t want to make this a matter of tooling I will not deny that I use leankit as my weapon of choice when it comes to organizing my work.
I’ve created the work item types described above as ‘card types’.
Within the card type ‘Epic’ I have the sub-card types mentioned above. This makes it easy for me to keep track of what I’ve accomplished already, what needs revisiting, and what might have to be broken down into smaller, more actionable pieces.
Three: The Flow
The Agile Coach workflow is a story on its own but since this story has not been written yet and since this story is so closely related to the backlog items I want to give you a very quick look at the flow of work.
Every new work item enters the workflow in the input queue. Again something that I copied from the Getting Things Done approach. Since there are always more options on what to do I deliberately distinguish between options waiting and things that I am currently working on. As I’ve said before, it is a good idea to limit the number simultaneously started epics to a very low number (e.g. 3 max).
Of course, prioritization can be an issue for Agile Coaches like it is for so many teams out there. I’ve expressed previously that I consider prioritization of long backlogs a wasteful practice. That’s why I suggest the ‘picking-approach’ for Agile Coaches. It may be tricky to decide which epic to start next. Ideally, this decision is made on solid observations, with a shared mental model and a unity of purpose collectively with the team and the management roles in the respective organization. Although it might be helpful for the Agile Coach to come up with a clear suggestion on what shall be aimed for next the discourse on whether the Agile Coches’ intent fits the goal of the organization is a very important part of the whole intervention.
It is often hard to ‘delete’ a seemingly good idea. That’s why I have some buckets on the board that makes throwing away less hurtful. There are the columns “Someday Maybe” for all the items (tasks and epics) that are not going to be processed right now but are not completely out of scope either. Then I have the “Will Not Do” lane. This lane makes getting rid of items extremely easy and thus takes very little mental energy. I find dragging a card into that lane by far easier than archiving it or even deleting it right away.
Especially when working together with a team of Agile Coaches or with your pair it may make sense to have columns that address explicitly what is going to happen today and what already has happened (“Planned Today” and “Done Today”). This supports daily standup meetings as well as asynchronous collaboration.
The columns “Flow Disruption Log” and “Delivery Log” — as their names suggest — create automated logs based on the cards entering the lane. Why and how cannot be covered in this post but it’s a really handy ‘feature’ if you want to track variations in the delivery process of the team(s) you accompany. (I’m not going to dive into common cause variation and special cause variation either ;) Or if you want to keep track of major deliveries you and your colleagues contributed to the goal. This makes an afterward-analysis of what had an impact and how long it took an organization to integrate certain interventions much more straight forward.
I hope this post held some inspirations for you. Let me know how you structure your work as an Agile Coach.
Further Sources
- Death by Meeting: A Leadership Fable…About Solving the Most Painful Problem in Business by Patrick M. Lencioni
- Getting Things Done: The Art of Stress-Free Productivity by David Allen
- How to Boost your Personal Kanban with “Getting Things Done” and Automation
- The Scrum Masters Diary — a powerful Tool to derive effective Interventions
- Reinforced Behavior — the Dark Matter of Organizational Success
- Do Agile Change Agents Know how to Manage? Do They Have to Know?
