Leading Change from the Quality team
•Transferir como PPTX, PDF•
1 gostou•615 visualizações
Change is hard. Most change efforts fail. Often, to improve software quality we need to influence how other teams do their jobs. This presentation shows a 4 step method to effectively lead change, illustrated by 2 examples.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Leading Change from the Quality team
Semelhante a Leading Change from the Quality team (20)
Último
Último (20)
Leading Change from the Quality team
- 1. Leading Change from the Test Team John Ruberto – Concur, Inc. – Director of Mobile QE
- 4. Tell me about your title Test Manager • Focus is testing • Organizing work around testing Quality Leader •Focus is whole life- cycle & process that leads to software delivery •Influencing outcomes
- 5. Most Changes Efforts Fail Why changes fail John Kotter: Leading Change – Why Transformation Efforts Fail, Harvard Business Review 1. Not establishing a great enough sense of urgency 2. Not creating a powerful enough guiding coalition 3. Lacking a vision 4. Under communicating the vision by a factor of 10 5. Not removing obstacles to the new vision 6. Not systematically planning, creating, short-term wins 7. Declaring victory too soon 8. Not anchoring changes into corporate cultures
- 7. Change is Hard The DREC Curve Ref: MindTools, DREC, etc. Kübler-Ross model 1.Denial 2.Anger 3.Bargaining 4.Depression 5.Acceptance Denial Resistance Exploration Commitment
- 8. Tale of 2 changes • Process / SDLC Change • Moving from 6-weeks to monthly release cycles • Technology Change: • Institute static analysis in our development methodology
- 9. Roles in Change Leadership • Change Leader • Drives the overall process for change • Change Agent • Active Participant • “First Follower” Video • Passionate defender of Status Quo • Actively resists the changes
- 10. Change leadership in 4 steps 1. Build the case for change 2. Plan the change 3. Test the change 4. Rollout and make adjustments
- 11. Build the case for change • Identify the need • Retrospectives • Benchmark other organizations • Defect escapes / escalations • Industry trends / best practices • Ideas from team, innovations, experiments • Root cause analyses • Risk analysis
- 12. Build the case for change
- 13. Example: Defects found in system test Coding errors 39% Coding:Exception Handling 19% Missing Code 9% Requirements: Missing 9% Design: Usability 6% Coding: Missing 6% Design: Functional 4% Coding: Browser Differences 4% Requirements: Wrong 3% Content Localization 1% • Root cause analysis • 70% of errors found in system test were caused by coding errors • How can we improve? (brainstorm) • Idea: start doing static analysis to find errors earlier
- 14. Build the case for change •Think about your audience •Developers •Testers •Product Managers / Product Owners •Project Managers / Scrum Masters •Leaders
- 15. Communicate in the language of your audience • Ideas -> Vision , Features -> Benefits 1000 songs In my pocket Plan Develop Test Release Quicker feedback From customers Automated code- Review buddy MP3 player With small HDD Faster release cycles Static analysis checks As part of the build
- 16. Plan the change • Communicate, communicate, communicate • Organization’s goals • Team meetings, all-hands, 1:1 sessions • Identify people who are: • Impacted by the change • Change agents • Passionate defenders of the status quo • Ask: • What needs to change to make the vision reality? • What is working that we need to preserve? • What worries you?
- 17. The Goals Grid D e s i r a b l e U n d e s i r a b l e Don’t Have Things we have Achieve Preserve EliminateAvoid
- 18. The Goals Grid Achieve Firm completion milestone Regression in only 1 week Automated deployment Definition of Done = “Customer ready” Better content communication across functions (ops, support, etc.) Preserve Demos with support team before release Staged deployment with subset of customers Feature configuration switches Level of documentation (requirements, design, etc.) Avoid Keeping the same practices, only compressing time and making people work OT Embarrassing bugs Double the manual deployments across data centers Using “looming deadlines” to encourage urgency Eliminate “This feature must release on this date” mindset Late scrambles for design activities. Pre-prod test environments instability D e s i r a b l e U n d e s i r a b l e Don’t Have Things we have
- 20. Break out the scientific method https://en.wikipedia.org/wiki/Scientific_method
- 21. Test the change Faster releases Static Analysis Testable prediction We can complete system test in 1 week if we use the new milestone definition A tool exists that will find valid/meaningful coding errors with minimal false positives Experiment Use new milestone, keep 2 weeks in schedule for system test, but try to complete in 1 Identify a list of tools, and try out the most promising. Compare results Refine Locks on change control Found 2 tools that worked well together (complementary results)
- 22. Rollout and Make Adjustments Högertrafikomläggningen - Dagen H (Sept 3rd, 1967)
- 23. Be Persistent • Actively seek out risks and issues • Communicate openly about risks & progress (often) • Ask for feedback: How can we improve this plan?
- 24. Show progress 0 50 100 150 200 250 Month 1 Month 2 Month 3 Month 4 Month 5 Month 6 Defects Detected by Static Analysis
- 25. Summary • Building the burning platform is most important • Speak the language of your stakeholders • Articulate your vision • be in love with the vision, not your particular solution • Communicate, Communicate, Communicate • Before, During, and After • Persist when it gets difficult • Are you still solving the original problem? • Otherwise, pivot to a different solution
- 26. Thank You! About Me @JohnRuberto blog.ruberto.com linkedin.com/in/ruberto Please leave a feedback card Links to materials referenced are here: bit.ly/JRChange About Concur concur.com/careers Travel & Expense Management w/ 35m active users In top 50 best places to work (glassdoor.com)
- 27. Image Credits • Slide 3 : Robert Engberg from flickr creative commons • Slide 9: US Coast Guard (public domain) • Slide 13: (jobs) segagman from flicker creative commons • Slide 13: (code) Pixabay (public domain) • Slide 17: McDonalds Inc. (public domain) • Slide 20: Jan Collsioo (public domain) • Slide 24: Concur, Inc. (with permission)
Notas do Editor
- References to the tools/models/videos here are linked to from this page.
- Story: Imagine a village near a river. One quiet morning, we hear some shouts for help and thrashing in the river. Someone, who can’t swim, is floating downstream. Our hero whips off his shirt, shoes, and dives in the river –saving the poor guy. There is much rejoicing when they return to dry land. The celebrations are cut short, though, when they hear more shouting and thrashing in the river. There are now 2 people in trouble, floating down stream. Our hero recruits a helper, they dive in, and save 2 more people. The celebrations continue. Until… More shouting and thrashing. There are now 5 people in the river. Our hero calmly puts on his shirt and shoes and starts to run away. The village elder shouts at him that he can’t leave now – he is needed more than ever. The hero shouts back, “I’m going upstream to stop people from falling in the river”. Now, finding bugs is valuable, but sometimes you need to go upstream to solve some root causes. Typically, this means leading through some change (process, technology, training, methodology, etc.) and leading change means influencing those outside your direct control. Today’s session is intended to give you some insights on how to lead change.
- I was interviewed a few years back, and one of the questions was “tell me about your title, you call yourself the quality leader. Why not test manager?” The actual title isn’t as important, but your mindset is.
- Kotter wrote an important article on Change Leadership. His focus was larger scale organization change, but some of these ideas are valuable. Notice that of the 8 reasons that change efforts fail, the top 4 are able about getting the organization to understand an agree on the reasons for the change. This is true in my experience. The first step of the model we will review today is “building the case for change” – and that is the most important. The bit.ly link has a link to the full article (available for purchase from HBD). You could instead search for the title with filetype:pdf
- There are a couple of versions of ”Change Curves” available. This one is called the DREC curve, which stands for Denial – Resistance – Exploration– Commitment, which correspond to the stages that people encounter when change is upon them. MindTools, link provided in the Bit.ly, has another model, Shock, Denial, Anger, Fear, Acceptance, Commitment. (sounds like Anakin's transition to the dark side). These Change curve models give advice on how to accelerate the change curve. To help the people get through the negative emotions quicker. There is another model, called the Kubler-Ross model, which shows a very similar pattern. This model was based on research in how people grieve when a loved one passes away. Change is difficult, if the leading change models are comparing change to death…
- I’ll present the change leadership model, and illustrate it with 2 changes that I lead. I’ll show the actual artifacts used during those changes.
- Before jumping into the model, lets talk about 2 roles. The bulk of the presentation is about the change leader role, but lets take a brief aside on the Change Agent. (watch video) Two important takeways: - As you lead change, you will want to find your “first follower” For changes that your peers/leaders are driving, are you being their first follower? They may return the favor in the future.
- The model is very simple, but powerful. We will spend the most time on building the case for change – it’s the most important In planning the change, I’ll show some tools that are useful for setting priorities. You need to test the change, no plan is ever perfect – and your idea might not be fully solving the problem Finally, rollout and make adjustments is important to keep the change permanent (continues beyond the time when you move onto other challenges)
- You may already know what you want to change. Perhaps, you are learning a new practice or tool at PNSQC that you want to bring back with you. Here are some sources of ideas for areas that need to change.
- A previous boss used to ask me, “what is your burning platform for change”. He was asking for the compelling reason for making the change. After researching this topic, I found the analogy that he was using. Imagine you are a worker on this oil platform when it catches on fire. You have a very clear and immediate reason to change your status quo. Leaders who advocate new ways of doing things usually start off with statistics & stories that illustrate why the status quo is not acceptable. They are building that burning platform.
- On one project, we were having difficulty getting through the system test phase. We were finding hundreds of bugs during that phase, so we started tracking the root cause. It turned out that 70% of the bugs were relatively simple coding errors. I held a series of brainstorming sessions with the development team – first showing this data – and asking “how can we improve”. This resulted in the idea to start using static analysis to find the coding errors.
- When communicating with your audience, tailor your communication around what is important for that audience. Developers – productivity, high quality Testers – productivity, high quality Product Managers/Owners – Features, roadmap, customer-facing content Project managers – predictability – efficient Leaders – ROI
- As technical people, we often communicate in details, describing features or technology – assuming that our audience gets the benefits. Successfully leading change often starts off with some marketing parallels – where its good to communicate the benefits first. So, instead of talking about your idea, talk about your vision. Instead of the features/technology, talk about the benefits. This is important for your audience to understand why we need to change. It will also come into play when we start testing our changes. If an idea or technology fails – we often still want to realize the benefit or the vision – so we pivot to a different idea. 3 specific examples
- If you have a large change, you will want to have it called out as part of your organization’s goals. If its not specific, its good to be able to show how your project connects to a higher level goal. For the SDLC change, I had it explicitly called out as a goal for our department. During the SDLC acceleration project, I had 40 1:1 meetings with various participants & stakeholders.
- Fred Nickols described a tool that is very useful for identifing what needs to change, and to communicate back to your participants & stakeholders. Its called the Goald Grid. A link to the full article is included in that Bit.ly link (http://www.nickols.us/strategic_planning_tool.pdf) Tool organizes issues/ideas/worries/hopes into a grid: those things that we already have and those that we want. If we don’t have it, and it’s a good thing, we want to Achieve those ideas If it’s a bad thing, we want to avoid it. If we do have it, and it’s a good thing, we want to Preserve it during the change Finally, if we have it, and its bad, we want to eliminate it with the change.
- Here is the filled out grid for the SDLC acceleration. Most of this content was gathered in the 40 1:1 meetings. I sent a weekly report with the latest version of the grid – this really helped to communicate what was changing and to calm any fears.
- Think about McDonalds. You know where the closest McDonalds is to you. You know what is on their menu. You know how much it cost. You know what it taste like. You know how you are going to feel after you eat it. You have a very high awareness of McDonalds. Yet, they still spend $1B per year on advertisement. Why is that? You have the high awareness because they advertise often, and in many different forms. Think about McDonalds when you are communicating your change. Don’t be afraid to “overcommunicate”, it takes many impressions to get through to people.
- Lets revisit our communication from before, where we talked about the vision first, then the specific idea. Remember the iPod as a 1000 songs in my pocket, vs a MP3 player with a hard-drive. The use of MP3 and HDD was the idea to implement the vision – the next step was to test that idea. As you can imagine, they spent much effort in design, prototyping, and testing to validate that idea. You have an idea that you are driving in your change. Your idea may or may not be the right way to implement the vision (or realize the benefits). You need to test your change. Think of your idea as a hypothesis, and create a way to test to those hypotheses. Refine and iterate, or pivot to a new idea.
- Here are the hypotheses for the 2 change:
- Its time to rollout your change. It might not go smoothly – be prepared. In 1967, Sweden switched from driving on the left side to the right side of the road. They spent years planning and communicating this change. It was called Dagen H. Yet, it didn’t go smoothly that first day. They didn’t give up, but preserved through and everything calmed down in a few days. Likewise, for your change – expect some issues early on and work through them.
- This is my favorite graph from the Static Analysis project – the tool was finding over 200 issues per month early on, but as the developers learned the patterns that the tool would find, they write more resilient code. This cut in half the number of issues found by the tool. The rapid feedback from that tool helped the developers write better code – truly defect prevention.
- Did I mention communication?