My First Agile Project Part 10: 5 Important Issues for Teams
I’ve written a lot about mistakes we made and the parts of Scrum we didn’t follow, to our detriment. We’ve got a late, still as yet unlaunched project, reduced credibility and lowered morale. And yet, even with all this going against us we still have one big thing going for us: an incredibly strong team. In this part of My First Agile Project I’m going to address this issue of teams and the importance of strong teams in Agile projects.
Read on for 5 important issues teams should look for. Some are good things, some are bad. But I believe we have a strong team and hopefully our lessons can provide some insight into building a strong Agile team.
**
- We’re all friends.**
Everybody on our team are friends. We hang out after work, we joke around; even if we didn’t work together we’d be friendly. I’ve worked at places where everybody was friendly and I’ve worked at places where everybody talked about everybody else behind their backs. Since Agile teams are supposed to be self-managing, it really really helps if people at least get along.
The problem with this is obviously if your team doesn’t get along, you can’t force it. Plenty of companies try to do “team building” exercises and these are even less effective for programmers than for other types of workers. Unless you’re trying to unite your team against management (which can be an effective tactic actually), you can’t build teams by doing inane activities. One thing you can do is try to split people up into smaller teams of people who get along. Having teams of friends contributes to the next couple of important issues and is vital for those reasons.
2) We communicate
The biggest benefit of being friends is that we talk. We talk about how we solved certain problems, we talk about things that went well and things that didn’t. If something is taking too long to finish, somebody will ask if they can help. Not only do we talk as a team, we talk to our Product Owner and she’s as much a part of the team as anybody. If we don’t like an idea she has, we’ll try to talk her out of it. This all contributes to the strength of the team.
An Agile team shouldn’t be just a bunch of people taking orders and going back to their cubicles to code/design/whatever. An Agile team is a team of professionals who should work together on their project and hash things out as a team. If your team isn’t talking, they’re not working at the level they should be.
3) We share work
During our sprint planning meetings, our practice was to assign work to specific individuals. Some people advocate assigning work to the team but we never had a problem giving work to people because we all knew it was really the team’s work to complete. None of us had a problem taking other people’s work if they got done early. Of course people’s first instinct is to be optimistic about finishing their work and not to voluntarily say they need help, but when everybody is friendly the risk of judgment is lower and people share their status and give up work more easily.
4) We Play
“Team building exercise” is kind of a joke around our department but we do things together regularly. Awhile ago the company was kind enough to pay for everybody in the company to go to the movie theater across the street for team building, my first exposure to the phrase. We all questioned how much team building could be done sitting in a dark room for 2 hours but it was a free movie. From then on though, whenever a new must-see nerd movie came out we would take off for a long lunch on Friday and see a movie as our own “team building exercise”.
In addition, at the end of our month-long sprints we would always try to do something as a team. We went miniature-golfing, bowling, out to dinner and drinks a few times, just drinks a few other times, things like that. We’ve also gone to a local laser-tag place for long lunches a couple of times, which is great fun even for the people who don’t think it will be. I really recommend activities like this for teams, it builds the team up without being any kind of explicit corporate-endorsed exercise. Even if your team is new or not up to friend status yet, everybody likes shooting at each other or beating the others at a fun game like bowling or miniature golf.
5) We let people go
The hardest part of keeping any team going efficiently is knowing when people just don’t fit. We (meaning our managers really) have had to let people go from the team twice during this project. The first was a programmer who just wasn’t picking things up quickly enough. When you’re sprinting, you can’t give people the same amount of time to come up to speed as you might on a regular project. The second time was someone who was slow and also didn’t follow our sprint procedures the way the rest of us did. He didn’t tell us during our morning sprint meeting that he was still working on something for the 3rd day and didn’t stick to the tasks assigned, taking half a day to work on random other things. These kind of things just take too much time to deal with when you’re packing each sprint to the gills with work and trying to get everything done. It’s incredibly difficult to get rid of people, but the integrity and efficiency of a team can’t be compromised when you’re in the middle of a project.
Conclusion
A good team can make up for almost any other deficiency in process. A good team can make a good product with no process or bad processes. A bad team can make a bad product no matter what. Good processes can’t help a dysfunctional team. A good team, with good processes, can make a good product and can make it fun. Increasing communication is the single best way to improve your processes. Helping people share information is good for cross-training, sharing the workload, and for increasing morale. Making a good team isn’t a magic, but it’s not easy either. If your process just doesn’t seem to be working or your team is going slower than you all think you should be, you might take a close look at how well your team gets along and work on that first. I know the strength of our team has helped us immensely through some pretty rough spots.
Please share any ideas you have for real team building in the comments. Thanks for reading and I’ll see you back here next Monday! You can also reach me on Twitter as mattgrommes.
My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool - VersionOne