|
|
STAREAST 2009: What Price Truth? When a Tester is Asked to Lie As testers, our job is to report the current state of software quality on our projects. But in the high-stakes, high-risk business of software development, some may pressure us to distort the message. When projects are late or quality is poor, software managers' reputations-even their jobs-may be on the line. Our testing progress report could be the biggest obstacle to a "green light" project status report or an on-time delivery. When testers see project disconnects-rosy status reports and repeatedly late delivery; managers shutting down open discussions of project risks; managers trying to close down testing that is exposing major bugs; or suggestions to "get creative" with the metrics-we need to beware. Fiona Charles discusses the reasons testers must refuse to compromise reality, how to secure detailed records of project progress and status, and the possibility of having to "blow the whistle"-regardless of the consequences.
|
Fiona Charles
|
|
|
STAREAST 2009: Improving the Skills of Software Testers Many test training courses include the topic of "soft skills for testers," specifically their attitudes and social behaviors. Testers are told that to be effective they need a negative mindset and a negative approach. Krishna Iyer and Mukesh Mulchandani challenge this belief. Having trained more than 5,000 testers in testing skills and more than 500 testers in essential thinking skills, Krishna and Mukesh demonstrate that testers must be creative rather than critical, positive rather than destructive, and empathetic rather than negative. Join them as they lead exercises in creative thinking, critical writing, and collaborative speaking to improve your eye for detail, nose for sniffing out defects, and ear for bias. Eliminate the old beliefs that hinder testers and find out how to deconstruct them and inculcate new, more powerful ones into your test organization.
|
Krishna Iyer, ZenTEST Labs
|
|
|
STAREAST 2009: Five Things Every Tester Must Do Are you a frustrated tester or test manager? Are you questioning whether or not a career in testing is for you? Do you wonder why others in your organization seem unenthusiastic about quality? If the answer is "yes" to any of these questions, this session is for you. Julie Gardiner explores five directives to help testers make a positive impact within their organization and increase professionalism in testing. Remember quality-it's not just effort, it's effort and quality; it’s date and quality; it's functionality and quality. Learn to enjoy testing and have fun-the closest job to yours is blowing up things in the movies. Relish your testing challenges-it;s you against the software and sometimes, it seems, the world. Choose your battles-take a stand on issues that are vital and let the small things go. And most importantly, remember that the only real power we have springs from our integrity-don't sell that at any price.
|
Julie Gardiner, Grove Consultants
|
|
|
Retrospectives in Action - Looking Back at the Conference In this last-day, last-hour session, Jean Tabaka invites you to apply a fundamental practice of agile teams-retrospection. Jean guides you in facilitating your own retrospectives about the Agile Development Practices conference you have just attended. You will mine your experiences by creating a timeline of your conference observations, your high points, your low points, and your conference activities. Each team will then use their timeline of observations, impressions, and actions to interpret how their overall conference experience might impact what they could do differently at the next conference, what they would recommend as changes for the Agile Development Practices conference organizers, and what they might recommend even outside of the conference context. Finally, each team will prioritize their recommendations to be collected and delivered to the Agile Development Practices conference organizers.
|
Jean Tabaka, Rally Software Development
|
|
|
Scaling Agile Up and Out: A Tale from the Trenches It seems like everyone wants to scale their agile teams. As projects grow in scope, the agile approach to software development needs to scale up to larger team sizes. Agile also needs to scale out to handle geographically distributed teams as businesses expand into new markets and seek the best talent available globally. These are challenging propositions for many teams. Ade Miller talks about his experiences at Microsoft®-scaling agile up on the Visual Studio® Tools for Office team and scaling out on the radically distributed teams within the patterns & practices group. Ade covers the approaches used-some which worked well, some not so well-and shares that the important thing is what was learned and how this new knowledge can be applied successfully to other projects. Ade presents some successful practices when scaling agile projects as well as some key pitfalls to avoid on your projects.
|
Ade Miller, Microsoft Corporation
|
|
|
Agile Growing Pains Often, examples of agile successes are presented in the context of small, software-only development teams. Michael Kirby describes what it took to deploy agile development techniques in a large, embedded software development organization. Michael describes the successes-and some of the failures-of deploying agile development in Xerox's Production Printer Development Team. Learn about the adaptation of Scrum (what happens when the project manager gets voted off the island), agile planning (what's a user story when the only observable behavior is to power up the device), and test-driven development and automated acceptance testing (until a paper jam occurs in the middle of the night). Michael describes the cultural barriers encountered at Xerox in trying to transition a large development team from "traditional" software development to a more agile development approach.
|
Michael Kirby, Xerox Corporation
|
|
|
Mistakes Agile Teams Make The road to hell is paved with good intentions-with a special section reserved for those who have tried to "go agile". Agile adoption can fail because a number of common, large-scale, organizational issues. A lack of executive-level support can squash promising improvements among the day-to-day producers. Sometimes the organization is in such disarray that delivering perfect features perfectly wouldn't keep customers satisfied. While these are real and important, J. B. Rainsberger suggests you'll find it more productive to focus on issues over which you have real influence. J. B. describes a few relatively simple mistakes, the warning signs to look for, and how to solve the problems. Hear useful stories from an experienced agile coach that include, "If I'd only known then what I know now ..." You'll laugh, you'll cry, and with luck, you'll catch a problem or two before it blows up on you.
|
JB Rainsberger, Diaspar Software Services
|
|
|
Agile Project Inception: Escaping the Waterfall Whether you are working on a new development effort or the next release of an existing system, you are probably required to make a compelling business case for the proposed work to clear an approval committee's "go/no-go" process. As an approval prerequisite, many organizations require big up-front planning and estimating resulting in a "complete" project plan including dates, costs, and resources. However, a key aspect of agility is an incremental, just-in-time approach to planning and estimating.
|
Kenny Rubin, Innolution
|
|
|
Maximizing Team Dynamics and Overcoming Dysfunction in Agile Environments Change can be painful, but staying stagnant can hurt even more. Deciding to "go agile" may be the right choice for many companies, but seeing Scrum or XP as the next silver bullet can be a mistake, or perhaps the right medicine at the wrong time. In the rush to be faster, better, cheaper, or super-innovative, it's possible to become trapped in organizational dysfunction, even to the extent whereby good medicine won't work. When companies seek to "become agile," what roadblocks might they hit that could increase risk of failure? Michael Mah presents examples of companies that have overcome problems, plus a few who didn't.
|
Michael Mah, QSM Associates, Inc.
|
|
|
A Lean Approach to Managing the Project Portfolio Whether you've been agile for a while or are thinking about it, you have one thing in common with every other software team I've encountered. You have too much work to do. One way to organize your work is with a project portfolio. But if your portfolio is an "as desired" portfolio, you still haven't solved the problem of too much work. Fortunately, taking a lean approach to managing the portfolio helps make those problems of "desired" and "too much work" transparent. Johanna Rothman discusses the several choices you have in managing the portfolio. She presents a project portfolio plan at the highest level and the lowest level, and describes how to apply rolling wave planning to your project portfolio. Johanna discusses ways you can evaluate the projects in your portfolio, whether it's a kanban board, a fixed queue, a fixed timebox, or other evaluation approach.
|
Johanna Rothman, Rothman Consulting Group, Inc.
|
