The second edition is now available! The Art of Agile Development has been completely revised and updated with all new material. Visit the Second Edition page for more information, or buy it on Amazon.
The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.
Sometimes I like to imagine software development as a pulsing web of light, with blips of information flowing along lines from far-flung points. The information races towards the development team, which is a brilliant, complex tangle of lines, then funnels into a glowing core of software too bright to look at.
I'm a little weird that way.
There's truth to the idea, though. Software development is all about information. The more effectively your programmers can access and understand the information they need, the more effective they will be at creating software. The better information customers and managers have, the better they can manage the schedule and the flow of feedback to the programmers.
Communication in the real world is a lot more messy than it is in my image. There are no glowing lines to sterilely transport information from one brain to another. Instead, people have to work together. They have to ask questions, discuss ideas, and even disagree.
This chapter contains eight practices to help your team and its stakeholders collaborate efficiently and effectively:
Trust is essential for the team to thrive.
Sitting together leads to fast, accurate communication.
Real Customer Involvement helps the team understand what to build.
A Ubiquitous Language helps team members understand each other.
Stand-Up Meetings keep team members informed.
Coding Standards provide a template for seamlessly joining the team's work together.
Iteration Demos keep the team's efforts aligned with stakeholder goals.
Reporting helps reassure the organization that the team is working well.
The purpose of this étude is to explore the flow of information in your project. If you're new to agile development, you may use it to help you understand how collaboration occurs in your project, even if you're not currently using XP. If you're an experienced agile practitioner, review Chapter 12 and use this étude to help you modify your process to remove communication bottlenecks.
Conduct this étude for a timeboxed half-hour every day for as long as it is useful. Expect to feel rushed by the deadline at first. If the étude becomes stale, discuss how you can change it to make it interesting again.
You will need white, red, yellow, and green index cards; an empty table or magnetic whiteboard for your information flow map; and writing implements for everyone.
Step 1. Start by forming pairs. Try for heterogeneous pairs—have a programmer work with a customer, a customer work with a tester, and so forth, rather than pairing by job description. Work with a new partner every day.
Step 2. (Timebox this step to 10 minutes.) Within your pair, discuss the kinds of information that you need in order to do your job, or that other people need from you in order to do their job. Choose one example that you have personally observed or experienced. If you can't think of anything new, pick an existing card and skip to Step 3.
Information usually flows in both directions. For example, during an iteration demo as the example, the flow may be the developers asking if the software behaves correctly. Alternately, it may be the customer asking what the software actually does. Choose just direction.
Reflect on all of the times you remember needing or providing this information. How long did it take? For information you needed, think of the calendar time needed from the moment you realized you needed the information to the moment you received it. For information you provided, think of the total effort that you and other team members spent preparing and providing the information.
Next, think of the typical time required for this piece of information. If the typical time required is less than ten minutes, take a green index card. If it's less than a day, take a yellow index card. If it's a day or longer, take a red index card. Write down the type of information involved, the group that you get it from (or give it to), the role you play, and the time required, as shown in Figure.
Step 3. (Timebox this step to 10 minutes.) Within your pair, discuss things that your team can do to reduce or eliminate the time required to get or provide this information. Pick one and write it on a white card.
Step 4. (Timebox this step to 10 minutes.) As a team, discuss all of the cards generated by all of the pairs. Consider these questions:
Where are the bottlenecks in receiving information?
Which latencies are most painful in your current process?
Which flow is most important to optimize in your next iteration?
What is the root cause of those latencies?
What will you do next iteration to improve information flow?
After everyone has had a chance to share their cards, add them to the table. Place colored cards on the table so that the cards visually show information flow. For example, if an interaction designer gets information about usage from real customers and gives it to the development team, those two cards would be placed side by side. Place white cards underneath colored cards.