Seven Properties of Highly Successful Projects

[Adapted from the book: Agile Software Development: The Cooperative Game, Second Edition]

The following list presents seven properties of highly successful projects along with test questions for each. The first three are the unifying theme across the family. The other properties increase the safety factor for the project. The properties are described in greater detail in Crystal Clear (Cockburn 2005a).

• Frequent Delivery. Have we delivered running, tested, and usable code at least twice to our user community in the last six months?

• Reflective Improvement. Did we get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss our group's working habits, and discover what speeds us up, what slows us down, and what we might be able to improve?

• Close / Osmotic Communication. For Crystal Clear projects: Does it take us 30 seconds or less to get our question to the eyes or ears of the person who might have the answer? Do we overhear something relevant from a conversation among other team members at least every few days? For other Crystal colors, replace those specific times with an inquiry into how long it takes to get a question to the right person, and the frequency of serendipitous discovery.

• Personal Safety. Can we tell our boss we misestimated by more than 50 percent or that we just received a tempting job offer? Can we disagree with him or her about the schedule in a team meeting? Can we end long debates about each other's designs with friendly disagreement?

• Focus. Do we all know what our top two priority items to work on are? Are we guaranteed at least two days in a row and two uninterrupted hours each day to work on them?

• Easy Access to Expert Users. Does it take less than three days, on the average, from when we come up with a question about system usage to when an expert user answers the question? Can we get the answer in a few hours?

• Technical Environment with Automated Tests, Configuration Management, and Frequent Integration. Can we run the system tests to completion without having to be physically present? Do all our developers check their code into the configuration management system? Do they put in a useful note about it as they check it in? Is the system integrated at least twice a week?

One additional property is worth mentioning, one that shows up only on the very best of projects:

• Collaboration Across Organizational Boundaries. Collaboration across organizational boundaries is not a given result on any project. It results from working with amicability and integrity both within and outside the team. It is hard to achieve if the team does not itself have personal safety and, to a lesser extent, frequent delivery. I consider the presence of good collaboration across organizational boundaries as evidence that others of the top seven safety properties are being achieved.

Some tips to help you to have a successful project:

Here is short summary of interesting strategies and techniques for you to consider:

• Exploratory 360°. Pre-project safety check. In a few days or a few weeks, sample the project's business value, requirements, domain model, technology plans, project plan, team makeup, and methodology.

• Early Victory. Small wins help a group develop strength and confidence. Arrange for some early in the project. Walking Skeleton is a great start.

• Walking Skeleton. A tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link the main architectural components.

• Incremental Rearchitecture. Evolve the architecture in stages, keeping the system running as you go. This applies both to the Walking Skeleton and to later revisions.

• Information Radiator. A display posted in a place where people can see it as they work or walk by. It shows readers information they care about without their having to ask anyone a question. Ideally it is large, visible to the casual observer, easily kept up to date, and understandable at a glance, and changes periodically so that it is worth visiting.

• Pair Programming. Two people sit side-by-side, working on the same code. They can be two programmers or a programmer and a user, business specialist, or tester.

• Side-by-Side Programming. Two people sit side-by-side but at different workstations, working on different assignments. The workstations need to be close enough that each person can read the other's workstation simply by turning her head (60 cm–90 cm, or 12"–18"). They help each other as needed.

• Test-Driven Development. The test, or executable example, is written before deciding how to design the code. It serves both as a specification of what to design and as a practice run at using the call sequence to the function. Also called XXD (see page 275).

• Blitz Planning. An index card-based planning session in which the sponsor, business expert, expert user, and developers together build the project map and timeline. Unlike XP's Planning Game, the cards in the Blitz Planning technique show tasks and task dependencies.

• Daily Stand-up Meeting. Everyone in the team meets, standing, for a maximum of 10 minutes to announce what they each are working on and where they are getting stuck.

• Agile Interaction Design. A one- or two-day sticky note and index card-based system usage modeling session, based on the ideas in Software for Use (Constantine 1999). Described in (Patton 2003).

• Burn Charts. A time-based graph of features to be completed over time and features completed so far.

• Dynamic Priority Lists. A list of features to work on in the next iteration or the whole project, prioritized and put into ranking order by the sponsors and updated by them at the end of each iteration or delivery cycle.

• Reflection Workshop. A work pause, for an hour periodically, certainly after each delivery, to reflect on the product, progress, and process.