Atomic Spin :: Elements of Software

I attended the Great Lakes Software Excellence Conference late last month. One of the tutorial sessions was put on by Tim Lister. Tim, a co-author of Peopleware and Waltzing With Bears, describes himself as a “Team Zealot” and “Risk Management Zealot” respectively in regards to these two books.

As one who has not yet read Peopleware, I found Tim’s insights, coaching and encouragement to be refreshing. His presentation gave a glimpse of what the book Peopleware contains.

One of the many hats Tim wears is that of a part time arbitrator specializing in software system disputes. Drawing on this experience he made a telling remark, “almost every dispute is emotionally based.” Neither Tim’s talk nor his book concentrate on disputes, but Tim clearly grasps the soft side of software development – it’s the people that make software succeed or fail.

I organized my notes here in an attempt to summarize Tim’s presentation.

Jelled Teams

Tim and his writing partner Tom DeMarco coined the term “Jelled Teams” to refer to the dynamics that arise within successful project teams.

Team Magic

Responsibility – Tim highly recommends Chris Avery’s Blog about responsibility and its effect on teams.

No more sports analogies, thank you. The internal competition of sports teams is the wrong analogy for our project teams. For example, no software developer sits on the bench hoping a starter twists his or her ankle so they get a chance to work. Instead, Tim suggests the glee club analogy. The baritone section never hopes the altos get laryngitis. In fact, the music is at its best when everyone is working well both individually and together.

Deadlines

“Real deadlines are understood immediately with little or no explanation needed.” For instance, census software has to be ready before the next census is taken.

Completing software because a manager picked a date out of the air is artificial and will not be the motivation that gets the project completed. If a Jelled team meets an artificial deadline it will be because of the strength of the team not due to any factor that comes from outside the team.

Team Identity – “Quack!”

Team identity is paramount. The relationships and identity forged by jelled teams often outlive the project itself. Tim told the story of a straight-laced developer he knew. Tim and this man were walking down a hallway one day when another colleague passed in the hall. In mid-sentence Tim’s associate quacked at the woman walking by. The woman immediately quacked back. Tim was floored and asked what had just happened. Through a long series of events involving an acquisition by a French company, the project team had come to know itself as “Les Canards Sauvages” – which is French for “The Wild Ducks”. A customary greeting involved quacking. That custom lived on years after the project was completed.

Team member commitment comes from day-to-day relationships. An example was given of a team member who chose to live out of a hotel for months while his team finished a project before joining his spouse who had already moved for a great new job. He did this for his team, not for his boss or company.

Healthy team culture is spontaneous and authentic, not directed and not divisive. In one case, a team member gave a “Foot-in-Mouth” award at the end of a dreary team status meeting. In a good-natured way, he described a big mistake a colleague had made recently and then gave the award – a boot with a laughing-box inside. Then he announced that whoever received the reward had to choose who would be given the award at the next status meeting. The team approved and began working through status meetings at an accelerated rate in order to find out who won the award each status meeting.

When speaking in retrospect, members of a jelled team always use first person plural (e.g. “we”). They say things like, “We did amazing things on that project” instead of emphasizing individual contributions.

Teams are made of colleagues, that is peers. Managers are allies but they are NOT members of the team. Someone who controls reviews or compensation will always been seen and treated differently.

“Good teams make good people do things they are good at.” – Jelled teams self-manage effectively and efficiently in ways that cannot be done from outside the team. For instance if Susan is great at database design, but she tends to be quiet and unassuming, the rest of the team will make sure that she gets assigned tasks and is included in decisions that leverage her abilities to the benefit of the team.

Deming’s 12th Point – The Measure of Success

Deming’s point 12a from Out of the Crisis is, “Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.”

• “Success in Quality” is defined by each individual in their own role
• An individual’s quality standard means more than any group quality standard
• Jelled teams set their own measure of success

Deming’s Out of the Crisis point 12b is, “Remove barriers that rob people in management and in engineering of their right to pride in workmanship. This means [among other things], abolishment of the annual or merit rating and of management by objective, management by the numbers.”

• Forced ranking systems are a form of “Numbers on Parade”, that is, meaningless – the examples discussed appeared to be for a) protection against discrimination lawsuits and b) a depersonalized method to downsize
• Money is hygiene – not a major motivator
• Management by Objective forces people to work toward the past, not adjust to changes in order to work toward the future. Objectives are set in the past and are out of step with the present situation. Successfully meeting objectives could easily happen while a project or organization is failing.
• “Guarantees are for children” – Kent Beck quote from his first XP project. We are adults. Living in the adult world means making difficult, courageous decisions in the face of change and ambiguity.

Awards and Recognition – The Sinister Clown Effective awards and recognition are generally:

1. Private
2. Praise with no tangible reward

Tim told the story of a project group singled out for recognition at a yearly company meeting with the CEO. Tim watched the group go up to the stage with heads bowed low. Clearly, they felt uncomfortable. Their work was no more important or challenging than any other project team. Further, with this single act, the majority of teams in the audience felt by implication to be failures.

Harlan Mills says, “Great software engineering is boring to watch.” Fighting fires and working in crisis mode is exciting and is often recognized as a herculean effort. Yet, in reality, good software should have few fires or crises. Rewards can easily recognize efforts to put out fires or manage near failures. This reinforces undesirable behavior.

Awards are far more meaningful as surprises rather than at planned reward times (like annual reviews).

Hiring and being Humane

“Where are the kids?” – Where is the new blood? Don’t get ingrown and don’t all retire together.

Use internships to your advantage. With great technical people, you know when they’ve got it. Pick the best.

Good managers appropriately encourage workers to get a life and not lose it. A Los Alamos National Laboratory manager paid for Thursday afternoons on the ski slopes. He said quite simply, “These people need fresh air.”

Since both Rewards and Pride in Workmanship are very individualized, generalization in these areas is doomed to failure. Try not to create a culture of failure.

Agility

“Individuals and interactions over processes and tools” – I wonder how many of the authors of the Agile Manifesto had a copy of Peopleware on their bookshelf.

• Nothing beats face-to-face. Teams don’t Jell if they are not together (yes, that means what is says). Email tends toward evil-mail.
• Nothing beats working on only one project at a time
• Nothing beats working hard, and then going home. “Really good developers know when to stop” – summary of an internal Apple article called, “I Know When I’m Ready and I Know When to Stop.”

Teamicide – Causes and Comments Here are seven time tested practices that dramatically increase the probability of failure:

1. Defensive Management – Teams must own their work. Unless they’re making a “cosmically boneheaded mistake”, shut up! (By the way, Tim thinks, “A project management path for great developers is a cosmically boneheaded mistake.”) “If the team is collegial [successful in Jelling], managers are bored and lonely.”
2. Bureaucracy – Teams do best with a self-imposed, Blues Brothers-like “Mission from God”. Just get roadblocks out of their way. Unrealistic deadlines usually indicate executive/management failure. Jelled teams know when they are doomed. Tumult in QA is indicative of chaos upstream in the process/project.
3. Physical Separation – Teams should be together on site. “Teams don’t jell in meetings.” Teams that have war-rooms seem to do better. Down-time with the team is important to jelling.
4. Fragmentation of Tasks – This indicates there is “no team”. There is thrashing and constant rebooting.
5. Quality Reduction – Telling a healthy team to reduce quality is giving them the cyanide capsule. They know what it means.
6. Clique Control – Mandating the break-up of a team after a successful project is a cosmically boneheaded mistake. Sprinkling successful team members like magic fairy dust into other teams is like mandating that anyone who happily reaches their 20th wedding anniversary must divorce and marry someone else. Sometimes teams do need to be broken up. How do you know when? Tom DeMarco hints at the answer by asking, “What is the difference between a breeze and a draft?” Answer: both are gusts of wind but one is deemed desired and comfortable the other is deemed undesired and uncomfortable. Err on the side of keeping successful teams together and you will know when you need to break one up. Pay attention to whether they are outward-focused or inward-focused, serving customers or themselves.
7. Phony Deadlines – Teams know when a project is doomed and they hunker down for self protection. Preparing for Iwo Jima, the troops refrained from getting to know each other because they knew that the few who survived would have watched the rest being torn to pieces. The euphemism of an “aggressive schedule” is insulting. Are you comparing it to a project with a “passive schedule”?

The Buck Stops Here!

Tim confesses that he and his generation are to blame for the state of the industry. But it is those who perpetuate this culture that are the ones who hold the key to turning it around. Tim is out to encourage our industry to recognize the realities of people working together well in teams and orient projects and culture to maximize success.

Growing Teams

Good teams are organic, not mechanical. So, using a loose farming metaphor, Tim suggests that growing teams need:

1. A cult of quality
2. Closure – Visible progress
3. Elite-ness – Identity that is self-defined
4. Heterogeneity – Adapt a process, don’t adopt a process
5. Preservation of successful teams – Example of IBM’s Black Team
6. Strategic not tactical direction
7. …And pray for rain