Better Software - September 2008 - (Page ADP21) CONCuRRENT CLASSES MONDAY, MAY 16, 8:30-5:00 THuRSDAy, NOvEMBER 13, 2:45 p.m. T15 PEOPLE & TEAMS T19 TESTINg Mistakes Agile Teams Make J. B. Rainsberger, Independent Consultant 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. Picking the Right Test Automation Strategy for your Project Gerard Meszaros, Solution Frameworks, Inc. The choice of a test automation strategy is a key determining factor in whether your test automation initiative will repay your investment or become a sink hole devouring time and money. gerard Meszaros helps you understand what kinds of tests you should be running, which ones should be automated, who should prepare the tests, what tools they should be using, and when the tests should be prepared and run. A well-executed test automation strategy is key to preventing defects rather than finding defects after they have occurred. gerard gives you the information you need to make an intelligent decision about how to approach test automation to minimize cost and maximize quality. T20 AgILE DESIgN & ARCHITECTuRE T16 AgILE MANAgEMENT Agile growing Pains Michael Kirby, Xerox 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. Understand the challenges of deploying agile development in an embedded domain and how you can be successful in your organization. Agile Engineering for Architects Ryan Shriver, Dominion Digital Agile development requires architects and architecture, but the current user story-centric approach ignores the qualities of systems, instead overly focusing on features and functions. Sadly, developers who depend primarily on stories miss enormous value-creation opportunities for stakeholders. Developers often think system qualities (non-functional requirements) are someone else’s responsibility to define. Even when defined, these qualities are typically not quantified, instead specified with vague terms such as “faster” and “better.” Ryan Shriver believes that architects are needed to build successful systems. Architects think like engineers and actively participate in quantifying the key system qualities and then designing to implement those qualities. Ryan demonstrates techniques architects can use that are lightweight, but rigorous, and can be applied to agile projects of any size. learn about practical tools and techniques you can immediately apply on your projects—proven techniques that are used in designing and building very complex and robust systems. T17 AgILE PROJECTS T21 SPECIAL TOPICS Scaling Agile up and Out: A Tale from the Trenches Ade Miller, Microsoft Corporation 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 that 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. Introduction to Multi-Stage Continuous Integration Damon Poole, AccuRev A full, continuous integration build and test is a key component of most agile processes. Unfortunately, as systems grow in size through consecutive iterations, these builds can easily take thirty minutes or more. Before you finish the build, other people’s check-ins will invalidate your continuous integration (CI) results. Multi-stage CI solves this problem by limiting projectwide churn and allowing CI to scale to large projects. With Multi-Stage CI, each team does a team-based CI first and then cross-integrates the team’s changes into the mainline code base. Damon Poole introduces the Multi-Stage CI process, discusses its benefits, presents examples of how to implement and automate it in both local and distributed environments. Join Damon as he shows how to avoid pitfalls, such as increased merging overhead and unnecessary integration delays, and describes how to include a variety of stages, such as multi-team integration, QA, code reviews, and more. T18 AgILE PROCESSES Retrospectives in Action: Looking Back at the Conference Jean Tabaka, Rally Software Development 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. Join Jean in a fun look back and a chance to impact future Agile Development Practices conferences! “I liked the ability to hear other views on agility—to [get a] better perspective of what others are doing.” — William Ploch, Project Leader, Energizer CAll 888.268.8770 OR 904.278.0524 TO REgISTER • W W W. S Q E . C O M /A D P R E g 21 http://WWW.SQE.COM/ADPREG
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.