As we discussed last time, our team is too big for this project. Getting 3 guys to build something that integrates nicely in 3 weeks is hard enough – how exactly are we going to do it with 8?
Well our first step was to recognize the problem and identify the risks of a large (oh, and did I mention it’s also distributed) team?
- Communication – without constant communication, we’re doomed to building 8 different products. Hipchat, daily stand-ups, and a pervasive culture of collaboration to the rescue!
Turns out, several of our guys have worked together previously and are used to working in remote locations and communicating frequently. As for the rest of us, we’ll follow their lead and error on the side of over-communication, at least for the next 3 week.
- Silo’d Code – No point in mulitple folks working on different components if they don’t talk to one another. Mitigation? If you’re working on something that interfaces with another component, see bullet point #1.
- Quality – What level of testing does this project need? We’re developing in Ruby, which is sans a compiler, so some amount of TDD makes sense. On the other hand, we don’t need to worry about testing CRUD operations because that’s all handled for us.
Our final decision was for people to “be smart” and build tests where it will catch errors that would otherwise trip easy bug fixes and leave “integration test” to a maybe down the road.
- Scope Creep – There are two ways we’re avoiding scope creep. First, wtf, we’ve got 3 weeks. Don’t do it!
Second, we’re using AgileZen to create stories and devs will pick off the ones that make sense for them (and implement nothing else).
Alright, so those are the issues we raised and our mitigations. Would love to hear what others we need to keep an eye on and, even better, ways to address them.