Or The Dynamics of an Agile Transformation Team

I found this great article about a leadership team (SLT) adopting agility WITH their teams.

http://blog.qrious.co.nz/how-to-navigate-with-agile-leadership

It’s relatively short, but powerful because of the perspective. That is, it focuses on the activity of the senior leadership team in an organizational agile transformation.

I often think one of the core challenges for most leaders is that they are stuck in a situation where they’re telling their teams and organizations –

Do what I say, Go Agile, and not what I do

That is, they are not walking their talk. Now don’t get me wrong. It’s usually not a malicious or lazy play. It’s simply that they have more important things to do. Things that require their specific skill set and expertise to lead and get done. So, there is little to no time left for working like or with their agile teams.

Some may think this is ok and that it doesn’t really have an impact on the agile organization. Or the potential agile organization. I actually think it has a very negative effect.

What David Wills illustrated in his article, is the power of example that leaders can show when they leverage agile principles to transform themselves, as well as, their organizations. I want to explore that notion much more fully in this article. Next, I’ll introduce the notion of an Agile Transformation Team or ATT.

Agile Transformation Teams

What are they?

They are a team that is formed to establish and guide the agile journey within an organization. It’s usually made up of internal senior leaders and internal or external coaches and agile change agents. One of the key attributes of the group is a passion for agile principles and a vision for where they want the organization to go.

The entire focus is on transformation, both from a strategic level and a tactical / execution level. Often these teams are larger than the Scrum team size guidance. Instead of 7 +/- 2, they might be 10-15 in size. While this might be unwieldy from a team size perspective, the advantage is usually broader organizational representation.

What does it look like?

In a word, like any other agile team. Let’s use Scrum as an example. Often the ATT is formed as a Scrum team.

There is a ScrumMaster; usually one of the more seasoned agilists within the organization. This person needs to have strong facilitative skills and be a role model as a ScrumMaster.

There is a Product Owner; usually the most senior leader chartered with leading the effort. In this case, the “product” is the agile transformation.

The team is composed of a core team that is representative of the overall organization. Often it includes:

  • CIO, CTO, CPO, CMO, etc.

  • Technical leader(s) (VP, Director level)

  • Development leader(s)

  • QA & Test leader(s)

  • Product leader(s)

  • Project (PMO) leader(s)

  • Business Analysis & UX leader(s)

  • Tooling (Admin, DevOps, etc.) leader(s)

  • Architectural leader(s)

What are the dynamics?

As I mentioned, they operate as a “real” Scrum team. That is, they:

  • Form, establish norms, create a definition of done, agree on tooling / practices;

  • Agree on sprint length and meeting timing;

  • Create a backlog together; it doesn’t have to be perfect at the beginning, just good enough for 1-2 sprints to “prime the pump” if you will;

  • Perform initial and ongoing backlog refinement; initially focused on the first sprint;

  • Plan and execute sprints, with daily standups;

  • Deliver results in sprint demos;

  • Retrospect & continuously improve.

All the while performing as an autonomous, accountable, self-directed team.

One of the most interesting aspects of this team is “eating their own dogfood” with respect to agile team dynamics and expectations. For example,

It is almost universally true that these teams bite off too much work in their first few sprints and fail to deliver on their sprint goals. To be honest, as a coach I LOVE this aspect of the learning for the leadership team. It brings them into the real world that their teams typically live in every day.

When should they be formed?

In a word, first. I often encounter greenfield agile transformation requests as an agile coach. Usually the client begins by asking me to come in, train their teams, and get them sprinting. The request is totally downward focused towards their teams.

I always try to change this direction.

I always favor a leadership-centric approach first.  So, one of the first things I’d like the client to establish is the ATT. This becomes the hub for all organizational activity around their transformation.

Does the team stay the same size; fixed membership?

Not always. Usually the team fluctuates in the first few sprints as members figure out their capacity, roles, and interactions.

Sometimes someone will join the team for a specific initiative (epic, story, focus point) and then leave after it’s complete.

Sometimes the roles shift as well. For example, I’ve seen ATT’s that rotate the role of ScrumMaster across the team on some interval; perhaps monthly.

What’s on the Backlog? What is the work like?

This is where it’s quite different from a Scrum team. The work of this team is:

  • More strategic, focused towards establish vision, mission, and overarching goals;

  • Also establishing the plan(s) to meet the goals;

  • More communications & transparency focused;

  • About removing impediments and providing resources;

  • Focused on initiatives, goals, and objectives;

  • Often establishing acceptance criteria for each story (for measuring interim and final closure);

  • Also focused on overall metrics;

  • Quite often the work of this team (activates, engages, delegates to) others throughout the organization.

At the same time though, this team is accountable and responsible for delivering the work they plan for.

Teamwork

One of the more interesting aspects of the ATT is the teamwork, true, collaborative, pairing-based, teamwork that it engenders across the members.

Often this is the first time that this group has worked together as part of a unified and aligned team. So, expect some turbulence as the team figures out how to work together and balance across their organizational roles vs. their ATT roles.

Sometimes I recommend the team read Patrick Lencioni’s, Five Dysfunctions of a Team, as a means of establishing the conditions for high-performance and trust teaming. It’s a quick read and quite useful.

Do the tools matter?

First of all, I usually deemphasize the need for grandiose tools at the beginning of any agile exercise. Preferring instead to use the simplest possible tools that can work. Even in a highly distributed group.

Post-it notes, flip charts, and markers can be highly effective, low-fidelity tools. And usually the teams opt for Trello as the online means to manage their team. Simple to setup, configure, and use. What you want your early tools to do is augment the conversations and collaboration as the ATT Storms, Norms, and Performs.

Another View: Mike Cohn’s – Enterprise Transition Community

In his Succeeding with Agile book, Mike Cohn brought up the notion of establishing an ETC to serve as the focal point for an agile transition (transformation). In many ways, it looks like my Agile Transformation Team.

Here are the steps Mike suggests in forming your ETC:

  1. Form an ETC Backlog;

  2. Establish an ETC Sponsor & Product Owner; they could be the same person;

  3. Establish an ETC Scrum Master;

  4. Establish an ETC Team (floating partners of the effort);

  5. Initiate ETC Sprints.

And, here are some of the responsibilities Mike shares for the ETC:

  • Set the vision; articulate your context;

  • Generate conversations;

  • Provide resources;

  • Set appropriate goals and aspirations;

  • Engage everyone; provide broad transparency;

  • Anticipate and address people issues;

  • Anticipate and remove impediments;

  • Encourage a broad focus on practice and principle.

I think the key difference is this is truly a community effort, so the team is really a loosely coupled group of folks. Yes, there is a core team, a backlog, goals, and vision. However, the execution is more influence based and engages everyone (or as many as possible) within and across the organization.

There is also more of an opt-in or invitation nature to the ETC than there is in my view towards an ATT. That can be good from a cultural perspective, but it can also slow things down if nobody is willing to step forward.

One of the biggest problems I see with the ETC is that in many organizations the leadership team delegates everything to the team. So, there is no senior leadership representation (skin in the game) in the ETC. Often without that, these teams struggle as much or more than the other agile teams in the organization.

If you want to have a high-functioning ETC, then the members need to have strong and empowered roles within the organization. Or at least the ScrumMaster, Product Owner, and Sponsor do.

Wrapping Up

As I said, nowadays I always try and start my engagements by helping the client form an Agile Transformation Team (or ETC).

I’ve found it a great way for a client to learn, practice, and grow their agility across all aspects of their organization.

It also sends a clear message to their teams that the leaders are willing to practice what they preach.

Stay agile my friends,

Bob.

BTW: here’s an article that nicely compliments this one –

https://www.linkedin.com/pulse/rocking-agile-transformation-team-gil-broza

 

Comment