Collaboration and Teamwork

Laurent Bossavit quotes these instructions from a college exam for testers: Incipient.oO{}: Certifications, degrees, teamwork "It is essential that you work on this exam ALONE with no input or assistance from other people. You MAY NOT discuss your progress or results with other students in the class."

And makes this response:

Some time after I'd left the official education circuit, I came to the conclusion that it hadn't been that much of a loss, since it had utterly failed to equip me with the skills that were to prove most crucial in my work as a software professional.
Among the chief such skills were those related to teamwork, and working in collaboration with others. I'm pretty sure that collaboration and teamwork are as important for a tester as they are for a software developer.

Yes, indeedy. I hear that things are different in schools now, that kids often work on group projects. Maybe in 20 years those kids will change the face of collaboration in corporations.

In the meanwhile, groups in software organizations struggle to work together effectively.

Many companies throw up organizational barriers to collaboration:

--reward structures that focus on individual achievement
--recognition of individuals for group efforts
--disbanding groups that do work well together (the "seeding" principle)
--promotion of individual stars

And most "team building" misses the mark. Ropes courses, pep talks, and inspirational posters are a crock.

Effective collaboration requires:

A healthy dose of self-esteem. People who feel good about themselves can be generous towards others. Self-esteem leads to good boundaries...neither a doormat nor a steamroller be. People who don't feel good about themselves have a hard time feeling good about others. Some people who don't feel good about themselves have to make other people "less" so they can feel "more."

Self-awareness. The more people understand about themselves-- their communication style and preferences, blindspots, responses, quirks, and strengths -- the better able they are to adjust to context and circumstances, ask for what they need and offer talents where they excel.

Conflict and negotiation skills. Any relationship between two people involves conflict, because we all have different interests, needs, and wants. Close working relationships require the capability to work through those differences in a constructive way.

Feedback skills. People who collaborate well know how to give feedback to their co-workers: information about the past, given in the present with the hope of influencing the future (to use the definition in Weinberg, Seashore and Seashore). They don't sit back and say "It's the manager's job to give feedback."

Willingness to let the other guy be right (some of the time). Collaboration requires sharing of ideas and sharing credit. People who always have to be right have trouble working collaboratively. (Plus it's not that fun to work with them.)

Listening skills. Don't be thinking about your response while the other person is talking. Listen for understanding, seek clarification, and listen for what's behind the words. (And check it out, don't just guess.)

Reflection. People get better at working together when they take time to reflect on their process, discuss what's working and develop new strategies for interacting.

What would you add to this list?

Reflection Leads to Learning

I'm back from the 2nd annual Retrospective Facilitators Gathering. What a great, juicy week!

Two stories stand out for me:

Seeing the Big Picture: Chrystina Katz, who is building a retrospective practice within her company, reports that informal communication has improved since they started doing retrospectives. People in different functional areas have a better idea of how their work or changes to their plans effect other groups, and they make an extra effort to keep other groups in the loop. The result: fewer blindsides and a greater sense of "we're in this together."

Better Working Relationships: Tim MacKinnon started doing retrospectives on his XP team after every iteration. The short turn around allowed them to try small experiments: " Let's do something differently this iteration and see how it works." Tim reports better working relationships and communication as a result of taking time to reflect on process and teamwork during retrospectives.

Another week out of the office. This week I'm at the 2nd annual Retrospective Facilitators Gathering. We're a bunch of folks from the US and Europe who are using innovative techniques to support organizational learning for software project teams. Forget those post-project reviews that product a list that is filed away never to be seen again!

And the gathering is held in a quaint little hotel on the Oregon Coast. Internet access is at the local library.

I may be scarce this week.

ED

More Meaningless Management Phrases

How could I have forgotten that classic: They're all number one priority! Usually uttered in response to a question like: What's the top priority? In this case, the speaker may not know what the top priorities are. Or he may believe that ranking the tasks will result in displeasing someone(s). Rather than incur the wrath of the non-number one priority task folks, all tasks are declared equal. He may also believe that if we just work a little bit on all of them, all the tasks will be completed more quickly than if they were done sequentially. Wrong, wrong, wrong.

Thanks to Frank for reminding me of this one.

Meaningless Management Phrases

The overheard conversation between a harried developer and her manager ("You'll just have to multitask!") reminded me of other management exhortations I have heard.

Failure is not an option! This is usually repeated with great vigor and conviction by managers who have sent their developers off on a project that has virtually no chance of meeting schedule and scope goals. (Projects like this seem not to have quality goals.). Perhaps they believe that repeating this phrase will hold failure at bay. Failure is always a possibility, and perhaps a probability. I suppose this phrase comes out of the school that believes Positive Mental Attitude will overcome all obstacles. Attitude counts for a lot, but it's not a substitute for good sense.

It's just a ___________(fill in the blank). The word "just" is a clue that the speaker is dismissing some essential complexity. Variations are:
It's just a database.
It's just a small change.
It's just a different programming language.
It's just negativity.

Don't bring me a problem, bring me a solution! I think managers say this believing that it will inspire staff to develop problem-solving skills and initiative. The real effect of this phrase is that the manager doesn't hear about problems early or at all. And team members will struggle to solve a problem long after they have exhausted productive options, and a bit of outside help is what's needed. If a manager really wants people to become better problem solvers, there are other (more effective) ways to develop those skills.

I'm sure there are more...

Multitasking adds to the task list (while diminishing avialable productive time). No wonder it's trend!

Keith Ray posts this snippet of conversation:

Ron Jeffries posted his email conversation with Jon Eaves on XP mailing list in "Bug tracking vs user stories"

[ jon ]
"Projects that have developers working on multiple simultaneous projects have a 30% higher defect rate than projects with developers assigned specifically to it"

[ ron ]
Fascinating if true.

[ jon ]
I don't remember the actual number, this is again from a previous life, but there was a higher defect incidence rate. We stopped this practice (or at least attempted to minimise it) and life was better for everybody.

Ok. So context switching uses tons of time, reducing productivity, and it also leads to higher defect rates.

Either those defects get shipped, or the poor harried programmers use their few remaining shreds of productive time to fix them. (It would be interesting to see what the Fault Feedback Ratio is in cases like this). How do folks make forward progress?

The other day I overheard a conversation between an overworked developer and her manager. The manager had just added on another task to the developers overfull plate. When the developer protested, the manager said "Well, you'll just have to multitask!"

I cringed. Directing staff to multitask rather than setting clear priorities and focusing on the most important initiatives is an abdication of management responsibility. Period.

(And the manager may not have known:

-- how to prioritize
-- how to determine what the top priorities are
-- how to say "No"
-- how to get out of fire fighting mode
-- how to sequence work
-- the costs of multitasking.

But that's another story.)

I'm on the road for the next few days... If I have a good connection, I'll post; if not, see you when I get back.

Competence in Context

Bob Lee & Keith Ray both commented on my post comments on my post Unskilled and Unaware of It.

Bob says: The other interesting point in the article is that competent people *assume* that others are as competent. "It's easy (for me) so it must be easy for them..."

The results suggests that the best teachers are those who have to struggle a little with the subject matter, not those for whom it is easy.

Yes. And the same can be said for managers. When technical "stars" are promoted into management they can lack empathy for people who aren't as brilliant. And they may not have the patience (or even know how) to work with people who, while solid, aren't quite as gifted.

It can be an ugly situation. And a costly one: The group is deprived of a strong technical performer, and now has a manager who doesn't understand how to help other people succeed.

(Plus we all know that the skills and characteristics that make a star technical performer are not necessarily the ones that make a great manager.)

Unskilled and Unaware of It

Stephen Norrie (an avid and well-organized collector of articles related to software development, technology, business and humans) pointed me to this study:

Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments
Justin Kruger and David Dunning
Department of Psychology
Cornell University

Abstract
People tend to hold overly favorable views of their abilities in many social and intellectual domains. The authors suggest that this overestimation occurs, in part, because people who are unskilled in these domains suffer a dual burden: Not only do these people reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the metacognitive ability to realize it.

Thanks, Stephen.

More to come.

You know who you are (unless you don't)

Alan Francis writes about programmer productivity in a piece titled you know who you are:

More from Steve McConnell's After The Gold Rush 2nd Ed - http://www.stevemcconnell.com/SoftFactors.pdf

The range in productivity says that some programmers are much more productive than others, which implies that we'd like to find ways to hire and retain the best programmers. But that’s only half the story. In DeMarco and Lister’s study, 13 of the 166
programmers in the coding war games didn’t finish the project at all—that’s almost 10 percent of the programmers in the sample. In Curtis’s study, 6 of the 60 professional programmers weren’t able to complete the “simple” debugging task, again 10 percent.

Actually, I don't know if they do know who they are.

I came across a report in 1999 or 2000 that stated that one dimension of incompetence is an inability to accurately assess performance against external markers. People who are incompetent are not able to see they are incompetent.

Scary!

I'll have to poke and see if I can find that study (originally saw it via Elisabeth Hendrickson).

Look Back to Move Forward with Renewed Energy

Another post from Dale Emery:
Walking to the Horizon

Dale talks about the frustration and exhaustion he feels when there isn't an "end" in view:
One day a metaphor popped into my head. I'm trying to walk to the horizon. For every step I take, the horizon recedes by exactly one step. No matter how far I walk, I'm never any closer to my goal.

"Good grief!" I thought. "No wonder I'm tired!"

Then I had an idea. Whenever I notice that walking-to-the-horizon feeling, I can turn around and look back at where I've been. I can notice the tiny steps I made yesterday, the good deed I did the day before that, the major accomplishment I scored just last month. When I realize just how far I've come, I can take a breath, enjoy the moment, and smile with satisfaction at the journey I've made so far. Then I can take the next step with renewed hope and energy.

Dale is talking about process improvement, but I see this in project work, too. Projects, by nature, have an "end," though some times it takes much longer to get there than advertised. And project teams become frustrated and tired when they go from one project to the next with out pausing to look back.

Looking back, in the form of a Project Retrospective helps the team move forward:

Individuals and the group:

-- look back and see what they have learned, the problems they solved, and what they created. Even on failed projects (may especially on failed or cancelled projects), the team can consolidate a sense of accomplishment.

-- reflect on what worked well and what didn't work well. They can look at actions and interactions worked or didn't work and make more conscious choices to act effectively in the future.

-- agree on changes that the team believes will increase their chance of success on the next project.

Retrospectives help people harvest what they've learned, bring closure, and create energy for moving forward.

There is nothing either good or bad, but thinking makes it so.

“There is nothing either good or bad, but thinking makes it so.”
William Shakespeare’s Hamlet, Prince of Denmark, Act II, Scene 2

Johanna Rothman's recent post talks about what happens when managers ignore or suppress data.

Trouble can't hide when information is public. Trouble is, some managers, such as the one described in Johanna's post, are unable or unwilling to "see" the current state, or let others see it.

Why? I have some theories:

--The manager may have deeply ingrained internal rules about failure or success that act against acknowledging the current state: Rules like "I must always meet others' expectations," "I must always deliver on my promises," "I must never fail," are powerful, influencers of behavior. We've all got them, we just bump into them in different ways.

--The organizational culture may cause people to suppress "bad news." People in organizations that shoot the messenger often sugar-coat and suppress information about the current state. "Shooters" deprive themselves of the very information that would help them succeed, or at least mitigate disaster. Managers of the shoot-the-messenger school seem to be fond of phrases like "Failure is not an option!" My little internal metric is that the likelihood of failure is directly proportional to the prevalence of this phrase (and it's close cousins).

--I've noticed that people with high self-esteem are more able to accept deviation from the desired state as information... neither bad nor good, that will help them take appropriate action. And I've seen managers with low self-esteem who were quite unable to admit that things weren't going well. My theory is that people need a good bit of self-esteem to admit problems or mistakes.

--Some managers seem to know, on some level, that things aren't going well, but they don't know what to do about it. This not-knowing-what-to-do seems to paralyze some managers. (Managers are supposed to know how to do everything, right?) Rather than admit they don't know what to do and ask for help, they let the situation continue spin out of control until it's too late, or at least very difficult to take corrective action.

The common thread seems to be that managers who suppress "bad news" or appear oblivious to "bad news" are protecting themselves in some way.

On the other hand, I've met some manager who were masters at declaring victory in any situation, marketing up, and moving on before the consequences come home to roost.

I interviewed one project manager who left a project for another job six weeks before his project crashed and died. When I talked to him he said, with a straight face, "I don't know what happened. That project was on track when I left, at most a week behind. How did they manage to ruin it in six weeks?"

I find these managers particularly puzzling.

On the subject of keeping project information public and avoiding the suppression mess, the participants on the AYE Conference wiki talk about Information Radiators and Public Project Progress Posters.

Beliefs, Identity, and Projects

Dale Emery makes a thoughtful response to my post Projects that will not die on his weblog : Success, Belief and Identity .

Our mental models, beliefs, and sense of self do play a big part in how we see the world. what we see in the world, and how we respond when things are not as we'd like them to be. More on this in two pieces that originally appeared in STQE magazine: Beyond Belief and Facing Up to the Truth.

I particularly liked the section Dale quotes from Margaret Wheatley's book. I think I'll journal on this one, and see what I learn. :-)

I also noticed my response as I read Dale's statement, 'When I say "I'm not surprised," you can bet that I am surprised.'

I don't do that, I said to myself. When I say I'm not surprised I'm not surprised.

Hmmm. I'll try to notice next time I say that, and check out whether I'm really surprised or not.

(I wonder if Dale was really surprised by Royer's research. He says he wasn't surprised, but does that mean he is? )

Projects that will not die (but are never going to deliver)

I came across this article on Stephen Norrie's blog:

HBS Working Knowledge: Leadership: When Bad Ideas Won't Die Why do smart companies put so much energy into doomed products? University of Paris-based Isabelle Royer tackles this thorny issue in this excerpt from Harvard Business Review. By profiling two French companies' experiences with failed projects, Royer gets at some surprising answers: Belief and faith triumph over reason. Mar. 31, 2003 Issue .

I've seen several of these projects in Retrospectives... after someone has finally driven a stake through the heart of the project and killed it dead. (The good news is that the group is looking back to see what happened and learn from the experience.)

These project aren't always trying to implement a bad idea: Sometimes these projects are trying to implement a very good idea that isn't achievable, at least not now, and not the way the project is going about it. Bad idea or good idea, projects that are failing but refuse to die sucking up the resources of the organization.

Here are some of the patterns I've observed:

The project champion makes glowing reports of progress and extols the mental prowess of the team in overcoming obstacles... but can't seem to provide much hard data or tangible proof of progress. Lack of data is the data.

Most of the time, the people on the project are smart people, and tenacious, problem solvers. As problem after problem comes up, they reassure them selves that they will be able to solve this latest one, too. It's not anyone problem that dooms the projects its all the problems taken in together. Each one is a small detour, but when you add up all the detours, forward progress is nearly nil. But on zombie projects no one seems to notice. Solving problems is progress of a kind, so it may feel like the team is accomplishing great things.

There's often one person with "the vision" who champions the idea. Because the technology is new and dazzling, perhaps people who usually make hard-nosed business decisions feel a bit intimidated.They may not understand quite how the project will get from point A to point B. If you hear the champion say "Trust me," you know you're in trouble. Trust but verify... which brings us back to data, and to credible plans.

Champions on these project tend to isolate themselves from bad news. A common way is to label people who criticize the approach or ask too many questions as "not forward thinking" or "not strategic." Then it's easy to dismiss anything they say that casts doubt on the viability of the project.

Sometimes these project are a core piece of a strategy that will addresses real, important business concerns. And it can be hard to let go of something that's going to all your problems, make tons of money or save the day.

Yesterday's Weather (or how information about past performance can help us make decisions in the present)

Frank Patrick responded to my post on phoney actuals with a couple of pithy quotes about the perils of one-dimensional measures (for lots more on this read Robert Austin's MMPO):

"Tell me how you'll measure me, and I'll tell you how I behave" - Eliyahu Goldratt

"Tell me how you'll measure me, and I'll tell what damn fool things I'll do to make the measurement look good." - Tony Rizzo

He goes on to say:

"No amount of sophistication is going to allay the fact that all your knowledge is about the past and all your decisions are about the future." - - Ian E. Wilson

Actuals are water under the bridge. What matters is what remains, and whether the time and money that remain are sufficient for the work that remains and its uncertainty. And when talking about internally resourced projects like most IT shops, funny money costs associated with "actual" resource or PM hours are the last thing I'd worry about in trying to manage a project. Focus on the dependencies, the time, and the behaviors, and the money will be what it needs to be.

Water under the bridge they may be. And I find that (real) actuals from previous projects can prevent some poor decisions when starting new projects.

Say you are handed a feature set, a budget and a delivery date.

If you have actuals from past projects, you can look back at projects of similar size and character and see if you've ever succeeded in delivering that size and scope within those constraints. If history tells you that the organization has never come close to a similar goal, perhaps you can get real about your prospects this time. Sometimes looking at the past can save you from committing to a project that has the smallest possible non-zero chance of meeting scope/date/quality goals.

Agile projects look at past actuals frequently -- every iteration. In each planning session, they look at the number of story days completed in the last iateration. And they don't sign up for more stories than they were able to complete in the last iteration. (Keith Ray has a nice article on how agile projects build feedback into the process. I hope we'll see it in public soon!)

The hapless project manager in Shooting Yourself in the Foot could be using actuals to get real about his prospects for delivering (as Frank points out).

Why bother with all this actuals stuff? When we know that what we were able to accomplish in the past, we are less likely to commit to an impossible project in the present. Then perhaps the people how want the the project will start believing us when we say we can deliver by X date. And that's one way to start influencing the trust dynamic in the organization.