I presented a webinar today, Becoming a More Agile Tester. Here’s the PDF. (It’s a talk, so if you read it and think you’ve missed something, you have. Send me email with your question.) I’ve been thinking a lot about test assets these days, and here’s a highlight from the presentation, a comparison of […]
I’m at PNSQC this week. I gave my metrics talk yesterday, and something occurred to me: in traditional projects, we’re used to measuring what’s been done. In agile projects, we measure what’s left to do. I just realized yesterday that the difference in how we measure makes a difference in how people feel about
In general, technical people don’t seem to make great managers (unless they’ve been trying to become great). A result of that is what Reifer says in his IEEE Software (May/June 2004) column Catching the Brass Ring: “software professionals aren’t often tapped for top corporate leadership positions.” He goes on to say “executives of my
You’re a project manager. You have too much work to fit into a project (scope) and not enough time to do it. What do you do? Timebox. Timeboxing is a technique to fit what you can accomplish (some of the scope) into the time you have allotted. Timeboxing works when you have fixed schedule
In response to my most recent Pragmatic Manager (about shortening project startup times), a colleague wrote: “I am working on a lifecycle definition team in my department and finally convinced the team that Agile Development was a Methodology using an Iterative Model lifecycle.” My colleague has neatly described the methdology (the practices) and the
I spoke at a joint meeting of the RI PMI and ASQ last night. My presentation was “Predicting Project Completion.” I offered a simulation for people to try: predicting the time it would take and then sorting two decks of cards. We learned a lot and had fun. At the end of the meeting, one
I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation. IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months)
Last night at my SPIN talk someone came up to me at the end of the talk. I’d discussed earned value and inch-pebbles in my talk but hadn’t specifically discussed how to avoid the dreaded “percent complete” reporting problem to management. The percent complete problem occurs when you have to report progress to management as
On the face of it, higher productivity looks like a Good Thing. More products for less time. Who wouldn’t want this? But I wonder about this search for higher productivity. What do managers really want? If you want to understand about productivity for software organizations, read Putnam and Myers’ new book, Five Core Metrics:
I’m at the 13ICSQ conference this week. One person (at least) was confused about agile processes: Conference attendee: “Agile processes are a license to hack!!!!!!!” JR: “No. Every agile team I’ve seen is highly disciplined. No hacking there. I’m sure there are people who say they’re performing agile development, and they’re just hacking, but truly