Inspiring Teams to Adopt Best Practices - Tale of Two Projects
•Als PPTX, PDF herunterladen•
1 gefällt mir•573 views
Everyone injects defects. Only the developer or author of a work product is able to build quality into the finished product. How does a Quality or Process specialist inspire smart, tech-savvy Engineers to adopt an effective inspection practice that produces long-lasting results? Introducing a best practice that thrives requires a culture that fosters and expects continuous improvement. The learning experience must be practical and aimed at adult learners. Lastly, the infrastructure should make it easy to follow the process and collect the data to measure improvements. This presentation will discuss the ingredients for successfully inspiring teams to strive for better quality.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (8)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Inspiring Teams to Adopt Best Practices - Tale of Two Projects
- 1. Inspiring Teams to Adopt Best Practices Laura Stanley Franco
- 2. © 2014 Laura Franco Experienced Software Development Leader Process and Quality Change Agent Master of the Difficult Situation
- 3. It was the best of times, It was the worst of times Contrasting doubles
- 4. A Tale of Two Projects Single External Customer • 3 releases in 3 years • New and legacy code • 5 collocated development teams • No functional QA • Small system test team • Customer paid us $X/defect to reach quality criteria Many External Customers • 2 major releases per year • New and legacy code • 15+ distributed development teams • Offshore functional QA team • Small, local system test team • Customers demand low number of critical defects © 2014 Laura Franco
- 5. Project 1 – Single External Customer • Defect quality criteria agreed • One week in-house user acceptance prior to system testing at customer site • Software shipped in parallel with user acceptance week • Defects found during user acceptance counted against quality criteria © 2014 Laura Franco
- 6. The Challenge • One team set a goal – zero defects during system testing at client site • Some developers planned their unit testing • Some did not plan/write down their test cases • Mix of new and legacy code © 2014 Laura Franco
- 7. The Negotiation Written test cases for NEW and LEGACY code Written test cases for NEW code ONLY The Agreement Written test cases for NEW and MODIFIED legacy code © 2014 Laura Franco
- 8. The OutcomeNew Modified Legacy Unchanged Legacy Unit test case found critical defect in unchanged legacy code! Chester, the Process Advocate and Change Agent is born! Developers inspired to plan their unit testing and deliver higher quality code! © 2014 Laura Franco
- 9. Project 2 – Multiple External Customers • Standard quality defect criteria in place • System test shortened from 14 weeks to 8 weeks • Developers ramp down during system test and ramp up on next release • Developers responsible for fixing incoming customer defects © 2014 Laura Franco
- 10. The Challenge • Dramatically reduce rework during system test • Team under pressure to improve quality and add more features • Large number of critical/major defects during system test • High rate of incoming customer found defects © 2014 Laura Franco
- 11. The Negotiation Distributed teams participate in 1 week Mastering Quality workshop Realistic short-term plan to do now Long-term plan for roadmap prioritization The Agreement Local team participate for 3 days Regional quality black belt candidates trained 2 days; observe 3 days
- 12. Surprise! Senior team members + architect only ones who “needed” to attend Team “too busy” so local quality black belt did the team’s pre- work Workshop cut from 3 days to 2 days Participants arrived cold and angry! © 2014 Laura Franco
- 13. Reset! • What to do? • Listen to team’s pain points • Revisit the goal • Focus on circle of control: • Team owns the problem • Team has Quality data • Team has knowledge of module’s weaknesses • Team owns the solution © 2014 Laura Franco
- 14. The Outcome • Team generated: • 33 product improvement and • 71 process improvement ideas • Built a tailored team development process • Distributed 3 code review checklists, requirements and design review checklists • Created short-term action plan for improving quality © 2014 Laura Franco
- 15. Discussion • Is there a Secret Sauce? © 2014 Laura Franco
- 16. Let’s stay in touch: Email Ljdiamond@sbcglobal.net Twitter @CoachLauraF www.linkedin.com/in/laurastanleyfranco/ © 2014 Laura Franco
Hinweis der Redaktion
- Laura Franco has 35 years of experience in software development and management best practices. As a senior leader, she has been instrumental in leading global organizations through the changes required to meet their process improvement objectives that are aligned with business objectives. She collaborates across the entire organization to optimize the results from the software development process with demonstrable quality, schedule, cost savings while achieving strong, positive feedback from the process practitioners.
- I heard recently that life is a series of experiments. With experiments, there are no failures, only bad or good outcomes. The important thing, is what you learn from it. In 30+ years of software development experiments, I have learned good and bad ways to influence people, teams, and organizations to change. Today, I will share some of my stories…
- Dickens, Charles. 1859. A Tale of Two Cities. London: Chapman & Hall.In the novel, ‘A Tale of Two Cities’, Charles Dickens used doubles to show diametrically opposed actions and their consequences. One woman is loving, the other is hateful. One man sees another as a model of who he could have been, had he made different choices.I invite you to examine 2 projects and see what contrasts and parallels you can draw based on your experiences…
- Here are the key characteristics of the two projects in my story. The first project required the transformation of our in-house, mainframe production software to operate according to a single external customer’s business rules, plus the addition of new features. The 2nd project entailed adding new features to software solutions that are used by many customers around the globe. Everyone on the 1st project was located in the same office in the US. The 2nd project utilized teams who often changed the same code, yet worked in remote development centers around the globe.In both projects, there is a small system test team.In the 1st project, we had agreed quality criteria for each stage of system and user acceptance testing. After the first release, we negotiated with the customer that after we met the quality criteria for starting system test at their site, the customer would pay us so much per defect to fix any defects found in order to meet the final production quality criteria. This was based on historical analysis of the time it took us to fix defects during different stages of testing.In the 2nd project, the software was required to meet 3 9’s reliability. In practice, our solutions were becoming mission-critical to our customers, who began expecting 5 9’s reliability.
- With that context, let’s look at Project 1. I was responsible for system testing of the software in our lab before it was delivered to the customer for system testing in their test environment. Before the customer would accept the software into their environment, they came on-site to perform one week of acceptance testing in our lab. To minimize delays in the start of system testing at the customer site, the software was shipped to the customer at the beginning of the customer acceptance test. The agreed quality criteria for customer acceptance counted open defects from our system testing, plus all defects found during the week customer acceptance test.
- The development teams had a practice of running unit test cases. For the most part, the test cases were not designed nor written down. It was easy to find defects during testing.One team leader, Chester, set a goal with his team to deliver their application with zero defects found during system testing at the customer site! How many teams have you known to set this goal?
- To achieve this goal, I encouraged him to set an expectation that the unit test cases be written down and reviewed by the team for both new and legacy code. He readily agreed to do that for any new code, and resisted it for legacy code since that code was running in production already. I asked Chester to do an experiment, one where the developers would write test cases for new and modified code, but not for unchanged code.Done - we had an agreement!
- What happened next was eye opening for Chester and for me. One of his developers wrote test cases for a module where she made small changes to the code. During unit testing, she found a critical defect in the existing code, not the new code that she had added! That team saw that designing unit test cases by looking at the code structure would find critical defects before system test. Chester became my most vocal spokesperson for adopting software best practices. It was no longer Laura trying to persuade the other teams to improve their practices, it was Chester beating the drum. By the way, this team achieved their goal of delivering defect-free software during system testing at the customer site!
- Here is the situational assessment for Project 2. At this point, I am responsible for the quality process improvement program for 7 development centers with 30 plus teams working on different products with unified release dates. Along this quality journey, as developers learned to build in quality through better inspection practices, the system test cycle was shortened from 12+ weeks down to 8 weeks. During the system test phase, the plan was for development teams to be able to ramp down on fixing defects for the current release and ramp up on requirements analysis for the next release. Once the current release was ready to deploy, the teams would have approximately 2 weeks to complete the design work on the next release.
- Within that context, I want to focus on one module. Several remote development teams were needed to meet the demand for features that touched this module. This particular module had one of the highest incoming rate of critical and major defects during system test and during initial deployment at customer sites. The developers were familiar with the buggy code and had insight into which modules were candidates for refactoring or uplifting.
- The Development Director agreed to carve out time for the local team to participate in a 3 day Quality Workshop where the team would produce a realistic short-term plan and a longer-term action plan for reducing the rework cost when adding new features to this module. Instead of bringing the remote teams on-site, management agreed to fly in regional quality black belt candidates who would be trained to hold similar workshops with their local teams.
- The Director and team leader confirmed the participant list. Leading up to the workshop, the team was busy fixing defects for the current release. The local quality black belt candidate agreed to do preliminary analysis of the team’s data as pre-work. Defect data was gathered and analyzed. Domain experts were surveyed to identify problematic areas of the code. The week prior to the start of the workshop, I learned that only a subset of the team would be participating and it would be for 2 days, not 3.The day of the workshop arrived and the mood of the participants was cold and angry. What went wrong?
- The external consultant kicked me and the quality black belt candidates (observers) out of the room. What he learned during the next few hours is that the team felt they were being put through a “Quality 101” course as punishment for the quality of the legacy code they inherited. After listening to their complaints, he gained agreement from the participants to focus on the highest value concerns.The observers were brought back in. The team agreed that they owned the module, the quality data, and could come up with reasonable solutions to improve it. With both words and actions, we assured the team that they had sufficient data and knowledge to create a plan of action that they would own. After calculating their own Cost of Quality, the team analyzed 3 areas: 1) problematic areas of the code based on defect data from system test and the customer experience, 2) their code review checklists used for team inspections, and 3) their documented vs. actual development process. Using this information, they were able to make an improvement plan.
- At the end of the workshop, the team was cautiously optimistic that they could make a difference in the quality of their module. It took management commitment to allow the team the time to implement their ideas. By the end of the next release, the stability and quality of the module in system test and during customer deployments had improved. There was still more work required to make it as robust as needed by the astronomical growth in data it had to handle.
- In retrospective, here is what I learned. Directly involve practitioners in analyzing the data to gain their buy-in and ownership of the problem. Executive sponsorship and team leader agreement is not enough. If they don’t have time to do the pre-work, consider delaying the workshop. Improvement initiatives are more successful when the team does thoughtful analysis of their data and brainstorms ideas to explore together.Do you remember Chester, the team leader from the 1st project? I learned that finding common purpose and using gentle persuasion is effective in building trust and gaining buy-in from leadership and practitioners, especially, when the leadership team and the culture helps them to realize the value for themselves.Did you see parallels from these stories to your own experiences?What questions do you have?
- The bottom line is that it is not my process or my problem, it is the people doing the work who own the problems and the solutions.Have you heard the quote “People are not made for the Sabbath, but the Sabbath is made for us – to give us a day of rest”?In the same way, People are not built to serve the Processes and Tools. Processes ought to be designed to guide the People doing the work. Tools should help automate the Process and make progress and problems visible.