7 Properties of Highly Successful Projects from Crystal Clear

Extracted from Chapter 2 of Crystal Clear: A Human-Powered Methodology for Small Teams

Lifecycle & Methodology | By Alistair Cockburn | Read time minutes

I recently awoke to the realisation that top consultants trade notes about the properties of a project rather than on the procedures followed. They inquire after the health of the project: "Is there a mission statement and a project plan? Do they deliver frequently? Are the sponsor and various expert users in close contact with the team?"

Consequently, and in a departure from the way in which a methodology is usually described, I ask Crystal Clear teams to target key properties for the project. "Doing Crystal Clear" becomes achieving the properties rather than following procedures. Two motives drive this shift from procedures to properties:

• The procedures may not produce the properties. Of the two, the properties are the more important.
• Other procedures than the ones I choose may produce the properties for your particular team.

The Crystal family focuses on the three properties Frequent Delivery, Close Communication, and Reflective Improvement because they should be found on all projects. Crystal Clear takes advantage of small team size and proximity to strengthen Close Communication into the more powerful Osmotic Communication. Aside from that one shift, experienced developers will notice that all the properties I outline in this chapter apply to every project, not just small-team projects.

By describing Crystal Clear as a set of properties, I hope to reach into the feeling of the project. Most methodology descriptions miss the critical feeling that separates a successful team from an unsuccessful one. The Crystal Clear team measures its condition by the team's mood and the communication patterns as much as by the rate of delivery. Naming the properties also provides the team with catch phrases to measure their situation by: "We haven't done any Reflective Improvement for a while…" "Can we get more Easy access to expert users?" The property names themselves help people diagnose and discuss ways to fix their current situation.

Property 1: Frequent Delivery

The single most important property of any project, large or small, agile or not, is that of delivering running, tested code to real users every few months. The advantages are so numerous that it is astonishing that any team doesn't do it:

• The sponsors get critical feedback on the rate of progress of the team.
• Users get a chance to discover whether their original request was for what they actually need and to get their discoveries fed back into development.
• Developers keep their focus, breaking deadlocks of indecision.
• The team gets to debug their development and deployment processes, and gets a morale boost through accomplishments.

All of these advantages come from one single property, Frequent Delivery. In my interviews, I have not seen any period longer than four months that still offers this safety. Two months is safer. Teams deploying to the web may deliver weekly.

• Have you delivered running, tested and usable code at least twice to your user community in the last six months?

Just what does "delivery" mean?

Sometimes it means that the software is deployed to the full set of users at the end of each iteration. This may be practical with web-deployed software or when the user group is relatively small.

When the users cannot accept software updates that often, the team finds itself in a quandary. If they deliver the system frequently, the user community will get annoyed with them. If they don't deliver frequently, they may miss a real problem with integration or deployment. They will encounter that problem when it is very late – at the moment of deploying the system.

The best strategy I know of in this situation is to find a friendly user who doesn't mind trying out the software, either as a courtesy or out of curiosity. Deploy to that one workstation. This allows the team to practice deployment and get useful feedback from at least one user.

If you cannot find a friendly user to deliver to, at least perform a full integration and test as though you were going to. This leaves only deployment with a potential flaw.

If the team cannot deliver the system to the full user base every few months, user viewings become all the more critical. The team needs to arrange for users to visit the team and see the software in action, or at least one user to install and test the software. Failure to hold these user viewings easily correlates to end failure of the project, when the users finally, and too late, identify that the software does not meet their needs.

Property 2: Reflective Improvement

The discovery that took me completely by surprise was that a project can reverse its fortunes from catastrophic failure to success if the team will get together, list what both is and isn't working, discuss what might work better, and make those changes in the next iteration. In other words, reflect and improve. The team does not have to spend a great deal of time doing this work – an hour every few weeks or month will do. Just the fact of taking time out of the helter-skelter of daily development to think about what could work better is already effective.

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

Property 3: Osmotic Communication

Osmotic Communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work. Several people have related their experience of it much as this person did:

• We had four people doing pair programming. The boss walked in and asked my partner a question. I started answering it, but gave the wrong name of a module. Nancy, programming with Neil, corrected me, without Neil ever noticing that she had spoken or that a question had been asked.

When Osmotic Communication is in place, questions and answers flow naturally and with surprisingly little disturbance among the team.

Osmotic Communication and Frequent Delivery facilitate such rapid and rich feedback that the project can operate with very little other structure. This is why these two properties are the first two listed.

• Does it take you 30 seconds or less to get your question to the eyes or ears of the person who might have the answer? Do you overhear something relevant from a conversation among other team members at least every few days?

Osmotic Communication, which lives from background hearing and communication along lines-of-sight, really only works with small teams. Larger team will set up Osmotic Communication within sub-teams and Close Communication across sub-teams.

Osmotic Communication makes the cost of communications low and the feedback rate high, so that errors are corrected extremely quickly and knowledge is disseminated fast. People learn the project priorities and who holds what information. They pick up new programming, design, testing and tool handling tricks. They catch and correct small errors before they grow into larger ones.

If you set up a war-room work area, be sure to arrange another place for people to go to unwind and do their private email. This allows people to focus when they step into the common area, and find a bit of relief from the pressure by stepping out. Such an arrangement is referred to as a "caves and common" arrangement.

Osmotic Communication generates its own hazards, most commonly noise and a flow of questions to the team's most expert developer. People usually self-regulate here, request less idle chit-chat or more respect for think time.

Even the best success property is unsuitable under certain circumstances. Osmotic Communication is no exception. If the lead designer gets so overloaded and so frequently interrupted as to be unable make progress on anything, she needs a work place with no interruptions at all and extremely limited communications with the team, a Cone of Silence, I call it. Many lead designers use the hours from 6pm to 2am as their Cone of Silence, but it is better for all involved if an acceptable Cone of Silence can be set up within normal working hours. The Cone of Silence strategy is described in detail elsewhere.

Property 4: Personal Safety

Personal Safety is being able to speak when something is bothering you, without fear of reprisal. It may involve telling the manager that the schedule is unrealistic, a colleague that her design needs improvement, or even letting a colleague know that she needs to take a shower more often. Personal Safety is important because with it, the team can discover and repair its weaknesses. Without it, people won't speak up, and the weaknesses will continue to damage the team.

Personal Safety is an early step toward trust. Trust, which involves giving someone else power over oneself, with accompanying risk of personal damage, is the extent to which one is comfortable with handing that person the power. Some people trust others by default, and wait to be hurt before withdrawing the trust. Others are disinclined to trust others, and wait until they see evidence that they won't be hurt before they give the trust. Presence of trust is positively correlated with team performance (Costa 2002).

When a person sees that others won't betray or damage her based on the information she reveals, she will reveal information more freely, which will speed the project. Therefore, Personal Safety is the critical property to attain.

• Can you tell your boss you mis-estimated by more than 50%, or that you just received a tempting job offer? Can you disagree with her about the schedule in a team meeting? Can people end long debates about each others' designs with friendly disagreement?

Trust is enhanced with Frequent Delivery. When the software is delivered, people recognise who did their share of the work and who shirked, who told the truth, who damaged or protected whom, and who, despite their superficial manners, could be trusted along which dimensions. With Personal Safety, they speak from their heart during the Reflective Improvement sessions.

Personal Safety goes hand in hand with amicability, the willingness to listen with good will. The project suffers when any one person on the team stops listening with good will, or loses the inclination to pass along possibly important information. In addition to personal skill, a project's forward progress relies only on the speed of movement of information across people ("meme-meters per minute", if you will).

Be careful, though, not to confuse Personal Safety with politeness. Some teams appear to have Personal Safety in place, but actually are just being polite because they are unwilling to show disagreement Covering their disagreements with politeness and conciliation, they don't detect and repair mistakes that are present.

Property 5: Focus

Focus is first knowing what to work on, and then having time and peace of mind to work on it. Knowing what to work on comes from communication about goal direction and priorities, typically from the Executive Sponsor. Time and peace of mind come from an environment where people are not taken away from their task to work on other, incompatible things.

• Do all the people know what their top two priority items to work on are? Are they guaranteed at least two days in a row and two uninterrupted hours each day to work on them?

Just knowing what is important isn't enough. Developers regularly report that meetings, requests to give demos, and demands to fix run-time bugs keep them from completing their work. It quite typically takes a person about 20 minutes and considerable mental energy to regain their train of thought after one of these interruptions. When the interruptions happen three or four times a day, it is not uncommon for the person to simply idle between interruptions, feeling that it is not worth the energy to get deeply into a train of thought when the next distraction will just show up in the middle of it.

People asked to work on two or three projects at the same time regularly report that they are unable to make progress on any one project. It seems to take an hour and a half for a person to regain her train of thought after working on a different project.

Among the experienced project managers that I interview, the consensus is that about one and a half projects is the most that a person can be on and stay effective. By the time a third project is added, the developer becomes ineffective on all three. Contrast this with the inexperienced managers who, underestimating the cost of switching between projects, assign developers to work on three to five projects at the same time. I encountered one developer assigned to 17 projects simultaneously! You can imagine that he barely had time to report at the various meetings his ongoing lack of progress on all fronts.

Property 6: Easy Access to Expert Users

Continued access to expert user(s) provides the team with:

• A place to deploy and test the Frequent Deliveries,
• Rapid feedback on the quality of their finished product,
• Rapid feedback on their design decisions, and
• Up-to-date requirements.

Researchers Keil and Carmel published results showing how critical it is to have direct links to expert users (Keil 95). Surveying managers who had worked both with and without easy access to real users, they write:

• "…in 11 of the 14 paired cases, the more successful project involved a greater number of links than the less successful project… This difference was found to be statistically significant in a paired t-test (p<0.01)."

Their research led them to a specific recommendation: "Reduce Reliance on Indirect Links." In other words, get real access to real users.

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

All very nice, but how many users, and how much time?

Even one hour a week of access to a real and expert user is immensely valuable. The more hours each week that an expert user is available to a team, the more advantage they can take of that proximity. The first hour, however, is the most crucial.

The other thing that is important is the length of time until a question gets answered. If a question won't be answered for another three days, the programmers are likely to put into the code their best current guess, and may forget to recheck their decision when they are with the users again. Therefore, they should have telephone access to the expert user during the week.

Before I leave this property, I ask you to read again the last paragraphs of the Frequent Delivery, in which I describe the troubles arising from not arranging for real user feedback. Even teams that do every other practice in agile development find themselves facing catastrophic bad news at the end of the project if they neglect such feedback during the project.

Property 7: Technical Environment with Automated Tests, Configuration Management and Frequent Integration

The elements I highlight in this property are such well-established core elements that it is embarrassing to have to mention them at all. Let us consider them one at a time and all together.

Automated Testing. Teams do deliver successfully using manual tests, so this can't be considered a critical success factor. However, every programmer I've interviewed who once moved to automated tests swore never to work without them again. I find this nothing short of astonishing.

Their reason has to do with improved quality-of-life. During the week, they revise sections of code knowing they can quickly check that they hadn't inadvertently broken something along the way. When they get code working on Friday, they go home knowing that they will be able on Monday to detect whether anyone had broken it over the weekend – they simply rerun the tests on Monday morning. The tests give them freedom of movement during the day and peace of mind at night.

Configuration Management. The configuration management system allows people to check in their work asynchronously, back changes out, wrap up a particular configuration for release, and roll back to that configuration later on when trouble arises. It lets the developers develop their code both separately and together. It is steadily cited by teams as their most critical non-compiler tool.

Frequent Integration. Many teams integrate the system multiple times a day. If they can't manage that, they do it daily, or in the worst case, every other day. The more frequently they integrate, the more quickly they detect mistakes, the fewer additional errors that pile up, the fresher their thoughts, and the smaller the region of code that has to be searched for the miscommunication.

The best teams combine all three into Continuous Integration-with-Test. They catch integration-level errors within minutes:

• Can you run the system tests to completion without having to be physically present?
• Do all your 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?

Evidence: Collaboration across Organisational Boundaries

There is a side-effect from attending to Personal Safety, amicability within the team, and Easy Access to Expert Users: it becomes natural to include other stakeholders into the project, as well.

Géry Derbier, working with the French postal service (La Poste) to build software to run a new facility to handle all the mail going into and out of northern France, reported on his use of Crystal. With 25 people, his was a project in the Crystal Yellow category. However, he knew the principles of the Crystal methodologies family, particularly the "stretch to fit" principle, and therefore chose to extend Crystal Clear to his larger setting wherever possible.

• We discussed his project, and at one point covered their project's linkage to the integration testing team located 30km away and to the business and usage expert working for La Poste. I asked questions of the sort: "How often did that person visit the team? How did he feel about that? How did his manager feel about his coming over so often?" Géry's answers were, for both external groups: "One day a week; comfortable; happy to be involved so early."

After our discussion, I realised that Géry had built the additional safety into his project of Collaboration Across Organisational Boundaries. His project was happily linked into both the customer and integration environments with a colleague on each end. La Poste's contract measured and paid according to integrated test results every few months (the Frequent Delivery). The La Poste executives got software delivered in growing increments and paid accordingly. Géry's bosses, who had no previous experience with incremental delivery, were happy about this also, since they saw regular delivery turn into regular payments. Géry had a support structure on all sides.

Collaboration Across Organisational Boundaries is not a given result on any project. It results from working with honesty amicability and integrity 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 organisational boundaries as partial evidence that some of the top-seven safety properties are being achieved.

Reflection on the Properties

I don't believe that any prescribed procedures exists that can assure that projects land in the safety zone every time. Nor, with the exception of incremental development, do I show up on a project with any particular set of rules in hand, even though I have my favourites. This is why Crystal Clear is built around critical properties instead of specification of procedures.

A Crystal team works to set the seven properties into place, using whatever group conventions, techniques and standards fit their situation. The conventions may vary by project and by month. New techniques get invented with each new technology (and usually go out of style again a few years later). These seven properties, on the other hand, have been applied on good projects for decades.

My intention with Crystal is to not invade the natural workings of individuals on the project where possible, and to allow the most possible variation across different teams, while still getting those diverse projects into the safety zone. To allow variation, I must remove constraints. Removing constraints means finding broader mechanisms that provide a safety net. The ones I choose to rely on are these:

• People are by nature good at looking around and communicating.
• They take initiative when provided with information.
• They do better in an environment that is safe with respect to personal emotional safety, and particularly freedom from personal attacks.
• They do their best work if they can satisfy their need for contribution, accomplishment, and pride-in-work.

The Crystal Clear safety net is built on those things.

Personal Safety gives people the personal courage to share whatever they discover.

Osmotic Communication gives them the greatest chance to discover important information from each other, and does so with very low communication cost.

Reflective Improvement gives them a channel to apply feedback to their working process.

Easy Access to Expert Users gives them the opportunity to quickly discover relevant information from the user(s).

Frequent Delivery creates feedback to the system's requirements and the development process. The technical development environment including:

• Automated Tests, Configuration Management and Frequent Integration allows people to safely make changes to the system. Synchronise the multiple minds that are in motion at the same time, and get feedback on the system's intermediate stages quickly. Focus allows the team to spend their energy well on the most important things.

Ron Jeffries once characterised Crystal Clear as, "Bring a few developers together in peace, love and harmony, shipping code every other month, and good software will emerge." He is close.

Dr. Alistair Cockburn (pronounced Co-burn, the Scottish way) is an internationally renowned project witchdoctor and IT strategist, best known for describing software development as a 'Co-operative Game', for helping craft the Agile Development Manifesto, for finally defining Use Cases and for developing the initial response technique relaxation/massage form.

Dr. Cockburn wrote the Article "7 Properties of Highly Successful Projects from Crystal Clear" and recommends you visit alistair.cockburn.us for more information on a range of topics including Agile Development, Crystal Methodologies and Project Management.