|
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 () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Blogs 
