What strikes me is that in the teams with good documentation all documents are good, regardless of author. How come? There could be several explanations:
- Good students want to work with each other (they could choose their teammates, they weren't assigned by us teachers).
- In good teams they cooperate on everything, inlcuding reviewing each others documents. In not-so-good teams they instead might try to split the tasks and work as independently as possible.
- In the good teams there is an exceptional student that functions as a mentor to the others.
- Excellent documementation from one role supports the others in their roles, e.g. an excellent architeture description supports testing etc.
- The good teams had not only a notion about what to deliver when they started, they also had a good notion on how to do it early on, e.g. they discussed so they had a common understanding of coding responsibility (everybody had to write code) and they choose an interative process or SCRUM already the first week.
- The good teams started with coding as quickly as possible. This is counterintuitive, but I think they felt more comfortable spending time on documentation if they already had some prototype running.
- It seems that analysis paralysis actually produces worse documentation. I think this is due to an inability to focus on the vital concerns and stop when they are sufficiently covered.
- It is hard to excel if your teammates drag you down. This could explain why there are no groups where just one role shines above the rest.
1 comment:
Based on my experience of working in teams and also observing other teams, I agree with some of your explanations. However, I have noticed the following also,
- If there is a large difference between skills/talent between team members then in many cases this created a virtual barrier. This barrier then resulted in exceptional member/s making a hasty decision or decision based on gut-feel rather than consulting all team members (extinct by instinct as wikipedia calls it). They would have made a right decisions just by asking opinions of those that are not considered exceptional.
- Team/s that start with coding as soon as they see requirements produced worse design documentation than that did design first. The problem is that, they think about code and design at the same time and when they have finished they are more likely to produce code and design document which are not consistent.
- I agree with you that teams that have a notion about what to deliver are likely to produce better results, and I have seen that such teams adapt better to changes in team/scope of work/development tools.
Post a Comment