Some aspects of a project methodology needs to be fine-tuned based on the project mix.
Some time ago, we wrote up this list of things that a project team should try to talk about shortly after the project starts.
|Process Monitoring||to what extent do we need to be aware of the evolution of our process, do we need to monitor it, if so how will we do it and who will do it (the coach, the customer lead?)|
|Pairing||how much (e.g. all production code?), when and how often should pairs switch, is experience level matching important (e.g. more with less), is it important to have good pair shuffling (i.e. if a developer seems to always pair with only one of two other developers, is that a problem), how do we deal with differing schedules (e.g. 8:00 ? 5:00 vs. 10:00 ? 7:00), mid-way through a task do we wait for our pair before starting in the morning.|
|Story development||when do we task out a story, how many open stories at one time, how do we know when a story is complete?|
|Stand-up meeting||when (e.g. always at the same time or once everyone has shown up), how long, who runs it (e.g. customer lead or maybe a developer at random), do we really have to stand up, what kind of things should we talk about, does it include tracking yesterday?s progress, what do we want to get out of it|
|Tracking||who does it, how/when do we do it, what do we use tracking for (e.g. to improve task & story estimation, if so how and when should we do this), do we track/report story percentage complete, if so how is this percentage established|
|Team status meetings||how often, who runs it (e.g. customer lead or maybe a developer at random), what do we want to get out of it, does the client attend, should we discuss the velocity estimate?|
|Velocity estimate||how do we determine it ? yesterday?s weather but ? do we use partial story points or is an uncompleted story a ZERO, what about stories that are 95% complete, who determines it (e.g. team lead or team consensus?), what do we tell the client at the beginning of the project about the velocity estimate (e.g. how it is calculated, what it?s for, how we expect it to be used at steering meetings)|
|Steering meeting||who from the development team should attend (e.g. customer lead and tech lead, or the whole development team?), how do we present velocity, how is velocity to be used. Think of scenarios: what if our velocity estimate was 4 and we only completed 1, what does that mean for the next development cycle, how do we present that to the customer team? Should demos be included in every steering meeting?|
|Coaching||do we need one (or more), if so what would the coach?s role be.|
|Communication||open communication is crucial for project success, but what does that open communication mean. How do developers feel about it. How do we minimize the build up of friction in the development team and disperse it when it builds up.|
|Integration/Build frequency||how often should we integrate/build, how much time between integrations/builds.|
|Scheduling of meetings||fixed time or ad hoc|
|Use of white-board space||how do we arrange story cards, task lists etc.|