program selection system

Why does Agile adoption fail? Why do projects doing “textbook” Agile sometimes fail. There is of course no one right answer to these questions. But we suggest the answer can often be gleaned by considering the small things. It’s quite common for projects to follow a “textbook” Agile methodology in the large, while undermining basic Agile principles in the small. We don’t suggest that allowing small problems to flourish is willful neglect. Rather, small, easily ignored nuisances or compromises in the quality of the process and product can become debilitating in size and number.

Management loves the idea of metrics. Project teams, though, hate it: no one likes to be examined like a bug under a magnifying glass. It’s such a shame that this is the perception, because constructive metrics are a project team’s best defense against insanity. When well done, metrics practice is like the martial art of Aikido, which uses an opponents own energy and momentum - and in this case self-interest and responsibilities - to overcome them. This course explores constructive metrics at the release level that can be used as leading indicators.

Testers often get left out in the cold when their development team transition to agile. We’ll look at “the wall” of challenges they face, and explore the support testers need to break through it. The goal is to get testers and QA teams get traction understanding agile development. We’ll poll participants for problems, and explore what they need to know and where to find it. Training, physical logistics, new roles as agile testers and QA managers, adapting traditional testing activities such as audit requirements are just a few of the areas we’ll touch on.

Achieving quality in Agile projects starts with a clear Definition of Done, listing all of the quality criteria that the team wishes to satisfy. It is not easy however, to integrate testing in such a way that the Definition of Done can also be met in later iterations. The natural progression of the required amount of testing effort is to spike sharply at the end of each iteration, and to increase overall in later iterations. This talk is about highlighting the problem areas in maintaining one’s Definition of Done, and about teamwork in testing.

Great software comes from getting the best ideas into the product. Jim McCarthy, who led the legendary turnaround of the Visual C++ group at Microsoft, left Microsoft in 1996 to create a team dynamics laboratory to figure out how to always create a create a high performace team. His lab has focused on this challenge, and has produced 11 protocols for making unanimous decisions, supporting quality thinking, strengthening design iterations, and incorporating feedback, emotions, nobility, and passion into products. Learn about an entirely new class of tools.

When Kent Beck first published Extreme Programming Explained in 2000 he invited us to embrace change. Certainly XP’s and Agile Software Development’s value system and practices support that. However, succeeding in Agile processes now requires more. We’ve come to value the successful delivery of the outcome of our work. It’s the value our “user stories” bring to business and end users that use the software that matter most. If user stories are a means to an end, then it’s the end that matters most.

The purpose of this session is to help non-technical project managers understand the business value of one of the popular agile software development techniques. It is designed to help project managers understand the impact on their projects when their technical teams use the agile technique, test-driven development (TDD).

Audience: (1) Project managers working with agile development teams, and (2) technical agile practitioners looking for arguments to convince their management that agile methods are worthy of adoption.

Description for Program Guide

Many agile teams use Continuous Integration (CI). It’s one of the XP practices that has been broadly adopted. How effective is it? Does the effort of maintaining the CI server save time over a lengthier process that attempts to never break the build? While much anecdotal evidence exists to the benefits of CI there is little supporting data. How do you convince teams that it’s worth adopting and how best to do it? This report covers experiences with CI in a distributed team environment and attempts to answer these questions.

After running a similar workshop with about 20 participants on XP2007 it became clear that getting distributed agile projects right is still a challenge. We got the impression that the community has definitely started to test and execute distributed agile projects. This is obviously driven by the offshoring trend. The interesting phenomenon we are observing is that it is the quality and collaboration aspects of agile practices that leads to an interest in agile practices despite the initial belief that distributed projects would need a more structured waterfallish approach.