If you have multiple projects and multiple developers you might need to decide if you should dedicate a developer to each project or create teams that can work on all of the projects. While there might be some good reasons to silo work to specific individuals, you should also keep in mind the following benefits of assigning work to a team.
1. More Flexibility
Teams can respond better to unexpected changes in priority / demand. If one project becomes the priority, then the team can shift focus to that.
2. Better Bus Factor
If a only one developer knows about the project, then they become a single point of failure. This is known as the bus factor. Sharing projects with all of the developers on the team can spread knowledge across the team and reduce the likelihood that losing a single developer will bring the project to halt.
3. Higher Quality
When projects are shared across the team, team members can participate in design discussions and code reviews at a deeper level. If independent verification of work is necessary, it’s very easy to share this task across a team. If Bob writes a feature then Anne can functionally test that feature w/ a fresh perspective that Bob might not have. And vice versa if Anne writes a feature, Bob can functionally test it.
4. Improved Morale
It’s great to have the feeling that you aren’t alone in the work you are doing. There are other people to bounce ideas off of who have the same context you do. If the work becomes overwhelming, there are others who will chip in to help. Working on a single project can also become tedious. Having a variety of projects to work on can help reduce burn out and boredom.
A WIP limit really depends on the team and what you are trying to accomplish. WIP Limits can encourage team work, expose bottlenecks and reduce multitasking.
To encourage team work, drop the WIP limit lower than the number of people on the team. For a team of six developers, a WIP limit of three would mean that every developer was pairing up to work on a story. If you wanted to try out mob programming you’d drop your WIP limit to one. If you want each developer to work one thing as individual then set your WIP limit to the total number of people on the team.
To expose bottlenecks in a specific column, drop your WIP limits on that column. That will force the team to swarm on the problems that are causing the back up.
To limit task switching reduce the WIP limit. If the WIP limit is less than or equal to the number of developers on the team, then developers shouldn’t be working on more than one thing at a time.
Closing the retrospective provides moments for continuous improvement, for reflecting on what happened during the retrospective, and for expressing appreciation.
I’ve recently lead a few retrospectives with teams that are new to a five step retrospective. I wanted to keep the closing activity as quick and painless as possible. I found an activity on plans-for-retrospectives.com called Feedback Door – Smilies. I modfied this a bit for the retrospecitves I led.
Smileys on the Door
Hand out stickies and sharpies to all of the participants.
Draw a smiley face :), meh face 😐 and a frowny face on a whiteboard or a stickes so everyone can see.
Explaing that, “This last activity is to close and gather feedback on this retrospective. Take a moment to think about the retrospective as a whole and then draw a smiley that represents how you feel. How did you feel about the activities? How did you feel about the things we decided to do? When you are finished, you can stick your smiley on the door as you leave.”
In a recent retrospective a question came up about morale. That triggered a memory about an activity for tracking the mood of a team. I tried to recreate the activity as best as I on the spot. This is how it went. We passed around sticky notes, everyone drew a smile, meh, or frown face to capture their overall mood from the previous sprint. The papers were folded / crumbled to keep them anonymous. The votes were then tallied and then we discussed the results.
Obviously this method of capturing morale can lead to skewed results. It’s hard to sum up or even remember all of the things that affect your mood during a sprint. If someone is really happy or mad on the day of the retrospective, that might lead to an overall mood that doesn’t take into account the other days of the sprint.
Since I’m a developer my mind naturally jumps to solving this problem with software. So I wrote up a little application to track my team’s happiness. The code is available at github.
The inspiration for this comes from the niko-niko calendar. One major difference is that this project is designed to “anonymously” track moods. Data is captured at a cookie level to link a single users stats over time, but there is nothing that will identify that person beyond what the put in their notes field.