Managing Agile Adoption through Observation of Behavioural Change

When trying to help a larger organization down the agile journey I have found it helpful to take a structured, but feedback rich approach to managing and coordinating the transition. This structured approach is based on the following premise:

• agile change is about a change in mindset and culture
• culture and mindset cannot be directly observed or changed
• changes to both culture and mindset can be observed by looking for changes in the everyday behavior and practice of both team and management
• flow of change can be visually managed by understanding the level of coaching support required to effect these new behaviors

I have been a on coaching teams responsible for helping medium-sized business units (think 200 - 600+ employees) effect progress along their agile journey. The change can range in scope across business, technology and operations. When starting the journey I often look at the organizational system, and divide it into a number of distinct business technology portfolios. Each portfolio is responsible for managing a cohesive backlog of business value delivery. Each portfolio is further broken up into a number of self organizing teams, with a minimum of dependencies outside the portfolio. For more information on how to do organizational design required to come up with portfolios, feel free to look at my previous post on the topic

Organizations tend to adopt an agile mindset incrementally, the focus of adoption to shift over time

The next thing I typically do is work with managers, team leads, and enthusiastic adopters (henceforth called change agents) and walk them through a path that both teams and managers can take to incrementally adopt various key behaviors that are, in my opinion essential to bringing forth an agile mindset and fostering a cultural change to the organization.While our coaching team will often have an opinion as to what this path should look like, we learn a lot by working with our change agents to come up with something contextualized to their needs. We work to gain agreement on what the overall focus of each state in the journey can be, paying attention to the behaviors that would provide the most value, while managing the disruption incurred.

Instead of starting with specifics, we first emphasized what the overall focus of a particular state of adoption would be. Teams and managers could choose to shift focus when they were ready to think about their next step in the agile journey.Looking at each stage in brief:Initiate - management and teams start to think about their system of work so that they can design a more cross functional, team oriented organizational structure. Coaches provide support required to enable a mode of accelerated learning, introducing the new mindset sufficiently to gain agreement on some target behaviors that they would like to change.Collaborate - management and teams increase their understanding of how work flows through and across various teams., They set up various events, practices and other working agreements. This leads to an increased focus, enhanced collaboration, and improved working conditions overall. The mindset is still rooted in thinking about work from a more traditional, deliverables and task oriented approach.Accelerate - management and teams start thinking about the end-to-end delivery of value, regardless of whether a particular aspect of delivering that work is the responsibility of their particular team. Teams are able to think in increments of customer value, and reduce bottlenecks and handoffs necessary to deliver that value frequently. Increases in technology capability tend to occur. Improvements are measurable.Dominate - another mind shift occurs, especially as it related to how thinking about work. Management and teams are now focused on minimizing the lead time required to understanding whether a certain activity will actually lead to sustainable market value. Teams are organized to own business, technology and operations for a particular product or service. A culture of validated learning, constant innovation, and “software everywhere” is taking hold.It's important to note that teams rarely move through these stages in a purely linear process. In practice, teams will start to exhibit behavior across these different stages at a single point in time. Regardless, we are finding it helpful to frame the journey as a set of stages as it helps teams new to agile to focus on where they would like to be in the short term, versus farther out in the future.

Each change in focus can be observed by looking out for key behaviors

The next thing our coaching team did was map out each stage in terms of key behaviors that we thought were important to demonstrating a shift in mindset. We asked teams to self select how far they wanted to go in in the next couple of months, and which behaviors they thought they could start demonstrating in that period of time.We tried to stay away from particular practices and and methods, as there are often multiple options to getting to each behavior. The distinction here is that a behavior could occur, regardless of whether a particular agile methodology or practice was being used.

InitiateDesign FocusDuring initiate, we wanted teams to take the time to understand their current and newly proposed system of work. Why would a particular team have the people in it that it did? What value was this team supposed to bring? How would this team interact with other teams to provide this value? Who are the primary stakeholders and customers of the steam? And what other teams would provide this team critical services? How would this team interact with executives and leaders?Learning FocusAnother key focus of initiate was to maximize the amount of learning that could go on. How "agile aware" were team members and management? Was their specific training, simulations, or boot camp sessions required to help teams onboard their work and get started?Mindset and Behavior FocusIs there a desire or opportunity to tutor people on how the agile mindset contrasted to traditional mindset?What behavioral change did various teams and managers feel was important to them? Could we get agreement between the coaches and people undergoing the change on how to best observe those behaviors?CollaborateRather than jumping immediately into a truly iterative value delivery, mindset, I have seen many organizations elect to move at a more conservative pace. When teams and managers decide to move into Collaborate, they are choosing to use agile methods to gain a better understanding of the work going on, and what their place is in the in current, larger ecosystem of work that surrounds them. Teams tend to still focus on thinking about work from a traditional, deliverable and task oriented perspective. Delivering value in small increments tends to be a problem that is deferred for later.Questions ask include:

• How can my team effectively deliver work in a way that minimizes confusion in churn?
• How can I interact with other teams?
• How can I reduce wasted effort in trying to create deliverables and complete milestones for those deliverables?
• How can I create an environment where the majority of my teams are emotionally invested in continually improving the way that they deliver?

Collaborate can be an important stage in the agile journey, as it allows teams to get value out of agile without immediately embracing what can seem to be a counterintuitive mindset. The value in helping a team focus explicitly on better collaboration, as opposed to jumping immediately to the Accelerate stage on the journey is that teams can increase self organization, introduce incremental improvements, increase feedback through reducing how much they do a time, adopt repeating events, etc. and gain tangible benefits which increases the desire for more bold change. Of course the risk is that teams settle on Collaborate, in effect adopting a set of agile mechanics without taking the true jump to a different way of thinkingAccelerateAccelerate is about the adoption of behaviors that allow teams to deliver work frequently in small increments of customer value. Teams in Collaborate continue to think about work as a set of deliverables, milestones and tasks. Teams moving to Accelerate think about work as a sequence of minimum viable products, features, and stories. Value is decomposed into finer grained units of solution behavior, and this behavior is tested for correctness. This requires that both teams and management take bolder steps, adopting bolder change. Expect team structure, flow of value, leadership and management, etc. to look very different as a result. Accelerate is really about having the courage to take on the constant change required to deliver frequently.Key questions asked include:

• How do I reduce the scope of what I'm working on get something to the market faster?
• How can I assemble my teams so that value can flow quickly through the entire organization? How can I enable teams with best in class technology engineering capabilities to support sustained frequent delivery of value?
• How can I quantify the frequency and amount of value that I'm delivering in some kind of measurable way?

Some teams starting with agile elect to move directly from Initiate into Accelerate. They tend to (rightly) view the Collaborate state as a potential speedbump, an extra step to moving towards a different mindset. In my experience, spending the time to explain the difference between the two has helped more teams make a better decision. I've had the unfortunate experience of trying to help a team get to incremental customer value right away and experienced a lot of churn as a result, having them accidentally end up in a state where they were adopting agile practices, but staying grounded in a more traditional deliverable/task mindset. By being explicit, it allows teams to understand the difference between the two mindsets, and take a deliberate stance on where they would like to be in the short term, and where they would like to be farther in the future.DominateWhen our coaching team asked ourselves what what does leading-edge agile at scale look like, Dominate was our answer, Imagine an organization that is observably following many of the practices and thinking described by books such as The Lean Startup, The Phoenix project, Clean Code, etc etc and you probably get the idea of what we're trying to represent with Dominate.The way that teams think about about their work again takes on a different paradigm. During Accelerate, the focus was on thinking about work as an increment of value. During Dominate teams tend to think about work as an increment of learning. Teams are no longer trying to maximize the number of stories, epics, etc. they're trying to get to market. Instead teams are minimizing the leadtime between making an assumption about whether a particular activity might provide real market value, and the certainty that it does.Again expect large changes in the organization. The majority of teams now own their business, technology, and operations required to deliver market value. There are very little handoffs, and dependency and other teams. Insight is connected to Operations. Devops has been achieved at scale. Constant and continuous market feedback exists at scale. Team metrics evolve from delivery completion metrics to how explicit experimentation is being used to validate business model metrics.Key questions being asked include:

• What are the key metrics that matter to my business?
• What are the key assumptions that if proved false will derail our business?
• How can accelerate validated learning required to understand whether we need to pivot or pursue our current strategies?
• How can we maximize market learning across the organization?
• How can we eliminate handoffs in our system of work?
• How can we completely break away from traditional silos across the organization?

Behaviors can be tracked at both the manager and team levels, and become the point of conversation for overall change coordination

Once change agents and coaches have negotiated the behaviors that they wanted to see, we can stand up an Adoption Kanban, which included a behavioral change backlog for each team. Our coaching team has had challenges visualizing adoption flow in the past. So in the latest iteration we tried to come up with a work visualization and workflow that reflected how coaches tended to support adoption when working with teams and managers. We ended up adopting a model based on how coaches often think about how to affect change within the community.

It is important to note that this model was inspired by presentation that I saw at the last Toronto Agile MeetUp given by Damon Poole, called the The Butterfly Effect. During the session Damon described different things that a coach could do, relating the coaching activity to the amount of change impact it would have related to the coach’s effort. We took this model and mapped it into a change flow.Doing / Teaching - when a behavior is in this state the coach is actively training teams on how to effectively exhibit this behavior. They are often playing a leadership role in the facilitation of specific sessions and practices, and at the least are working with leaders to debrief before or after a particular practice or session is in use. In general, the behavior in question would not occur if the coach were not around to provide support and enforcement.Mentoring/ Managing - the Coach is still playing an active leader and facilitator role, but team members are now playing an active role, supporting the practices and carrying some of the weight, so to speak. There is agreement that the behavior would occur, albeit sporadically, and with obvious (from the coaches perspective) opportunities for improvement if the coach were not present.Coaching - the team consistently exhibits the behaviour in question, the mindset has indeed taken hold. The coaches is only required for occasional support, and the coach truly gets to act as a coach. Support from the coach is provided through open inquiry, asking thoughtful questions, in effect providing an environment where the team can come up with their own answers through the reflective dialogue provided by the coach. At this point the behavior would continue to occur and improve, regardless of whether the coach is present or not, but the coach can work with the team to adopt breakthrough improvements.Independent - There is really very little to no support from the coach at this point. The coach may attend an occasional practice or session to observe, but has very little to say if anything. The coach’s primary motivation would be to encourage the team to start teaching and coaching others.The power of managing adoption using this flow comes from a number of concepts. The first being is that we aren't actually measuring the maturity of the people going through the change, rather were asking teams the question "how much support do you think you require from the coaching team order to affect this behavior?". This subtle but important distinction is allowing teams to self assess how much support they require from us, minimizing judgment in terms of maturity or capability. So far, our experiences show that this leads to a very honest conversation. The second thing that we are liking about this flows it is making it really clear how things are progressing and where things are stalling. In the past we've tried various visualizations and found that no matter what we did we ended up masking the bottleneck, and struggled with ways of visualizing where churn was occuring, for instance what does it mean when we are helping a team adopt story mapping, and it is in progress? Things tended to stay in progress for a very long time…

In order to exact change effectively, consider using a structured method to plan and coordinate the change efforts

Finally, I typically work with our change agents to come up with a changed cadence model, where change planning and coordination events can occur on a regularly scheduled repeating basis. This type of approach has the benefit of using agile techniques to bootstrap agile adoption, which leads to early learning and understanding of the benefits of some of the practices.

Change CoordinationChange coordination sessions, a kind of change stand up, can be held for 15 minutes weekly in front of an Adoption Kanban. Team owners, managers, and other leaders attend to discuss what adoption activity they are focusing on for the week, and what support they required from our coaching team and/or others who are also going through the same journey. Our experience in doing these kinds of sessions in the past is that it creates a kind of community of change. Teams that are accelerating through the learning curve now have a venue to offer assistance to others who are struggling for various reasons. The standup create a kind of pride and ownership, leading to better focus especially at the beginning of these kinds of efforts.Change Strategic AlignmentAnother weekly session for 15 minutes where change "sponsors" (think executives and senior manager) can meet with a subset of our coaches to understand if we need to look at things from a macro perspective and make any necessary pivots. While certainly our focus is to keep the bulk of the decision-making within the change coordination meeting, there are occasions where some discussions need to be had with a smaller group.Change planning and reviewDuring the session coaches and change agents will meet to look at the current progress in terms of behavioral adoption, re-evaluate their plans, as well as do a kind of change retrospective to discuss pop and pediments and what to do about them.