Tuesday, December 3, 2013

Initial Responses to XP

Most of our development team has been introduced to XP now. We agree that there are a lot of changes that need to be made. Some of these changes are internal to the team, and some require external changes. The two areas that we think need to start first are the XP team and short stories. Our existing team is both a huge team and no team. We have about 15 developers, a few testers, a few product managers, a few account managers who act as customers, and a project manager. The people are very friendly, and everyone helps each other in whatever way possible. The environment is very good for a team, however, team is pretty spread out physically and logically. I am a developer, so I am most familiar with the developer's perspective. It takes a while to talk to the testers or product managers, and it is nearly impossible to get the attention of customers in a timely manner. Many developers are very busy with their stuff, so it is hard to get help when I need it. I often have to wait several hours to get answers. No only is the team busy with stuff, everyone is busy with different stuff. We strive for collective code ownership by having everyone work on various portions of everything. There is a significant amount of code, and it takes a new developer weeks if not months to know enough about the code to be productive. In an effort to improve our bus factor, we assign developers to various portions of the system that they are unfamiliar with. The main problem with this is that they are individually assigned to a half-year project with little involvement from other developers. At the end of the half year, the developer is familiar with the code, but no one else is. So instead of whole projects having a single expert, we have many portions of projects having a single expert. We haven't really improved our bus factor much. To address these issues, we are attempting to have smaller and tighter knit teams. We will have testers and customers be more involved in the development process to reduce the amount of time it takes to get answers. We will try pair programming to improve the collective code ownership. Personally, I was expecting a lot more resistance against pair programming, but most programmers don't mind it as much as I had thought. We have been trying it for a few smaller sessions and it seems to work pretty well. Surprisingly, this is probably going to happen first before other improvements. It is likely to grow organically as well. While we get the team together, we will also tackle the problem of slipping deadlines. We came up with a long list of things to do to fix them, but the best thing we are looking at is just to create smaller stories that give us more milestones. We are going to divide up the 2-12 week stories that we currently have into smaller 1-3 day stories that we will be able to better manage. So all in all, we are hitting quite a few bumps in the road to XP, but we're excited about what kind of changes we can make to our process.

No comments:

Post a Comment