A-Team Debriefs

From time to time we'll perform a debrief (aka post-mortem) on A-team projects, in order to help us learn from our past. We will record these here, and try to distill from them a set of common themes which can be applied to a variety of projects.

Past debriefs

• Datazilla Debrief

Common Themes

Project Management

• We have a tendency to be too focused on quarterly goals, even when it becomes apparent that the goal as written will not achieve the long-term purpose that the goal was originally written to address. We need to be more proactive about resetting goals and expectations as our understanding of a project evolves.

• We create time estimates (linked to goals) based on very little information; because of this, we set ourselves up for failure, especially with large and complex projects. We either need to accept the need to spend serious time in planning as a goal itself, and/or be more flexible with updating goals (see above).

• We can't assume that needs which need to be filled by another team (IT, rel-eng, security) will be addressed on our timeframe unless we do the work up front of helping them understand our needs and put it on their schedule. We can't blindly assume, for example, that IT will be able to deploy our service by a given date if we haven't even talked to them about it.

• If a project interacts with legacy projects, it probably will have to deal with a significant amount of technical debt. We have a tendency to underestimate how painful and time-consuming dealing with this will be.

• Related to the above, we often introduce new technical debt that will cause problems ad infinitum because we are rushing to get some project done; our "can do, get 'er done" attitude often works against us in this way. Although we can't always prevent this, we need to be more cognizant of the ripple effects of doing this, and push back where possible.

• We should question projects that have >3 weeks of development time required. Have there been prototypes done? Do the plans follow what the final prototype does?

Data

• We can't solve a data problem with a new UI.

• For projects that involve both a UI and some data, we need to spend time understanding the data before we can design a UI for it. We may need to build a throw-away UI to help us explore the data, but we shouldn't think we can start crafting the final UI before we've done any work to understand the data itself.

• Related to the above, we need to understand how data scales before we can build something that uses it. Strongly consider quick prototyping of the management and use of data and be prepared to throw the code away and try again a few times.