We have 4471 guests and 1 member online

Video Spotlight

Home > Blogs > Featured Blogs > Practical Teamwork > Wanting to be part of a team

Wanting to be part of a team

Written by Steve Berczuk   
Tuesday, 10 July 2007 00:06
Another lesson I learned from my home renovation project is that while you can follow the steps of an agile process and still not be agile. The people on the team need to want the process to work. 

It's been a while since I've posted here, in part because life has been busy with the birth of a child and moving in to the newly renovated house.  I did learn some things during the past months that I hope are worth sharing here.

As I mentioned in my last post the renovation project didn't  finish as well as it started. I initially thought that the problem was that we had not followed the process correctly; We didn't meet frequently enough and we didn't work off of a list, and we never set short term expectations for what would and would not get done.

A short while after the contractor was mostly done with the project I discovered that things were worse than I thought when I received a surprise bill for "extra" work that was done months before. Given all of our communication and availability (towards the end we saw the contractor almost every day) how was it possible that we had such different expectations about the state of the project? I realized that the problem was deeper than simply not having the right number or kinds of meetings, or even having the right agreement (our contract stated that extra work needed to be approved in writing in advance). The problem was that the contractor didn't buy in to the idea that he had to be direct and honest about what he expected so that we could react. In other words, he had to actually participate in our collaboration for it to be successful. 

This would not be terribly interesting to software developers except for the fact that I've seen the same problem on Agile teams: the team follows all of the steps but there is someone (or more than one) who goes through the motions of the agile process, yet he holds back the team. I've been thinking about how to work with people like that.

The good news is that following the process lets you detect who "gets" agile and who doesn't. If you have a daily scrum and you listen to when people share what they are working on, you will realize if people are working on things that are not on the backlog. When checking up on this you need to be careful not to change the tone of the scrum from "sharing" to "status reporting" however.

Once you figure out that someone isn't keeping to the spirit (either not really sharing progress, or doing something else) you need to figure out:

  • Is it an honest mistake? Agile is different from what people are used to and there will be a transition time
  • Are they getting mixed messages? Perhaps the product owner is circumventing the backlog?
  • Do they just refuse to follow the process?

If the issue is one of the first two coaching can help. If the problem is the latter then you have to decide:

  • Do you work around the person? While that seems like the path of least resistance, this person can be a drag on the team.
  • Do you remove or replace the person?
I don't have clear answers for these questions and would welcome hearing comments. What I do know is that in the most effective teams everyone buys into the spirit of the agile process.

Comments (0)Add Comment


Write comment

You must be logged in to post a comment. Please register if you do not have an account yet.

busy
Last Updated on Tuesday, 10 July 2007 02:19
 

Agile Marketplace - Announcements and Special Offers

Webcast:  Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!

Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial

Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper

PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now