Burndown charts are one of the most common artifacts of an Agile software development environment. As a tool to provide insight for management into the state of a project, burndowns are useful and easy to understand. As a tool to motivate developers, they are counter-productive and often abused. The information contained in a burndown chart should be largely irrelevant to the day-to-day work of a developer. Let's consider a scenario: assume you have a team of developers who are skilled, intrinsically motivated (i.e. enjoy their work), and focused on delivering the highest priority features as defined by the product owner. Now assume the burndown chart displays a slope indicating that the project is behind schedule. What is a developer supposed to do with that information? What actions or behavior is he or she supposed to alter based on that knowledge? Let's consider his or her options: (1) Cut corners to go faster. This is obviously short-sighted. By omitting criti...
Inspired by the ideas of W. Edward Demming, Taiichi Ohno, Tom DeMarco & Carol S. Dweck