A senior leader, Jim, emailed me to clarify how to track a project’s progress. He’s a sales guy by training and is now leading a technology-based company. He’s confused. When he asks about progress, he feels as if everyone takes one step forward and two steps back, just as in the Project Kisses of Death […]
Ever since I was on the Troubleshooting Agile podcast, I’ve followed Squirrel and Jeffrey. (I highly recommend their podcast.) Recently, Squirrel posted something fascinating on LinkedIn: Aim for a “single source of lies” about your business. That’s quite a provocative idea, especially when many of us persist in looking for a “single source of truth.”
Joanie, a new VP Engineering, joined the company a couple of weeks ago. Her boss, the CEO, wants to know how long it will take engineering to finish all the projects. Joanie asked the various leaders these questions for every project in progress: When did you start this project? Are you still working on this
Daniel Vacanti and Prateek Singh graciously invited* me to be on an episode of Drunk Agile: Episode 37 Johanna Rothman Part Deux More Bigger Aging. (*Invited is their term. I sent them an email, politely demanding they discuss aging. Is it possible to politely demand? I tried. Only they can tell you if I was
Both David Maister, in Compensation Systems, and George Dinwiddie, in Agile Compensation, have useful comments about compensation systems. There’s something implicit in both pieces, that the criteria to move from position to position (as well as from one salary to another) have to be explicit. For years, I called this expertise criteria. You develop expertise
I taught my Pragmatic Project Management workshop in Israel last week. I was talking about defect charts and what they mean and how I use them. (No, I don’t include priority or severity data on defect charts; just # opened and closed by week and # remaining open each week. One of the participants
Jason Yip’s Hail Mary software development talks about what happens when you defer all the finishing to the end of the project. In the dashboard chapter of the book, I have a sidebar called “How Can We Have No Completed Work?” which talks about exactly the same thing. The more serial your lifecycle, or
I taught my project dashboard workshop today. One of the things most people want to measure is progress towards project completion. But you can’t measure project completion progress unless you have completed features: developed, integrated, and tested features. A completed feature is done enough for someone to use. Implementing by architecture leaves all the
I met a manager recently who relayed his technique for making sure his testers stayed focused on their jobs. “Our defect-tracking system logs people off after 30 minutes of idle time. If they’re logged off, I know they’re not working.” This was a new one for me. I’ve heard of counting lines of code.
I gave a talk entitled “Predicting Project Completion” at the Central Mass chapter of the PMI last night. I had some suggestions about techniques to generate and discuss schedule estimates. Then, to practice a little, I asked the audience to become participants and practice a simulation. The simulation is to first estimate how long