I've talked about LeanChange, and the Change Canvas in a couple of previous posts, to make it real, I'd like to share a story about Danny the Danny the developer.
Dan works as part of the team responsible for developing web applications that need to serve multiple lines of business within his employing organization. Danny feels that most of his peers within his team have good experience in their fields of expertise, and are passionate about delivering a good quality product.
Unfortunately Dan cannot shake the feeling that the project that he is currently working on is doomed to fail. This team is currently working on a complex application with multiple business stakeholders in a relatively short time line in which to deploy working functionality to production.
Despite the Fact that his team is working long hours, Danny feels like it is taking an awfully long time to show working functionality to the various business stakeholders of this engagement. The team seems to generally agree that there is no end in sight to this project.
When working functionality is shown to customers, these customers tend to be dissatisfied with the results.
There seems to be a lot of confusion both within the project team around what the solution is supposed to do, and there seems to be even more confusion between the delivery team and business stakeholders.
Danny is extremely passionate about his craft, he has been studying up on different ways of improving his game. In particular he has been doing a lot of research on agile methods, and how agile can improve delivery outcomes for businesses trying to deliver working software to their customers. Danny wants to completely overhaul the way his team is delivering business value through the adoption of the agile approach.
Danny brings this up with his delivery team, and encounters an immediate resistance. Most of Danny team members feel completely overburdened with the amount of work involved in delivering this project. The last thing that they want to do is spend the time required to learn a completely new set of practices and new methods. Danny's team members also do not understand how agile methods will resolve their problems, and can connect how adopting agile methods will bring any immediate benefits to their current project.
In short Danny's ideas of adopting agile is shut down by his peers and his management without being given a reasonable chance.
introducing the Change Canvas
David then takes a step back, he is determined not to abandon the idea of trying to prove the way his teammates are delivering software, but is now convinced that he needs to take a different approach. Simply telling his teammates what he thinks a solution should be is not working, so Danny needs to try an approach that will allow him to collaborate with his team on what that solution should be.
Danny will also face better odds of success if he uses this collaboration as an opportunity to learn from his peers and understand what team they are feeling, and what solutions do they feel would best help them get out of their current problems.
Danny decides to use a Change Canvas to collaborate with his teammates on a solution. A change canvas is a lightweight tool that allows a change agent, in this case Danny, and a set of change recipients, in this case Danny's team, to negotiate a change solution that meets the needs of all involved.
The Change Canvas is made up of a number of components, each component is responsible for articulating a key aspect of any change plan.
- Any change initiative should start with the problems being addressed, and establishing a sense of urgency amongst the change recipients.
- change initiatives will target one or more change recipients, who connect with the problems in urgency identified on the canvas.
- once a set of change recipients can agree and feel urgency a guiding vision for the change initiative can be established helping to provide a "true North" for all stakeholders involved in the change.
- this vision helps to guide a target state, the destination that describes the methods, behaviors, and working environment that the change recipients and change agents are aspiring to.
- getting to the target state will require that the change agent and change recipients collaborate on a set of change actions, examples could include coaching, self learning and facilitated workshops.
- participating in these various actions will require commitments from the change recipients, change agent, change sponsors, as well as any other packet stakeholders who may be impacted by the suggested change. This commitment typically comes in the form of time required to learn new methods, experiment on new ways of working, as well as occasionally in the form of budget required to upgrade workspaces and other working
- if change recipients and other change stakeholders honor their commitments they should receive benefits in the form of improved productivity, more satisfied customers, and better working around moral.
- In order to ensure that the change initiative is moving towards its target state and that change recipients are receiving appropriate benefits, measurable success criteria are tracked throughout the change process. This metric is typically expressed in the form of rate of adoption a particular methods, and sometimes in improved delivery performance
- finally any change initiative needs to be supported by good communication across the agent recipients and all stakeholders. Specific modes and methods of communication are marked down. here.
Danny starts by filling out the canvas on his own
Armed with this canvas, Danny hopes that he can be more successful in helping his team change the way they work and save the project that he is working on.
Danny lists all of his teammates as his change recipients. This includes the other developers, and testers that are on his team. Upon taking a second pass at the change recipients section, Danny realizes that he should also include his manager, the business analyst on the team, as well as his most active business stakeholder.
Danny feels that the big urgency that's causing a need for change is that his team applies delivery methods and practices in a very ad hoc and inconsistent way, this is causing delivered to be both slow and extremely unpredictable when it comes to the quality of what is shown to the client.
Danny feels that an inconsistent and ad hoc approach to meeting with customers and gathering their needs into requirements as well as demoing working software is significantly contributing to an environment of poor collaboration between his team and his business customers.
Danny's vision for his team is that of a top performing that can execute using textbook agile, enabling the kind of environment that he tends to read about in other places.
Danny wants to adopt the management practices of scrum, the technical practices of extreme programming, the measurement and metrics approaches prescribed by lean, and some of the modeling practices described in the agile modeling method to enable his team to become best in class.
Danny wants to hire an external expert to coach the team on a part-time basis in all the methods and practices necessary to become successful.
Danny thinks that learning and adoption as well as usage of the new methods and tools will take approximately 6 hours a week for his manager, four hours a week for his customer, and approximate two hours a day for the rest of the team. Danny feels that that his team can more than make up for lost time thanks to the extra performance boosting the gain from these methods.
Danny sees big benefits in following this approach, he is hoping his team will be able to deliver approximately 3 user stories per month. He also hopes that he's going to improve his customers satisfaction using the net promoter score approach, and trying to get a score of nine or higher.
Danny would consider this change initiative to be successful if it results in both she and one other team member becoming an "agile expert", He's also hoping that the remaining members of his team have gained some good proficiency in some of the methods and tools, they don't need to be experts, but he wants them to have some reasonable aptitude and experience.
Danny wants to rely on classic agile style meetings to communicate progress of not only the project but the change management plan as well. Danny would like to make sure that his team runs daily standups, that testers and the rest of the team collaborate at least weekly in an attempt to promote things to the testing environment, and that customers try to replenish a new set of user stories every two weeks. He'd also like to make sure that customers are working with real code in production once a month and finally the team needs a monthly respect respective to make sure that their change management plans are on the right right track.
Now that Danny has completed the canvas he is ready to show it to his team.
Danny was now prepared to share his canvas. Danny began to socialize this canvas with his various team members, stakeholders and other interested parties. Danny was careful to communicate that the purpose of showing the Change Canvas was to modify it to suit the needs of all the various change recipients and stakeholders and not dictate an approach. As a result the change model underwent drastic modification.
The first people Danny talked to was his manager and primary business stakeholder of the project. He wanted to make sure he had some initial support to go talk to his remaining team members.
Danny's manager immediately noticed that his canvas did not include the project manager. The current project manager was only a part-time person responsible mainly for managing coordination and issues related to dependencies between his team and the business and infrastructure related teams. Regardless, the manager felt it was important to get him more involved in this project including any suggested changes around how the team was delivering.
Both the business stakeholder and project manager thought it was important to have a director level executive act as a sponsor and champion for any new approaches that the team was going to take. If there is going to be any success using agile or lean methods both felt strongly that executive support was required.
All four of these change recipients felt that the primary urgency for change was that the team was not going to be up to deliver a product that was of good quality and make the customer's needs by a certain date. Any change to delivery approaches or methods had to support this business-critical date. People's jobs were on the line, and any suggested changes to the way people were working at the pragmatic and support this outcome.
The biggest impediment to making this date was the fact that it was taking too long for the delivery and customer teams to resolve issues that impacted the expected functionality of the solution.
Danny then decided to hold a meeting with the rest of the delivery team.
When scheduling the meeting, a business analyst approached him and suggested that he add a business subject matter expert as another change recipients. The analyst worked very closely with the subject matter expert when defining all business requirements such as business rules, workflow and overall business process. Any change to the way requirements are gathered and validated would directly impact the business subject matter expert.
When Danny met with the team he discussed various problems statements that would resonate with them, and they quickly landed on the idea that the team fundamentally lacks confidence. They internally had no confidence that they would be able to deliver what their customers want it, and they also thought that their customers equally shared this lack of confidence.
Consequently Danny and his delivery team were able to hammer out a vision that spoke of building confidence in both the business and delivery teams are working in a much more collaborative interdependent fashion than they were working in now.
When reviewing this vision, the executive sponsor felt that this problem was systemic across the organization. He also suggested adding the notion that any new methods adopted would also be introduced to other teams who are also facing similar problems.
The team felt that the first step in establishing competence was creating a plan based on a reasonable capable of the deliver, but also making sure that the team delivered in very small batches with the customer frequently checking quality to make sure that delivery was going in the right direction. The team also wanted to make sure that the customers were frequently checking in with the delivery team and directing with user stories would be delivered next. The team finally wanted to make sure that any requirements and design work was done using collaborative techniques borrowed from the agile world such a story mapping, and specifications by example. JAD style workshops would be used such as those recommended by the agile modeling method.
Different members of the team learned at different paces so they felt the best way to facilitate adoption of new methods was to compile the practices that they wanted to use from various textbooks that could be easily purchased. This combination of methods would be supplemented with samples taken from their current project.
That being said, the team was not at all confident in adopting a new way of working without significant help from an expert would already done this before. The team felt strongly that this change was a nonstarter unless they had some help from an agile "expert". They wanted this expertly more than a coach and is a dedicated member of the team until such a time the team felt comfortable in writing in the new model without outside assistance.
Danny worked with his team members, as well as the project manager and other stakeholders to come up with a rough estimate of what would be involved in implementing this change for this team. He felt that the non-core stakeholders of this change effort would probably need at least three hours a week to attend an occasional status meeting, help with issue escalation, as well as to get an overview of what the new approaches entailed.
The product manager who is now becoming more active on the project would need around an hour a day to help with facilitation and coordination.
Team members responsible for solution analysis and requirements gathering would be most impacted. The business analyst and business stakeholder along with the solution designer would need to spend a minimum of two hours a day working with the new techniques throughout the duration of each.
The team felt that developers and testers would be impacted less, with developers and testers needing to spend around an hour a day in order to be able to make sure that they were working in a format that supported a more agile approach.
While not entirely sure what a net promoter score was, most the team thought that improving customer satisfaction was the primary motivator for this change, and so left the net promoter score benefit as is on the canvas.
The original throughput of three user stories a month was not nearly sufficient for this project to be completed when it needed to be. It also does not justify the investment required in learning the new methods and tools. After much discussion, the team cautiously agreed chopping throughputs 6 users towards a month, with the caveat that they would check this number very carefully to see if it was realistic.
The executive, manager and client stakeholder also wanted to make sure that any methods, techniques and learnings that were gained as a result of this change would be captured in a way that could be of use to other teams were suffering from the same problems. All three of these folks agreed that many of the problems that this team are suffering from were typical of other projects being completed within this organization and felt that this change was successful that it should be considered for the rest of the organization.
Everyone seemed to agree that success meant that team throughput had risen so that the client would be able to deliver a solution that was reliable and support critical business functionality.
The team also felt that this needed to be accomplished while keeping team morale, and not getting this project done at the expense of burning out everybody involved.
Finally Danny worked with all of his chief stakeholders to be on the set of sessions and meetings that he would use to communicate progress of the project and change initiative as well.
Danny was then able to conduct a final workshop with all his stakeholders to review the entire canvas, Danny felt much more confident his chances of success armed with an agile change plan that reflected the needs of his chief stakeholders.
Read More of Lean Change - Chapter 2: Getting Started with the Change Canvas
- a Short History of the Canvas
- the Change Canvas in Action-a Story of Danny the Developer
- Using a Canvas to Represent a Minimum Viable Change
- Guidelines and Practices When Using the Change Canvas
