Remember This for New Years Resolutions: Good Work Habits

From a CNN article:

We've all heard the conventional wisdom about good work habits. Many of us have attended time management classes, participated in workshops and have been advised to "work smarter, not harder."


Work habits that might seem less productive will make you more effective, say experts.

Some ideas, however, appear at first glance to be unusual or even counterintuitive.

Goof off at work, read a book, ignore e-mail. (Read the article.)

Working Hard or Hardly Working

George Dinwiddie is considering a discussion about velocity as a performance measure and how to tell whether people are working hard that started on the scrumdevelopment yahoo list.

Here's the original question, posted by Graeme Matthew.

The unknown in all of this is that if a team have a velocity of 6 how do you tell if they should have a velocity of 8 i.e. they are underperforming. It gets complex. If they have a velocity of 16 are they doing well or have they estimated at the higher scale of story points.

0. Using velocity as a performance measure is wrong, wrong, wrong. Velocity just is, and you work to improve it over time by improving engineering practices, the work process, working relationships, and skills.

The assumption behind the questions is that people might be slacking off, not working as hard as they can.

I don’t want people to work as hard as they can. I want them to work hard, but at a pace where they aren’t making themselves more error prone, and aren’t exhausting themselves.

[aside]
If the team seems to lack a sense of urgency, it might be because they are missing information about why the project is urgent. The fact that a senior manager made a bet on the golf course doesn't make the project urgent. That some sales person promised the moon and stars without any knowledge of the development effort is not urgent--for the development team. Making a once-a-year sales window...that's urgent.)
[/aside]

Some managers seem to want to know who is working hard, and how isn't.

My experience is that some people have to work harder to accomplish the same results that another person can accomplish easily. Some people look like the are working mighty hard, but are not accomplishing much.

Thinking that we have to have everyone working equally hard doesn’t make sense to me…Why would you want to punish the person who gets his work done quickly by piling more on?

Further, there’s almost always someone how isn’t the best programmer, but things just go better when he/she is on the team. They may not look like they are working hard, but take them off the team, and everyone's performance goes down.

Perhaps some different questions:

Are the conditions present for every member of the team to do his or her best?

Have the managers put together people with the mix of skills and expertise needed to do the work the company needs done?

Are individuals performing to the expectations of their pay level?

If there’s a perception that people are not working hard, what might the reasons for that be? (Systems, policies, procedures that dis-incent performance; work they don’t care for; disenchantment with direct managers?)

As a manager, I'm more interested in who is struggling and/or who doesn't have the skills or interest in doing the job they've been hired to do. In a manager-led team, that pretty easy to notice if you meeting with people on a regular basis.

On a self-organizing team, it's harder, but not impossible. First, there has to be enough trust to support transparency. When there's visibility into the work, then a manager can see where things are binding up, and investigate the source of the problem. The source might be a person, but might also be the process or some other factor.

What's a Manager to Do?

When the team self-organizes, the manager needs to step back, but not too far back; she needs to step in, but not to quickly.

My article on the manager's role in self-organizing teams is on the cover of Better Software Magazine and available on-line here. (link updated 2/4/09).

Team Renewal

Jim Sowers asked for more information on team renewal.

Here are some reasons teams need renewal.

Over time, work that was initially a challenging learning experience becomes routine.

Life circumstances change and some team members need to focus their energy in a different direction.

Team membership changes.

The team may complete their initial goal.

When there are challenging interpersonal relationships on the team, people may get tired of putting that much emotional energy into the workplace.

The action you take depends on what's going on for the team.

It may be time to celebrate past accomplishments, aknowledge contributions and then disband the team.

There may be an opening to re-examime the work the team is doing, and find a new challenging project for the team to work on.

The team may need to reexamine their reasons for continuing as a team or continuing with the work.

Sometimes, for various reasons, its just time for individual team members to move on...so recognize, celebrate and then find a new team member (if necessary) and reform the team (because it will be a new team in many ways).

Some sort of periodic reflection (a retrospective!) is a good way to address on-going commitement before team members get bored or burn out....maybe on a half-year or yearly cycle depending on the work, and with an explict focus of doing a check-in on engagement.

Magic Chemistry of Teams

George Dinwiddie has posted his notes from one of my AYE 2008 sessions, Magic Chemistry of Teams.

During the session, I asked people to draw a time line that represented their experiences working on teams, then, working in small groups, identify the factors that were present on high-point teams and low point teams.

Here's a partial list of factors present on low-point teams (posted on George's site):

no vision
bad results around us
bad fit of skills & interests
alone
angry boss/poisonous environment
no common location
lack of appropriate tools & equipment
specialization
One Jerk/personal conflict
lack of respect amongst team members
absent leader
lack of face-to-face contact
lack of clear priorities
judgemental leader
loss of team members
blame/shame
team too big

Notice how many items on this list relate to how the team is established: vision, location, skills fit, priorities, tools and equipment, team size. These are all within management's responsibility.

If there is a clear vision, clear priorities, necessary physical environment, the right number of people with the right skills, then it's more likely that the items on the "high point" list will emerge:

common goals
clear goal/vision
clear role/expectations
new/novel/learning
presence of great skill
self-organizing
ritual
team members value each other
good humor
ate together
camaraderie
appreciation
recognition
trust
passion
friendship
flow

Too often, managers throw a group of people together and declare it a team. Calling a group a team doesn't make it so. It takes work to establish an environment where team work will emerge.

(It takes collaboration skills on the part of team members, too, as in Secrets of Agile Teamwork, coming up in February.)

Found Treasures

I was at a friends house this morning and picked up a book she had out as she worked on a course. As I flipped through the pages, it look sort of familiar, and when I came home I found it on my bookshelf.

More than 50 Ways to Build Team Consensus (R. Bruce Williams) is chock full of activities that teams can do to clarify their vision and goals, build commitment to task accomplishment, engage participation. (I have the 1996 paperback edition. Don't remember how much I paid, but it was less than the price quoted on amazon.)

I wouldn't do all of the activities (I'd skip the team song, for example); but if you work with a team and are looking for some ideas on how to get people on-the-same-page, talking, and engaged you'll find some helpful ideas.

Feedback Doesn't Just Roll Down Hill

Many organizations have a model that feedback rolls down hill. The VPs give feedback to the Directors that report to them. Directors give feedback to the Managers. Managers give feedback to developers. It all cascades downward.

A manager's job is to create an environment where the people who report to him/her can succeed. While it's useful to hear how the people above you in the hierarchy view your work, it's not sufficient. It's also important for managers to understand how well they are doing in supporting others to do their work.

Unfortunately, it's not that easy for managers to obtain open feedback. People aren't accustomed to giving feedback. They may fear they'll be punished if they don't stroke the bosses ego.

360 Feedback Processes are an attempt to get feedback from different points of view. In my experience, these programs don't provide much actionable information. Its too easy to lob softballs or zingers, with no way for people to follow up.

I find that it's more useful to find out what's important to people and start a conversation. I've outlined a process to do that here.