I’m close to falling into “Crossing the Desert” syndrome. A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert […]
Tristan, the senior manager in charge of all projects, strides into Ilene’s office and plunks himself down in her visitor’s chair. “Ilene, you are the project manager in charge of the project to save the company, right?” Ilene nods. “I really need you to fit this other feature into this release,” Tristran says. “We’re toast
Contents: This month’s Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 3 Announcements =-=-=-=-=- Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 3 In the previous two issues, I suggested some approaches for making a waterfall work for you. If you missed either of those issues, see Waterfall Part
Contents: This month’s Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 2 Announcements =-=-=-=-=- Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 2 Last month, I suggested some approaches for making a waterfall work for you. If you missed that issue, see <https://www.jrothman.com/pragmaticmanager/waterfallpart1.html>. Assuming you’re somewhere in the coding
Contents: This month’s Feature Article: Discovering and Maintaining Your Project’s Heartbeat, Part 1 Announcements =-=-=-=-=- Feature Article: Discovering and Maintaining Your Project’s Heartbeat Some projects zoom along, making progress regularly. Others feel as if they slog along, with barely any progress from week to week, or worse, month to month. Why? The zooming projects have
Normally, I’m huge fan of continuous integration. Continuous integration is when everyone integrates his or her code every day, preferably as each little tiny piece is built and tested (or in the case of test-driven development, tested and built). The developer checks his or her code in, does a local build, checks the build, and
Joshua asked me to clarify what I meant by implementing by architecture. Here’s my picture-story. When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture. When a team implements by feature, they are cross-functional teams. When teams implement by feature, they do what’s needed in whatever part
Scott points out Software Product Delivery – 20 Rules? that you should do the riskiest part of the project first. (He explains that you modify that given what’s most important.) I’d add a further refinement: that what’s most important better provide the most value. If it doesn’t, do the most valuable parts first. You
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’m writing part of the PM book, and said this about the minimum requirements for a configuration management system (CMS): Modern CMSs can branch, label, automatically merge multiple authors’ changes, and allow for developers to work in their own private workspaces (sandboxes). If your CMS can’t do that, dump it and obtain a new