Agile Development Practices East 2010


Pairing in Software Development

Two people working at one computer collaborating on the same deliverable-sounds like double the work and double the costs doesn't it? Not so. Based on empirical studies, pair programming, properly implemented, has been shown to result in higher quality code, better program design, reduced risk, and improved knowledge management-all without a significant productivity hit.

Laurie Williams, North Carolina State University
Paying Down Technical Debt

Your reputation as a development team depends on your ability to deliver quality code-on time, safely, and with the functionality you committed to deliver. Whenever you compromise good design principles or development habits, you make future modifications and maintenance of the system more difficult and costly. We all know that eventually we will need to return to fix our short cuts and mistakes-this is technical debt. Like financial debt, technical debt grows and compounds if we do not deal with it immediately.

Amir Kolsky, Net Objectives
Products and People over Process and Dogma

If people in your organization are spending time "going agile," "being agile," or "doing agile" instead of simply using agile methods that work in your context, this session is for you. Ten years into the agile movement, the original ideals around lightweight process are putting on some pounds and calcifying in dangerous ways. David Hussman challenges you to stop focusing on improving your process and start focusing on improving your product-that thing your process produces-and your people-you know, the ones who do the work.

David Hussman, DevJam

Reality Over Rhetoric: Busting Some of the Myths Around Agile

Many myths surround agile software development: agile has been adopted by the majority of development teams; agile approaches are more effective than waterfall approaches; agile teams don't do up front requirements or architecture; agile teams produce less documentation; it is common for agile teams to take a test-driven approach; and many more. A few of these are true, many are false, and some we're not so sure about yet.

Scott Ambler, IBM Rational

Root Causes of Agile Project Failure

Agile initiatives always begin with the best of intentions-accelerate delivery, meet customer needs, improve software quality, and more. Unfortunately, agile projects do not always deliver on these expectations. Sometimes failure is due to external factors beyond our control; other times we have the power to get things right the first time or turn things around. If you are seeking ways to assure the success of your agile projects, this class is for you.

Jeffery Payne, Coveros, Inc.

Scaling Agile Beyond the Team

Agile methods are helping teams deliver software faster and with much higher quality than ever before. Given the success of agile at the team level, many managers are looking to implement these methodologies across the entire product delivery organization. Launching their adoption efforts, these managers discover many obstacles, misconceptions, and myths that can derail their efforts before they even get started.

Mike Cottmeyer, Pillar Technology

Scaling Scrum: Practical Techniques for Large Organizations

Are you looking for tips to help scale your Scrum deployment to the larger organization? Is the "Scrum of Scrums" concept not working out the way you thought it would? Have you had success with multi-team Scrum projects and want to share what you've learned with others? If you answered yes to any of these questions, join Melanie Paquette in this interactive session where she shares the experiences of organizations that have had success-and challenges-in scaling Scrum.

Melanie Paquette, Research In Motion
Serious Games: Product Planning and Prioritization Using Innovation Games

Perhaps the most vital aspect of building great software is finding the 20 percent of features that represent the 80 percent of functionality your customers really need. The planning and prioritization of these features can truly set a team-and a company-apart from their competitors. Cory Foy presents approaches from Innovation Games® designed around feature discovery and product prioritization. Try your hand at prioritization using the Prune the Product Tree game.

Cory Foy, Cory Foy, LLC

Servant Leadership: The End of Command and Control

The switch from traditional, top-down management to agile project practices poses a dilemma for managers and the team. If agile teams self-manage their work, what does a manager actually do? And without strong guidance from a traditional manager, how do teams organize their work? Dale Emery describes how successful agile teams resolve these conundrums-by adopting a seemingly paradoxical way of collaboration called "servant leadership." A servant leader leads by serving and serves by leading.

Dale Emery, DHE

Story-o-Types: Patterns Within User Stories

Have you noticed that similar stories appear over and over as you develop a system? According to Dan Rawsthorne, stories-those small chunks of work that make up your backlog and provide demonstrable value to the project-can be categorized by purpose: production, analysis, cleanup, business support, infrastructure/environment, or other. Within each of these categories are different "story-o-types"-patterns that define the commonalities among the stories themselves.

Dan Rawsthorne, CollabNet


CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.