Resolving Doubts Around Agile Transformations. The Agile Transformation Framework

This article was originally published at ScrumAlliance website on 30-June-2017. Although, the members-authored content has been suspended at ScrumAlliance a while ago (with Maryan’s wonderful drawings). So I have copied it here, on medium, where (chances are) it will last longer :)

Yuriy Koziy
agiledrive
8 min readJan 26, 2020

--

Introduction

On May 26–28, a Scrum Coaching Retreat was held in a fabulous resort outside Kiev, Ukraine. The group of coaches broke into smaller teams to work on important topics around Scrum, agility, and business transformations.

The beginning of the retreat — the Groan Zone of the future self-organization

This article describes the result of the eight-hour collaboration of four experts (Yuriy Koziy, Alex Shevchuk, Evgeniy Labunskiy, and Maryan Tsar) on a topic they felt was very important: responsibility borders in an Agile transformation. What is the responsibility of the external Agile coach, and what is the responsibility of the client (organization)? How do we ensure that everyone is on the same page regarding those borders?

This should clarify any ongoing doubts on the part of an Agile coach, which often include:

  • Is he or she the right fit for the client (and vice versa)?
  • Is the transformation progressing at the right pace? And what is “the right pace” here?
  • Are the transformation results visible and satisfactory for the organization?

We first looked at Definition of Ready and Definition of Done checklists, but that topic turned into something bigger — something that we would dare to call an Agile Transformation Framework. That is, a framework that helps Agile coaches and their business clients ensure that the Agile transformation fulfills business objectives and is aligned with Agile values.

Yes, it looks very much like Scrum, and that’s the idea. Scrum is self-sufficient and self-explanatory, so is the Agile Transformation Framework. Simple yet sufficient roles, artifacts, and meetings.

Overview

Before the beginning of the coach’s cooperation with the client (company), the parties should agree on transformation prerequisites. We call it the Definition of Ready. It’s a checklist of entry criteria that helps the coach assess whether a potential client is ready to start the transformation journey.

As both parties agreed on the entry criteria, the Agile coach helps the client to:

  • Build awareness around the vision, scale, and approximate duration of the transformation
  • Build the Transformation Team: identify the Transformation Owner and a team of Change Agents (see Roles). Clarify the responsibilities of these roles.

This will build a sense of priority and transparency for the process. In the short term, the Transformation Owner, with help of the Agile coach, identifies a short-term goal and builds it up as the iteration backlog — a list of achievable tasks that deliver the value, according to Definition of Done. The duration of the iteration — typically from a few weeks to a few months — is to be agreed upon by the parties.

During the delivery, the team uses the Health Check to verify how they approached the goal.

Demonstration of the iteration results takes place at the end of the iteration. Change agents and the Agile coach present the results to the Transformation Owner. After that, the Transformation Team participates in an iteration retrospective meeting to reflect on the transformation process and adjust further plans.

Roles

  • Transformation Owner: The person who requests and budgets the transformation. For small to mid-size companies, this can be the CEO or business owner; for large enterprises not necessarily the CEO, but perhaps someone among the top executives.
  • Agile Coach: Either external or internal, this is the expert in Agile who is educating the teams in the organization, lives Agile values, and shares and acts as a ScrumMaster for the Transformation Team. As in Scrum, the meta-goal of the Agile coach is to grow the Transformation Team, so that they run and support the business transformation process without his or her assistance.
  • Change Agents Team: Volunteers from inside the organization (e.g., leaders, ScrumMasters from teams, people from HR and PR, etc.) take initiative, being those who are willing to dedicate their time and energy to drive changes. Without these people on board, it may look as though the only person committed to transformation is the Agile Coach. The initial Change Agents are to be identified during discussions around the Definition of Ready. The team composition can vary during the transformation.
  • Transformation Team: Three above-mentioned roles form the Transformation Team.
  • Stakeholders: A group of people, typically top executives, who are interested in the results of transformation. They work closely with the Transformation Owner to ensure that the transformation aligns with business priorities of the company.

Artifacts

Health Check

Throughout a transformation, it’s vital to understand the current conditions. Are we facing any resistance or difficulties on the path? Do we have enough support from stakeholders? Is the current situation transparent and are obstacles and results visible to everyone?

The Health Check is a set of criteria identified by the Transformation Team and interested stakeholders that will align everyone on the progress of transformation. It’s critical to involve stakeholders in the Health Check design and — most important — in choosing criteria and phrasing.

Once we have criteria in place, we suggest the following:

  • Conduct the Health Check in the middle of the iteration, or as part of a transformation iteration retrospective meeting.
  • Gather stakeholders and Change Agents in one room.
  • Make this a voting session only, and keep it short and focused. Use the results to drive powerful conversations based on clear questions such as, “How can we improve the transformation process?”
  • Ask everyone to rank each of of the criteria on a scale of 1 to 10 in importance.

The image below lists sample criteria that your team could start with.

Definition of Done (DoD)

Since Agile transformation lives in a complex environment, defining specific long-term goals is not an easy task. With limited understanding of the organizational context, a coach usually cannot promise concrete results on a specific date. Neither can the client. That’s why it’s crucial for the coach to help the Transformation Owner formulate the closest achievable goal: a transformation milestone. It can be scheduled from a few weeks out to a few months, depending on the organizational context.

We decided to call this the Definition of Done. In fact, it’s a set of specific objectives, upon which the Transformation Owner will measure success of the iteration. This will help the team stay on track at any given moment.

For example:

  • The Scrum Team releases an increment by the end of each sprint.
  • ScrumMasters are identified and ready to act as change agents.
  • For each team, there’s no more than one product owner.
  • Teams accept new structures and new practices and follow process changes without resistance.

Definition of Ready

Before starting collaboration with a client, it is recommended that a coach ensure that they are a good fit for one another.

As part of the Definition of Ready preparation, the Agile coach might want to learn the following details from the client:

  • Current state of the business, successes and pain points
  • Information about any previous transformations within this organization, their successes and failures
  • Why they have decided to conduct a transformation right now
  • Client readiness assessment
  • Agile coach readiness assessment
  • Low-hanging fruit — changes the team could do easily at first, to get the transformational ball rolling
  • The client’s vision and road map for the transformation

Client readiness: The success of any transformation starts with the client’s desire and ability to change. And this is something that the Agile coach will want to assess at the beginning of their cooperation. For example:

  • Intention: is it a client who is willing to start changes? Do they understand scope of the transformation?
  • Resources: Does the client understand the importance of allocating all needed resources inside and outside of the organization?
  • Budget: Does the client have a relevant budget for his needs?
  • Time: Does the client understand the time involved in a transformation?
  • Cooperation: Do the coach and client respect each other and cooperate based on trust?
  • Processes: Does the client understand that a transformation may require changes not only on the team level but that it will also influence the organization in general (processes, structure, habits, etc.)?
  • Education: Does the client understand the importance of education as a starting point of the transformation?
  • Decisions: Has the coach ensured that he or she has contact with a decision maker on the client’s side?

Coach readiness: The coach should be confident that he or she is able to handle the scope of the transformation in terms of time, availability, expertise, etc. That is left to the coach’s set of ethics and is outside the scope of this guide.

Backlogs

There are two backlogs:

The transformation backlog describes the scope and scale of the transformation that the Agile coach helps the Transformation Owner come up with. This backlog contains the list of actions for the Transformation Team to execute during the Agile Transformation. For example, Scrum Teams deliver an increment after each sprint, Communities of Practice start emerging, stakeholders get transparency about the results, etc.

The iteration backlog is the to-do list for the Transformation Team for the current iteration, discussed during the iteration planning. This backlog should move the company toward the goals described in the transformation’s Definition of Done.

Meetings

Transformation is an iterative process. The Transformation Team sets preliminary goals (acceptance criteria), reviews results, and improves the process.

  • Iteration planning: Before kicking off of any next iteration, the team should get together and discuss and plan activities for the next iteration and formalize the iteration backlog and the Definition of Done.
  • Iteration results review: At the iteration review meeting, the Transformation Team should get together to discuss the actual result they got during the iteration and understand the current organizational state, evaluating the results.
  • Iteration retrospective: A regular meeting for the Transformation Team to inspect and adapt the process, run a Health Check, and improve the process.
  • Regular sync-ups: A synchronization meeting is useful for the Transformation Team to ensure that they stay on track with iteration goals and the DoD. While typically run on a weekly basis, the frequency of these meetings is to be defined by Transformation Team.

Conclusion

The original intent of collaborative work between our group was first of all to clarify, align, and develop a list of best practices concerning how to approach a client before diving into a transformation, how to do it in a bit more structured and professional a way, how to speak your client’s language. As an outcome, this Agile Transformation Framework emerged. We believe that it will benefit Agile coaches who are taking the very first steps in the field, and that it can support experienced coaches in their hard daily work.

There are still a lot of challenges we can see ahead of us. The Framework is just a lightweight tool, not a multi-purpose one. Inspect it and adapt it for your specific context.

This article was coauthored by Yuriy Koziy, Alex Shevchuk, and Evgeniy Labunskiy.

--

--

Yuriy Koziy
agiledrive

Organizational Consultant, Managing Partner @ agiledrive