|
Managing Software Debt In Scrum, the product backlog is used to prioritize feature implementation based on business value. The product owner manages the product backlog to direct implementation for the greatest possible business value. However, product backlogs that list only system features do not consider the decay of software over time. The resulting “software debt” can eventually sink a project or even an entire product or organization. Chris Sterling explains ways to manage software debt with an eye on the long-term vision and success of the product. Unfortunately, many teams ignore key concepts regarding debt and fall into a “get it done” mentality. They either ignore, or are unaware of, the negative effects of these seemingly small decisions on their future success.
|
Chris Sterling, SolutionsIQ
|
|
Learning to Learn: What You Didn't Learn in School and Why From taking our first steps and saying our first words, through kindergarten, grade school, and college, we are praised, rewarded, and judged on our ability to learn. When we finish formal education and enter the workplace, we discover that we have to start learning all over again. Outside of work, we learn and practice skills in our leisure time-maybe a sport or something artistic, a musical instrument, or beating the monster at the end of level 17. Given the amount of time we spend learning, it is surprising how little we invest in understanding how it’s done. From Dreyfus to De Bono by way of Japanese martial arts, Dan suggests that some of our modern organizational challenges may be due to teachers telling us that copying is cheating and that challenging authority gets you detention. Take away several models of learning and skills acquisition that will help you learn to learn more effectively.
|
Dan North, ThoughtWorks Inc
|
|
Quality Metrics for Testers: Evaluating Our Products, Evaluting Ourselves As testers, we focus our efforts on measuring the quality of our organization's products. We count defects and list them by severity; we compute defect density; we examine the changes in those metrics over time for trends, and we chart customer satisfaction. While these are important, Lee Copeland suggests that to reach a higher level of testing maturity, we must apply similar measurements to ourselves. He suggests you count the number of defects in your own test cases and the length of time needed to find and fix them; compute test coverage-the measure of how much of the software you have actually exercised under test conditions-and determine Defect Removal Effectiveness-the ratio of the number of defects you actually found divided by the total number you should have found. These and other metrics will help you evaluate and then improve the effectiveness and efficiency of your testing process.
|
Lee Copeland, Software Quality Engineering
|
|
Becoming a Lean-Agile Enterprise Many companies have adopted agile by using Scrum on one or more of their projects. Unfortunately, they may be missing the point that agility should be aimed at the enterprise, not merely at the team. Agile enterprises can respond quickly to changing market conditions, competitive pressures, and changing technical environments, thus bringing their innovations to market faster. However, creating an agile enterprise is much more than simply getting teams to adopt Scrum. Alan Shalloway discusses how to use lean thinking to determine where to start using agile methods as well as how to adopt agile throughout the entire enterprise.
|
Alan Shalloway, Net Objectives
|
|
Introducing Change, Avoiding Dysfunction Change can be painful, but staying stagnant can hurt even more. As a manager, how do you decide what should change and how do you know if your organization is ready? When managers seek to improve by introducing new practices such as agile, CMMI, or others, what roadblocks can cause their organizations and teams to reject change-or even worse, to spiral into dysfunction? Michael Mah presents examples of managers who have successfully overcome problems introducing change, plus a few examples of managers who weren't so fortunate. Learn how systems theory plays a role in software development and why complex communication and expert thinking are the penultimate challenges facing many software managers. Discover how accurate and reliable metrics are necessary to reveal patterns that will help you find the right path through an improvement program.
|
Michael Mah, QSM Associates, Inc.
|
|
Demystifying Virtual Lab Management The benefits of a virtualized lab environment for development and test teams are compelling and quantifiable-rapid provisioning and tear down of environments, faster test cycles, and powerful new capabilities to resolve defects. Although some application development teams have experimented with virtual machines and have seen some of the benefits, they've also discovered issues with virtual machine "sprawl," difficulties administering the lab, and lack of virtual private networking. Ian Knox provides solutions to these problems and offers ways to simplify both managing and using virtualization in your development and test environments. Ian describes the basics of virtual lab automation and how you can use virtual labs to solve some of the most pressing and expensive challenges in software quality.
|
Ian Knox, Skytap Inc
|
|
Ten Practices of High-Performance Teams With all the hype about agile, lean, CMMI®, and every other method du jour, we sometimes forget that our real goal is high performance. High-performance software teams consistently deliver products that delight their customers, all while remaining on schedule, keeping with agreed-to functionality, and maintaining high quality. These teams are proud of what they produce and are continuously improving the way they work. Over the past decade, Noopur Davis has worked with many high-performance teams in both large and small organizations. She has discovered that high-performance teams share a number of key practices, regardless of the process they use. Noopur shares these effective practices, including self-direction, openness and transparency, simplicity of work practices, focused use of data, an uncompromising commitment to quality, and others.
|
Noopur Davis, Davis Systems
|
|
Virtual Retrospectives for Distributed Software Teams Project retrospectives are challenging enough when the software development team and stakeholders are together in one location. What happens when the team members are spread across multiple locations, time zones, and continents? John Terzakis describes the key challenges of retrospectives for geographically dispersed software teams and provides solutions he has used to address each challenge. Beginning with a brief overview of the retrospective process, John introduces the concept of a “virtual retrospective” and offers techniques and tips for successfully facilitating them. He identifies cultural, geographical, and site-based issues and risks that can imperil virtual retrospectives and demonstrates collaboration tools to overcome distance barriers. Find out how to conduct retrospective exercises, including a valuable project timeline exercise, when participants are not co-located.
|
John Terzakis, Intel Corporation
|
|
Testing in Turbulent Projects Turbulent weather such as tornados is characterized by chaotic, random, and often surprising and powerful pattern changes. Similarly, turbulent software projects are characterized by chaotic, seemingly random project changes that happen unexpectedly and with force. Dealing with turbulence is about dealing with change. Testing teams must contend with continuously changing project requirements, design, team members, business goals, technologies, and organizational structures. Test managers and leaders should not just react to change; instead, they need to learn how to read the warning signs of coming change and seek to discover the source of impending changes. Rob Sabourin shares his experiences organizing projects for testing in highly turbulent situations. Learn how to identify context drivers and establish active context listeners in your organization.
|
Robert Sabourin, AmiBug.com Inc
|
|
Better Software Conference & EXPO 2009: When to Step Up, When to Step Back Leaders can stifle progress when they unnecessarily interfere with team processes. However, as a leader, you don't want your project to go over the cliff and fail miserably or deliver the wrong results either. There are times when leaders should stand back and let the team work things out for themselves-and other times when leaders should step up and really lead. How do you know which is which? Pollyanna Pixton focuses on collaboration as the key and teaches you how and when to step back and unleash the hidden talent in your organization and teams. Learn how to create an open environment that fosters innovation and creativity and how to let your team members take ownership and hold themselves accountable. Equally important, develop the techniques to step up and lead to keep the project on track without impeding the flow of ideas.
|
Pollyanna Pixton, Accelinnova
|