Charlie Starts the Adoption Process, but Again Faces Passive Resistance
As Charlie works with the application maintenance team a common pattern begins to emerge. While there was reasonable participation in setting up the kanban system, and there is always some participation in the various kanban related meetings, a majority of change stakeholders either do not show up or are very disengaged from the process. No one is actively resisting Charlie's work, but neither are they showing very much initiative to do things on their own. Many change recipients are complaining that they have other activities to do, and that this change is taking too much of the time.
Charlie decides to reflect this information on his canvas. He's clearly not progressing towards his Success Criteria as fast as he would like, so he marks it yellow. Only a minority of change stakeholders consistently show up and or engage standouts and other kanban related meetings. An even smaller minority shows interest in actually modifying work policies are partaking in workshops necessary to set up and refine the Kanban systems. He marks the Success Criteria as yellow, i.e. partially correct as he is making some progress.
Charlie tries to work with managers to restructure all capability into a single dedicated team with employees who can provide full-time commitment, but is met with forceful resistance. It seems that there is too much point knowledge spread out across too many people, people that have other responsibilities, so he marks this part of the Target State as red.
Charlie still believe that there needs to be some concept of a fully focused, dedicated team, but at some restructuring is required to get it to work. He indicates this by marking the application maintenance team concept within the Change Recipient section as yellow. Currently not all change recipients are fully participating, nor are they learning all the skills promised, so he also marks the appropriate Commitment and Wins Benefits as being only partially correct as well.
Charlie and His Change Recipients Perform a Change Pivot
Charlie starts working with his change champions to get a better understanding of how work actually flows through the application maintenance team. These change champions have been showing enthusiasm and a genuine desire to improve performance. What is interesting is that these change champions are made up of a number of roles, there are operational experts, business analysts, and developers who are showing a mostly full-time commitment. A larger portion of these folks fall into the other other, less interested group.
Charlie collaborates with this change champions to design a simple value network diagram to try to get understanding of the different degrees of responsibility across these folks. It becomes clear that a subset of the application maintenance team are acting as a virtual team. A subset of operational experts understand the system from an end-to-end solution perspective, or have domain expertise in multiple lines of business. A subset of developers likewise understand how all the various systems work together from a solution and or integration perspective. Remaining operational experts and developers are either knowledgeable in one line of business or one specific system, and are really only needed on a part-time basis when a particular aspect of the solution needs to be changed or tested.
From Dedicated Team to Feature Team
Taking some inspiration from Kanban literature, Charlie looks at the concept known as a feature team. Charlie defines a core team, redefining the business analysts within this team as solution analysts, and redefining the developers within the team as solution developers. This team will be made up of dedicated, full-time individuals. The remaining operational experts and developers are placed in a pool, and are dynamically assembled into feature teams on an as needed basis. Charlie needs to work with the appropriate managers (development managers and LOB representatives) to make sure that enough capacity is set aside and some service-level agreements are put in place to ensure that these feature teams can be assembled fast enough to meet the to the needs of the core team.
As a part of designing the value network, Charlie and members of the core team update the change canvas to reflect the latest thinking. They starts with the Target State, adding the concept of a dedicated team supported by feature team.
He then updates the Change Recipient section of his canvas to show two different classes of Change Recipients, a dedicated solution team, and the just-in-time future team.
Likewise the Success Criteria are now much less ambitious, the dedicated is the only group that needs to have deep skills in of Kanban. The larger group needs needs to only be of work related policies to be able to follow them. The Commitment and Benefits section are likewise updated to reflect this new focus on the core solution team.
Charlie then puts in a new Action to help the team design this new type of kanban system and coach the solution team in operating it.
The Team Is Now Collaborating Better, Charlie Turns to Other Elements of the Change Model That Have Not yet Been Tested
With these new adjustments in place, adoption is going much smoother. Charlie places 2 new Improvement experiment into the backlog, one based on fixing the dysfunctional intake & prioritization mechanism, and another experiment dedicated to helping the team adopts some of the metric oriented root cause analysis capability that comes with the Kanban method.
Again, Charlie Faces the Evil of Passive Resistance
Charlie runs a number of facilitated prioritization sessions with LOB representatives who are responsible for establishing priority. He is shocked by how little progress he makes. His attempts to create queues and allocate them to different lines of business go nowhere. No one is willing to step up and say exactly how much capacity they need, Nor are any of these representatives willing to contradict anybody else. Charlie knows that most of these representatives are still going directly to the team, practicing backdoor politics to get their work done first.
Charlie is also unable to find any one person who really wants to own the role of analyzing metrics and getting the team into a state of quantifiable improvement based on data.
Charlie is unsure which part of this change model are incorrect, so he places yellow markers in the Urgency, Target State and Action section. He knows he needs to do some work here but is not sure exactly what.
The reality is that the Business LOB Representatives all have performance bonuses tied to getting their work completed by the end of the fiscal year. Interestingly, a very clear mandate from top executives have made it clear that these LOB representatives need to work with each other to make sure that all work gets done. This is led to a highly politicized climate, where backdoor dealing is the rule of the day.
Charlie adds this problem to the Urgency section.
Time to Reintroduce the Product Owner Role
Because of the divisive and fractured nature of the LOB group, Charlie suggests to one of the executive stakeholders that they look again at the Product Owner role, but this time he suggests that the person fulfilling this role is a senior executive, and that this person possesses the skills and factor to have some tough conversations with various business clients around what can and what cannot be done this year. Charlie is able to get agreement, as this concept was already currently being circulated within the executive group as a potential solution.
Charlie updates the Target State, to include the concept of a Product Owner. And likewise reflects this concept of a Product Owner in the Action, and Wins Benefits section. Charlie has upped his Commitment now to three days a week, as he will be spending a good deal of time coaching his executive on how to be a Product Owner on an agile team.
You may remember that the concept of a Product Owner was part of the original version of this Change Canvas, the idea was scrapped when the idea of an agile iterative team model went out to the window and we brought in Kanban instead. This is a completely normal part of the process, elements of a change model will be removed and then added back in based on new learnings. What Charlie has learned is that he needs to remain flexible and take concepts from different methods in different areas of thinking to come up with a solution that truly fits the needs of his change recipients.
Charlie runs a new improvement experiment for about a month, dedicated to taking an existing, senior Line of Business Representative, and coaching him to become a product owner for the entire solution. This person takes to the new role extremely well, and all early indications show that he is doing a fantastic job.
He also takes ownership of looking at performance metrics such as throughput in leadtime, and running periodic root cause analysis sessions to understand if performance is improving to keep up with the growing demand and improve customer satisfaction.
The change recipients are now showing the ability to successfully adopt new methods, as well as gather performance oriented metrics for the purpose of quantifiable improvement. Charlie is now ready to move the Minimum Viable Change into the final, Verify Performance state of the Validated Change Lifecycle.
Check out the Rest of Lean Change - Chapter 5: Walking through the Validated Change Lifecycle with a Comprehensive Example
No comments:
Post a Comment