It's fashionable these days to decry the command and control style of management. Although self-organizing teams are all the rage, managers are still responsible for ensuring that teams perform the work that needs to be done and deliver value to the organization. If you are or have been the big boss, you don't just wake up one morning as a different person. Esther Derby shares the servant leader way to think about management that moves from mandate and monitor to guide and support. She explains-and shows you how to avoid-the oscillating “too hands-off/too hands-on” pattern that often follows the decision to eschew command and control management in favor of a more collaborative, supporting model. Join Esther and take back new tools for forging a trust-based relationship between managers and the teams for which they are responsible.
Why do we insist on calling people "resources"? If software projects were a factory, people would be fungible-interchangeable equipment just like desks and computers. Because software development is highly creative work and not a manufacturing factory, we need to manage people as human beings, not as tasks or resources. Johanna Rothman describes how to find and develop the right people for your teams and projects-people who fit your culture, share your values, and will become integral parts of your team. She explores what skills make a team great and how great managers model those skills and reward people who use them to help the project. Find out how to empower your team, including protecting it from bad influences, making sure the team has what it needs, and helping team members learn to be accountable to each other. It's the people working in teams-and not their managers-who make software projects successful.
The road to the financial ruin experienced on Wall Street during the past two years was paved with ineffective risk management strategies. While risk management theory continues to evolve, implementation of that theory often fails, especially when it comes to software. Though most executives readily acknowledge risk management is an essential practice for software projects, few can point to accomplishments and sustainability of their organization’s software risk efforts. Why is it so difficult to build and sustain effective software risk management? Do risk management’s intellectual demands exceed human capability? Are hidden forces thwarting our efforts to build and sustain good practices? Payson Hall describes the human challenges inherent in developing and sustaining an effective risk management program and why many risk management efforts become paradoxical victims of their own success.
Software defects bug everyone. If your organization is like most and you have a large queue of defects waiting to be fixed, this session is for you. It's probably not realistic to think we'll get around to fixing all of these bugs; so, we need to consider another approach. Lisa Crispin explains how agile teams address defects and how you can apply an agile approach to defects whether or not your development approach is "agile." Explore with Lisa ways to deal with a giant pile-or database-of old bug reports and which of the many, available defect tracking systems to consider-if you need one at all. See examples of alternatives to traditional bug reporting and how to shift your team's mindset toward preventing bugs in the first place. Get new ideas for taming your backlog of defects and discover ways your team can work together to minimize or eliminate bug reports all together.
Your company is ready to launch its new product. How will it perform under real-world conditions? Will it meet the needs and expectations of the users? Will it operate on all the platforms and configurations for which it was designed? With the future of the product, your company, and perhaps your job depending on the answers, beta testing is a great way to maximize your chances of success. Beta testing provides empirical metrics that prove or disprove that your product will meet clients’ expectations, providing you with input for necessary course corrections in the product. Rob Swoboda explains the process of beta testing as well as the key concepts needed to plan, execute, and evaluate a successful beta testing effort. Rob shares his insights into the practices he employs to design and manage high-priority beta test efforts and offers you the keys to succeed in your own beta test program.
Erik Boelen starts his risk-based testing where most others stop. Too often, risk-based test strategies are defined in the initial test plan and are never looked at or used again. Erik explores how a dynamic, living risk-based testing strategy gives testers a vital tool to manage and control testing activities and identify the infrastructure they need to perform these activities. Find out how to use your risk-based testing strategy as a tool for negotiations among the different stakeholders. Take on the important role of risk mediator for all of the parties in the project. The risk-based test strategy is a tool you can use to defend testing’s need for time and resources, especially when late delivery is possible. Use your risk-based strategy to drive and manage exploratory testing sessions.
Is your organization releasing applications that target multiple mobile devices, platforms, or browsers? If so, you have faced-or soon will face-the challenge of choosing and setting up a test environment for these devices and platforms. Nat Couture shows how to develop a cost-effective application test environment to mitigate the risks associated with deploying mobile applications. He shares his latest research on mobile devices, mobile platforms, and mobile browser usage, and explains in detail what you need to consider when choosing a test environment. Learn how to select a winning combination of device-specific simulation, platform-specific simulation, and browser-specific simulation-coupled with tests on the actual devices. Build a mobile device testing program that reduces cost, increases coverage, and helps achieve the level of confidence you need to release mobile applications into production.
Continuous integration is one of the key processes that support an agile software development and testing environment. Sean Stolberg describes how a traditional software tester-transitioning to an agile development environment-put a continuous integration infrastructure in place. In doing so, he helped improve development practices and made possible his team’s transition to agile testing. Sean discusses his team’s initial motivations for adopting agile development practices and dives into the nuts-and-bolts implementation details. He shares their post-assessment of the implementation using Martin Fowler's “Practices of Continuous Integration” and concludes with a retrospective on implementing and promoting continuous integration within the context of agile testing. Find out how continuous integration can help improve your testing results and the quality of the software your team delivers.
Sean Stolberg, Pacific Northwest National Laboratory
Over the years, experts have defined testing as a process of checking, a process of exploring, a process of evaluating, a process of measuring, and a process of improving. For a quarter of a century, we have been focused on the internal process of testing, while generally disregarding its real purpose-creating information that others on the project can use to improve product quality. Join Lee Copeland as he discusses why quantifying the value of testing is difficult work. Perhaps that’s why we concentrate so much on test process; it is much easier to explain. Lee identifies stakeholders for the information we create and presents a three-step approach to creating the information they need to make critical decisions. He shares key attributes of this information-accuracy, timeliness, completeness, relevancy, and more.
Many test leaders believe that development, business, and management don't understand, support, or properly value our contributions. You know what-these test leaders are probably right! So, why do they feel that way? Bob Galen believes it’s our inability and ineffectiveness in communicating-selling-ourselves, our abilities, our contributions, and our value to the organization. As testers, we believe that the work speaks for itself. Wrong! We must work harder to create the crucial conversations that communicate our value and impact. Bob shares specific techniques for holding context-based conversations, producing informative status reports, conducting attention-getting quality assessments, and delivering solid defect reports. Learn how to improve your communication skills so that key partners understand your role, value, and contributions.