Tuesday, June 2, 2015
Sometimes we intentionally make our work more visible so that we can more easily see what’s going on. We do this so that, as a group, we get a better picture of the whole of the group’s effort. At it’s best, this is more than a dashboard that displays information. Instead, it’s a tool that’s used by the people doing the work in the process of doing that work. (Continued)
Tuesday, December 4, 2012
In my experience, Agile projects almost never have a single milestone at the end. The business wants to see multiple milestones along the way, taking internal releases from the development team even if they’re not prepared to make them public. The simplest dashboard I know to illustrate this situation is a burnup chart with multiple goal lines, indicating the goals of each milestone.
This sort of chart is trivial to create by hand or with a spreadsheet. The typical Agile Project Management software, while providing a myriad of ways to view data, never seems to include something as simple and powerful as this. Fortunately, it doesn’t take much time to create your own. It takes a few minutes at the end of each sprint to update the chart, and you can make sure that the data is correct as you do so.
Tuesday, April 14, 2009
A new installment of the Agile Tool Podcast is available, where Bob Payne and I talk about Team Rooms. Please let us know what you think of this.
Sunday, June 10, 2007
I was reading Jerry Weinberg’s book, Quality Software Management: Vol. 2, First-Order Measurement, and came across the following:
Software’s nature is to be invisible, unless we work to make it visible…. During a construction project, we can see the building rising; but during a software project, all we may be able to see is a programmer staring at a screen.
This got me to thinking, as Jerry’s writing generally does. (Continued)