|
|
Getting Ready for Your First Iteration - Cancelled Many agilists take little time to prepare for the first planning session of their first iteration on a new project. They dive right into the "work" and, sometimes, ultimately deliver software that lacks much value. Some newly formed teams believe that collocation breeds instant success and altogether ignore early planning. While sitting together always helps, it does not mean that people spontaneously collaborate to create sustainable value. Before holding the first planning session, a bit of preproduction work helps communities learn about each other, the value they will deliver, and their newly forming ecosystem. Pragmatic preproduction does not need to imply empty ceremony or Big Design Up Front (BDUF). David Hussman shares practical ideas for mining value, connecting communities, and creating productive working environments.
|
David Hussman, DevJam
|
|
|
What's More Important: Being Agile or Creating Value? Agile processes and tools have become very popular over the past few years. They promise success where many organizations have had failures. Concerned over struggles to "be agile" and worried that they are not doing everything that every agile consultant says they must, some organizations are worrying whether their projects are really agile or not. Is worrying about whether or not we are really agile the point? Are we, in our rush to be "agile," losing sight of what's really important? Shouldn't our question be, "Are we creating software our customers value?" Jonathan Kohl focuses on understanding why we are developing software, for whom, and what our end-users and team members value. It's easy to get caught up with the newest trends and tools and measure our success based on their adoption, while forgetting about the basics.
|
Jonathan Kohl, Kohl Concepts Inc.
|
|
|
End-to-End Testing in an Enterprise Agile Environment All too often, surprises occur late in development when independent projects-agile or not-at varying stages of completion must merge into a cohesive deliverable. These surprises often result in schedule slips and unfulfilled customer needs. At Intuit, Billie Bell found the root causes of these problems and developed an end-to-end testing model to address them. Billie discovered that test progress reports did not contain the right information to help decision makers anticipate issues early, resulting in design defects being discovered late in development. Join Billie to find ways to prevent end-of-project surprises by identifying dependencies early with use case analysis, mapping functional touch points to test cases, empowering test teams through knowledge sharing across projects, and rethinking standard project milestones.
|
Billie Bell, Intuit, Inc.
|
|
|
Agile Testing: Solving the Agilist's Dilemma One problem with iterative software development is that teams are forced to write and test software incrementally-and repeatedly. Testers know that any change could break features in both obvious and hidden ways. Developers know that a change to their stable design is just around the corner. So, should we go back to designing software all up front and testing the whole product just before delivery? Of course not! So how do we solve this "Agilist's Dilemma?" Rob Myers describes the two popular practices that can solve this dilemma: unit level test-driven development (TDD) and acceptance test-driven development (ATDD). Join Rob to explore the similarities and differences of these agile practices and learn how they support each other. Find out why ATDD is much more than traditional test-automation and how its practice drastically alters the role of the agile tester.
|
Rob Myers, Independent Test Consultant
|
|
|
STAREAST 2009: Test Process Improvement on a Shoestring In these times of economic crisis, cost reduction is usually the #1 motive for test process improvement. Although improvement models such as TMM® and TPI® are very popular, they require formal assessments, process change working groups, extensive implementation programs, and new organizational structures. Instead, you can quickly implement measures that improve your testing process incrementally within your day-to-day activities. Martin Pol presents a set of easy-to-implement measures that can rapidly improve the testing’s contribution to your project’s success-simple risk analysis, pro-active test design, coverage targeting, and novel ways to reuse tools, environments, expertise, and existing testware. Learn how low-budget test process improvement can become a natural behavior for your testing staff. Achieve quick wins by working more closely with development and using what you have instead of buying or creating new tools.
|
Martin Pol, POLTEQ IT Services BV
|
|
|
STAREAST 2009: Seven Key Factors for Agile Testing Success Agile development approaches present unique challenges for testers and test teams. Working in short iterations, often with limited written requirements, agile development teams can leave traditional testers behind. Common testing-related activities, such as user acceptance testing, testing inter-product relationships, and installation testing, need different approaches to fit into agile projects. Lisa Crispin explains seven key factors for testing success within agile projects that you can also apply to more traditional methodologies. Using a whole team approach and adopting an agile testing mindset are among the important components of a successful agile testing strategy. Learn how to overcome cultural and organizational obstacles and barriers to success in areas such as test automation.
|
Lisa Crispin, ePlan Services, Inc.
|
|
|
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
|
|
|
The Business Value of Pair Programming After ten years in the public eye, Pair programming (two people seated together, working on the same programming task) is still one of the most controversial of all the agile programming practices. Managers are concerned about the cost of having "two doing the work of one," and developers are concerned about what will happen to their privacy, their reputations, and their personal performance metrics. Rob Myers dispels these and other concerns by examining the Lean aspects of the technique and by describing subtle (yet high-dividend) benefits. Rob's "Top Ten" contains only benefits that provide clear and significant value to the organization, the team, and the individual. Rob also gives some clear advice on how to try this technique and evaluate the results. You will be better equipped to weigh the costs, benefits, and ROI of pair programming, and to decide whether or not it is valuable for your organization.
|
Ken Pugh, Net Objectives
|
|
|
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.
|
|
|
Test-Driven Development Takes On Embedded Software Embedded software developers face the same challenges as other software developers-unpredictable schedules, poor quality, and the problems that follow. In addition, embedded software developers must overcome the realities of concurrent hardware/software development, scarce target hardware availability, long download times, high deployment costs, as well as the challenges of testing embedded C. Test-Driven Development (TDD), a key agile practice, helps software developers improve schedule predictability and product quality; but very few embedded software engineers apply TDD to their craft. James Grenning describes the problems addressed by TDD, as well as the additional challenges and benefits of applying TDD to embedded software. He provides valuable lessons for doing TDD in the hostile environment of C. After the class, get hands-on experience with James' independent study exercise, "TDD in C".
|
James Grenning, Renaissance Software Consulting, Co.
|
