|
The Technical Exchange consisted of sessions that brought people together and allowed them to learn from each other. The emphasis of Technical Exchange sessions was learning, interaction, concrete outcomes….and having fun! Whether you were an expert or a beginner there was something new to learn as you worked with others to broaden your horizons and enriched your knowledge.
Scheduled Technical Exchange Sessions
 |
 |
Technical Exchange Abstracts
| E1 |
Agile Contracts (W180)
Mary Poppendieck, Poppendieck.LLC & Christine Moore, Caribou Lake Software |
|
Agile contracts: These two words together in one phrase just look odd - or at least they seem to be at odds with each other. Contracts have played a very important role in the business of software development; in fact, much of this work is in fact done 'under contract'. Organizations adopting agile methodologies are finding it hard to write contracts for software development without compromising the core values and practices. The Agile Contracts workshop is your chance to help the agile community identify ways contracts can be structured and worded to support agile software development. A pre-conference web site has been established for conference attendees to share their thoughts, ideas, and even contract samples! Visit the web site and get in your two cents now! www.leantoolkit.com/agilecontracts.htm |
| E2 |
Evaluating and Documenting Alternatives to Certification (W180)
Clyde Cutting, independent & Gary Jedynak, Summerhill Associates |
|
Martin Fowler led a discussion on Paying For Better Value at the Agile Universe 2002 conference. It posed the question: “How do we make it accepted that able people who are expensive end up being better value than cheap, less able developers?”
° What makes an expert Agile software developer? How do we prove that we are one? We believe the pattern of Expert Capability Maps answers these questions. In this workshop we will all share our perspectives and assess our own capabilities. If you are an expert you will leave with the proof of it. If not, you will leave with a map of your route to becoming an expert.
° The steps to proving expert capability are 1) describe the attributes of an expert, and 2) get external validation we possess those attributes. Help us evaluate and document why certification and other common systems fall short in attempting this. We will also demonstrate that such experts provide economic value far beyond that of those with lesser capability or experience.
° Before the conference please join our AgileAssessment list to contribute to creating an Expert Capability Map for Agile software development, using Behaviorally Anchored Self-Assessments. We will also be posting the evolving documents (does not require list membership).
|
| E3 |
Customer Collaboration: Challenges and successes in practice (G90)
Helen Sharp, Open University & Hugh Robinson, Open University |
|
An important principle in agile methodologies is to value customer collaboration over contract negotiation. In XP, for example, this principle is instantiated through the practice of having an end user on-site, someone who is available to answer questions, resolve disputes and set small-scale priorities on an ongoing basis. Other agile methods suggest alternative approaches. This form of customer collaboration is different from the traditional approach to requirements engineering where a substantial period of investigation and negotiation takes place to uncover the client's requirements.
The session will share, and then disseminate to a wider community, practitioners' experiences with, and insights into, customer collaboration within an agile environment.
|
| E9 |
Enterprise Continuous Integration Limitations and Challenges (T90)
William E. Caputo, ThoughtWorks |
|
Continuous Integration as discussed in the Extreme Programming literature and elsewhere is largely focused on the development, integration and deployment of a single software product. Many IT shops however have additional problems to solve, problems that result from operating at an enterprise scale.
This session will determine issues and limitations in scaling Continuous Integration to the enterprise, and identify strategies for overcoming these issues and limitations.
|
| E5 |
Exploring Motivation (W180)
John Nolan, Connextra & Rachel Davies, Amarinda |
|
Many organizations attempt to increase their productivity by the use of employee reward schemes. Over the years, an increasing body of research has grown suggesting that the use of rewards to move individuals to action may have negative effects on their team working and the quality of their work products in the long term.
The objective of the session is to raise awareness of the impact that development practices can have on intrinsic motivation, and to identify ways that the practices in different software development methods (such as RUP, SCRUM, XP, Open Source) affect motivation within teams. Participants will pool their experience to come up with patterns (or anti-patterns) that nurture intrinsic motivation within teams.
|
| E6 |
Clearing Communication Logjams (W180)
Russ Rufer, Pentad Software & Tracy Bialik, Pentad Software |
|
Under a heavyweight process, two individuals can work on the same problem and communicate primarily through the buffer of a 2-inch document. As agile teammates, they would rely instead on many short conversations. Compared to their heavyweight counterparts, it is even more vital for members of an agile team to focus on communication, since the quality of communication relates directly to how smoothly the agile project flows. If communication bogs down, and logjams appear, the agile teammates must unblock themselves to stay on track.
Workshop participants will examine specific and common problems that arise in everyday interactions within teams practicing agile methodologies. Participants will share and assess one another's approaches to a spectrum of communication logjam scenarios.
|
| E8 |
Architectures and Technologies for Agile Development of Enterprise Applications (W90)
Randy Stafford, IQNavigator |
|
Let's cut through the hype and talk about what has really worked. Which technological and architectural choices have best facilitated agile development - early and continuous delivery, at a pace sustainable forever, of valuable, working, simply-designed software, to ever-changing requirements - in the context of enterprise applications?
In this workshop we'll examine that issue, by breaking down the measures of success of an agile development organization, and correlating architectural and technological choices to performance against those measures, on projects we've experienced. We'll split into small groups to share sanitized characterizations of projects where we've seen correlations, positive or negative, and we'll compile matrices of correlations between such choices and the success measures we break down. We'll describe architectural refactorings we had to do, why we had to do them, and what the end state looked like.
|
| E13 |
Introducing Agile Practices (G90)
Lisa Crispin, KBToys.com |
|
Before you can succeed with an agile project, you must first succeed in introducing an agile process to your organization. As news about agile processes spreads, more organizations are becoming intrigued and are ready to dip a toe into agile waters. The goal of this goldfish bowl discussion will be to share experiences and look for common answers to questions such as:
- What is the best way to convince an organization to try an agile process?
- What types of projects are appropriate for a company's first agile project?
- What are the most important things to do during the first 60 days?
- How do we measure success?
- What obstacles are we likely to meet? How do we overcome them?
- Should we start with an established agile process or should we customize our own?
- How do we handle reluctant or skeptical programmers, customers or bosses?
|
| E10 |
Experience the Transition to an Agile Organization (S180)
Sanjiv Augustine, CC Pace Systems & Bob Payne, Electroglide |
|
Our experience on several XP projects over the past four years has led us to believe that strong management and organizational change is critical to successful adoption and application. Because traditional command-and-control management doesn't align well with XP, a more appropriate agile approach is needed.
In this simulation, participants will simulate a greeting card company. Working together, they will produce greeting cards to specification. The goal of the simulation will be to draw out the differences between traditional and agile organizations to gain a deeper understanding of agile organizational principles.
Visit CC Pace Systems at http://www.ccpace.com to learn more, or go to Electroglide http://www.webdc.com to check out detailed simulation material.
|
| E11 |
Successful Customer Involvement (W180)
Ellen Gottesdiener, EBG Consulting |
|
Do you want to collaborate effectively with your customers? Use "appreciative inquiry" to harvest wisdom from the best of your own experiences with them.
Customer involvement is essential for agile projects. We involve customers in chartering (visioning) and planning releases, defining requirements or stories, creating customer scenarios or stories for testing, conducting prototypes, running and checking acceptance tests, and retrospecting (debriefing) iterations and the project as a whole, and more. Using an appreciative inquiry approach, we'll explore the best ways to actively and positively involve customers and users in your project, from beginning to end. Visit http://www.ebgconsulting.com/adceffectivecustcollab.html for more info on this session.
|
| E12 |
Are Design Patterns Dead? (G90)
Russ Rufer, Pentad Software & Tracy Bialik, Pentad Software |
|
Designs are emerging; small refactorings add flexibility when and where it's needed; the tests tell you where to go. Do design patterns still have a place in an agile world? Some argue the nail is already in the coffin, others contend design patterns thrive in an agile environment. Proponents of these two positions will square off to convince one another of their views. We'll debate Small Up Front Design, its general appropriateness and whether patterns have a role to play, along with the technique of Refactoring to Patterns spearheaded by Joshua Kerievsky. |
| E4 |
Tool Support for Agile Development: Hi Tech vs Low Tech (T90)
Laura Hill, Sun Microsystems Laboratories & Michael Van de Vanter, Sun Microsystems Laboratories |
|
Agile development strives to respond better to the software needs of the customer. And in doing so, agile developers use a variety of tools, some technological typically surrounding the creation, testing, and delivery of the software, and others involving ways of communicating and working with people. In some cases, high-tech and low-tech tools can be brought to bear to solve the same or similar problem in agile development.
The aim of this think tank is to debate whether high-tech or low-tech tools are the best avenues to supporting and improving an agile process. Participants will contribute their own experiences as well as learn from the experiences of others.
|
| E14 |
Requirement Specifications in Agile Projects (T180)
Pete McBreen, McBreen.Consulting |
|
Although "requirements as conversation" works for some organizations, many places still need a written document that can be referred to. Creating an appropriate weight document for Agile projects is the purpose of this session. Specifically this session will look at the enduring specification artifacts that should be preserved by projects as an essential organizational memory of Agile projects. |
| E15 |
What Should Students Know About Agile Development? (W180)
David Socha, University of Washington & Jeff McKenna, Eidogen |
|
As agile practitioners, we know the practices and dispositions necessary for an individual to successfully participate in an agile team. Can we convey this understanding to academia? What do we believe students need to know in order to prepare them for doing agile development? What do we want to see in fresh-out students?
This collaborative session is designed to start this conversation and produce a set of concrete assertions, guidelines and suggestions that are grounded in our experiences as industrial practitioners of agile development.
|
| E16 |
What We Have Learned about Agile Methods (W90)
Forrest Shull, Fraunhofer Center & Laurie Williams, North Carolina State University |
|
For the past year, the Center for Empirically Based Software Engineering (CeBASE) has sponsored three online “eWorkshops” on agile methods. The purpose of each workshop was to build up decision support for software developers. Each eWorkshop started with and then refined a handful of “heuristics” that attempted to describe basic assumptions about the nature of agile methods and how they could be best used for various types of projects.
Using some of the heuristics that resulted from the eWorkshops as a starting point, participants in this session will have the opportunity to contribute their own experiences to refine or expand the list of heuristics.
|
| E17 |
Retrospectives (S90)
Rachel Davies, Amarinda |
|
A retrospective is a meeting, where a team looks back on a past period of work so that they can learn from their experience and apply this learning to future projects. Some agile teams run retrospectives at the end of successive iterations rather than at the end of a project. The benefits of running retrospectives every few weeks rather than months are improved communication across teams and early feedback on development practice.
The objective of this session is to explain the benefits of holding regular retrospectives and give guidance on how to run a retrospective. Participants will get practical experience of how to run a retrospective, using the conference as the subject for reflection.
|
|
|
Technical Exchange Selection Committee
- John Daniels, Fastnloose Ltd, UK (Chair)
- Laura Hill, Sun Microsystems Laboratories, USA
- Mary Lynn Manns, University of North Carolina, USA
- Helen Sharp, Open University, UK
|
