TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPass
Home  >  Detail: Helping Your Team Weather the Storm



A StickyMinds.com Original
Article Picture
Helping Your Team Weather the Storm

By Esther Derby

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Jim is mad at Hal. Sara is complaining to Jason. Hal feels hurt; Susan shows up late. Jason thinks only Sara and he have a clue. Is this team falling apart--or just experiencing a normal part of group development? In this week's column, Esther Derby describes what their team leader Jenny goes through as she learns about the predictable ups and downs of team formation and the one thing any team member can do to help.


HP Pillars of Application Quality
From the inside, it felt like the Release 2.0 team was falling apart at the seams.

Jim fumed as he walked back to his cube after the team meeting. "I can't believe that Hal waited a whole week to tell us that he was having trouble completing the shopping cart tests," he thought. "Everyone should know to ask for help when they're stuck for more than half a day!"

Elsewhere Hal, feeling rather abused, wondered why Jim had jumped on him. He didn't know that "everybody" knew there was an unspoken rule about asking for help.

Meanwhile, Sara, who also worked on the Release 2.0 team, vented her ire to co-worker Jason.

"Why can't people show some common courtesy? Joe is always interrupting people and Susan is always late," she complained. "I can barely stand to work with Hal--he's so secretive! And Jim acts like he's king of the world. I don't know how we're going to ship this release on time. You're the only one I can work with."

"You and I are the only ones accomplishing anything on this team," Jason said. "The way Jim and Hal have the check-in process is brain-dead. No way I'm following their asinine process."

All the members of the Release 2.0 team were feeling put-upon, hurt, and annoyed. They were making some progress, but no one was having fun.

Jenny, the team lead, interacted with each person as an individual and with the team as a whole. She gathered from conversations and the work they produced that each team member wanted to do the best job possible and wanted the team to succeed.

A few weeks before, when the team formed for Release 2.0, everyone had been excited and optimistic about the project. Jenny was puzzled that these smart, caring individuals were such a mess as a team. How could things have gotten so bad in such a short time?

She did a little research on team dynamics to see if she could learn how to knit the team back together. Here's some of what she found:

Teams experience predictable stages of development. Every team goes through these stages at a different pace, and when there is a significant change--a new team member arrives, a team member leaves, or the overall task changes--the team will go through some part of the process again as they re-form and adjust to the change.

Stage 1: The team needs structure and a clear goal. Individuals need to know how they fit in and what part they play. Team members are usually optimistic, but they may also hold back until they discern how they mesh with the rest of the team.

Stage 2: Team members begin to wrestle with the task, and conflicts emerge as people realize they have different approaches and different needs.

Stage 3: Team members begin to work in earnest. The team learns how to handle conflicts and members provide each other with direct feedback. People acknowledge their differences and begin to work productively in spite of them (and because of them).

Stage 4: The team has a sense of purpose, and focuses on getting the job done. Members connect their task to the larger mission of the organization, and they feel commitment to each other.

As Jenny read this material, she thought she recognized what was happening with the team. They had been optimistic and friendly when they started work on the release. Now as they ran into the usual glitches, tempers flared. People had different ideas about how to accomplish the work and what constituted appropriate behavior. The team wasn't falling apart; they were going through a normal stage.

But if she didn't do something to help the team to the next stage, Jenny worried they might stay stuck in this stormy stage. And with the release date looming, she needed to nudge them into high performance.

At the next team meeting, Jenny shared her observations and what she'd learned about team formation with the group.

"I think we need to agree on what we expect from each other and how we're going to do things," Hal offered.

"That's a good idea, Hal. That fits in with what we've just learned about team development," Jenny said. "I learned an exercise for developing working agreements. Are you willing to try it?"

Joe, Susan, Jason, and Sara nodded. Jim wasn't so sure, but reluctantly agreed to try.

"First, let me explain what a working agreement is," Jenny said. "It's like a social contract: we all agree on how we'll work together, and then we're all responsible for holding each other to the agreement. I know you all want this release to succeed. Working agreements will assist us in our interaction and help us work together productively."

Jenny helped the group develop possible working agreements.

At the end of their working time, they had ten possible working agreements posted on the white board.

"Ten seems like a lot of rules to keep track of," Sara said.

"I agree," Jenny responded. "Let's identify five to seven rules that are most important to us. We can vote by each putting check-marks next to the ones we think are most vital to a productive working relationship. Each person gets three votes. You can put all your votes on one working agreement or vote for three different ones."

By the end of the meeting, the team had settled on these five agreements:

  • Arrive at meetings on time and prepared.
  • Ask for help when you are stuck on a task for more than two hours.
  • Whoever breaks the build fixes the build.
  • Seek to understand before jumping to judgment.
  • One conversation at a time in team meetings.
In the next weeks, the team consciously attempted to live up to their agreements. After three weeks, they realized that they needed to add a new agreement: Team core hours are from 9:00 a.m. to 3:00 p.m.

Jenny’s team continued to refine their agreements. They still have frictions (as all humans do), but when that happens, they remind each other that they are all committed to shipping the release and find a way to work through the conflict. They feel pride in their work and pride in their work as a team.

Working agreements won't solve all team problems, but can help teams create a framework for negotiating how they will work together and discussing issues when they come up. That framework can make the difference between a productive team and one stuck in a stormy stage.

About the Author

A regular StickyMinds.com and Better Software magazine contributor, Esther Derby is one of the rare breed of consultants who blends the technical issues and managerial issues with the people-side issues. She is well known for helping teams grow to new levels of productivity. Project retrospectives and project assessments are two of Esther's key practices that serve as effective tools to start a team's transformation. Recognized as one of the world's leaders in retrospective facilitation, she often receives requests asking her to work with struggling teams. Esther is one of the founders of the AYE Conference. You can read more of Esther's musings on the wonderful world of software at www.estherderby.com and on her Weblog at www.estherderby.com/weblog/blogger.html. Her email is derby@estherderby.com. She has presented at STAREAST and the Better Software Conference & EXPO.

Back to Top
 
 


Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Sachin G 3/26/2006

Well said. I have gone through similar experiences in the past and it is very difficult to keep everybody happy. Well, one can always try with different approaches though. One of the best things in the article and which i had experienced in the past is the team goal, even though we have conflicts and issues, team is always striving for a team success and focussed on releases.

 
 
Comment:    
by John Daughety 12/8/2005

These four stages apply equally to a marriage (or a long-term relationship with a friend or significant other): and that is just a team of two! I think this is a great reminder of how special those teams that really hum are; in many years of testing, marketing and even financial analysis, I have gotten to experience this only a few times. I will also admit that I have checked out in several situations that were clearly in the struggles of the middle stages, with territorialism, information hiding and overt feuds highlighting most days. Especially after reading this article, I can see how such indifference on my part really sabotaged my...Read On

 
 
Comment:    
by Prabhaakar Balasubramanian 12/7/2005

"Everyone should know to ask for help when they're stuck for more than half a day!" -- this is very correct, helping team members should be an objective in the performance appraisal. Every team member should have a "team wins, i win" attitude, and getting a team to the "perfomring" stage is every manager's nightmare. Hidding information, one of the most common problems, i presume everyone in the IT industry must have faced. Again, if people are commended, awarded for sharing information then certainly the skill might improve. I strongly disagree with the concept of defining everything into a process and asking...Read On

 
 
Comment:    
by Ed Weller 12/5/2005

Unspoken rules are one reason why a good set of (defined) processes are needed - new team members know what is expected behavior and over time this behavior becomes ingrained and allows new teams to form (storm,norm and perform) more quickly. Unspoken rules assumes everyone is assuming the same thing, and we all know what assume breaks down to :-)

 
 
Comment:    
by Mike Whittaker 12/5/2005

No, it's not an oxymoron - check the dictionary definition ! Re the article, seems like "the team" didn't understand how to behave as a team, so I guess some coaching in the basics was in order ...

 
 
Comment:    
by Gene Fellner 12/5/2005

"Everybody knows about the unspoken rule." Heehee. Is that an oxymoron or what? Things can only go downhill from there.

 
Back to Top


Marketplace

Census: Web-based Bug Tracking and Defect Tracking
Track software bugs, defects, enhancements, support calls, and more. Issue tracking software that is scaleable, fully customizable and integrated with VSS. Includes e-mail notifications, role-based workflow, change history, and Crystal reporting.

Web based bug tracking - AdminiTrack.com
AdminiTrack offers an effective web-based bug tracking system designed for professional software development teams.

Check Out IT Certification Preparation Materials
Sign Up With SkillSoft & Get Access to Training Materials for Over 50 Professional Certifications.

Need Agile Test Cases?
Create statistically complete test cases simply and quickly.

Bug Tracking On-Demand
Looking for the reliable, convenient, secure and completely web-based issue tracking system? BUGtrack allows unlimited number of users, projects and bugs as well as unlimited customer support for a low flat rate.

Get your product or service listed here.
Subscribe to Better Software Magazine
Subscribe to Better Software Magazine

First Name:

Last Name:

Email Address:


Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2008 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


McCabe Software

Borland

STARWEST 2008

 
Agile Development Conference 2008