Project Start-up

Work Practices

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.

Item Description
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.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply