Via Jack Vinson, I found this gem: Stop doing half-actions. All of you who are separating your developers from your testers? You are doing half-actions. Separating the writers from the developers and testers? Half actions there, too. Even when you define architecture and implement across the architecture, instead of by feature, that’s a half-action. A […]
About a month ago, I spoke with a project manager who’d inherited a project in chaos. No one was making progress. He was stumped–he’d never worked on a project where the developers couldn’t do anything, the testers couldn’t do anything, and time was just slipping away. I suggested he try baby steps. What’s the first
It’s winter here in Massachusetts, and we’ve had lots of snow, ice, rain, snow, ice, snow, ice, rain. All that freezing and melting plays havoc with the roads. We have lots of potholes, and the local and state governments are busy doing emergency repairs all over the place. (For those of you who don’t know
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’ve been working with some companies who do hardware/software systems. Most often, they have some embedded code too, just to make life interesting. To be honest, I don’t know how to do implementation by feature for a whole brand new system. Here’s what I’ve been suggesting: Prototype the software architecture as early as possible,
I had a discussion recently with a manager who was concerned about his developers meeting their milestones. “We have “Code Complete” as a milestone. The developers say they meet it, but that just means they wrote code until the milestone date. The code isn’t complete. I can’t even tell how complete it is.” Ah,
I taught a project management workshop earlier this week. I include a small project as part of the workshop, so participants can practice planning, organizing, and a little steering of a project in a safe setting. One of the project teams thought they were going to implement their project (a mobile), with an assembly
A few years ago, I received a call to help out a project in trouble. Unsurprisingly, when I was reviewing what had been done and what still left to do, the PM explained there were many half-implemented features. (The team had not been implementing by feature, but instead by architecture. Each architecture group had
I gave a talk at the local PDMA group called “Setting Expectations Between Engineering and the Three PMs”, attempting to clarify how the roles of product management, program management, and project management are sometimes confused, and to suggest practices that help people unconfuse them. I set up teams of people to create a little
I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem. So