Roy Osherove taped my talk, “Nine Steps to Becoming More Agile” at the Israel Agile group meeting a couple of weeks ago. I was pleasantly surprised by how good the quality of the recording is. The recording isn’t perfect, because I walk back and forth across the room when I speak. I didn’t remember […]
© 2005 Johanna Rothman. If your agile projects are like most of the projects I’ve encountered, they started because a bunch of people already in your organization decided they needed to use agile techniques to be successful. Those projects have been successful, and now it’s time to hire more people. Now there’s an even more
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