Many people who define requirements use some form of documentation to organize their requirements. Too often, that documentation is in the form of a text document. Because text is so bad at describing what a user interface does, the text becomes a design document for the user interface. Then the developers and testers are […]
I’m a fan of nightly builds with automated smoke tests, run overnight. In the morning when everyone returns to work, anyone who’s broken the build fixes it. In most cases, the developers see what they did and they fix it. The agile folks take this even further and say to build the system whenever
I just returned from my younger daughter’s fifth grade graduation. (For those of you without children, sixth grade is now part of middle school.) It was lovely, and reminded me of how important it is for us to have rituals or ceremonies for the ends of significant work. If you’re scheduling a project, schedule
At a recent presentation about agile project management, I mentioned refactoring. One of the attendees said, “No, I don’t want to redesign the whole application every iteration. Agile’s not for me!” Well, I decided I couldn’t address the resistance if I didn’t first start with defining refactoring. I said, “Hmm, refactoring isn’t the same
The zeroth measure of productivity is showing up. Sorry I haven’t been showing up, but I have to admit, sleeping is good 🙂 Ok, back to business. When I tried to calculate productivity of a team, here’s what I measured for one team over the course of five releases (Apologies to bloglet subscribers; tables
When we think about manufacturing work, we measure labor productivity as the ratio of the output of goods and services to the labor hours devoted to the production of that output, output per hour. (See U.S. Dept of Labor) Remember the discussion of Project Constraints and Requirements? That’s where I said the project requirements were
I’ve been thinking a lot about some of my clients’ problems managing their projects. Two of my clients are stuck on the notion that there is a silver bullet, one right way to solve their problem. Then I read Steve Norrie’s blog entry this morning, and saw this quote: “Nothing is more dangerous than an
I was extremely fortunate in my choice of companies and work early in my career. I developed in assembly language and microcode and Fortran for a few years. Then, I moved to object oriented languages, primarily at Symbolics, using LISP. At Symbolics (I left in 1990), we practiced incremental development, iterative planning, and some
Many project managers (and senior management) still have the mindset of “How much can we fit into this project?” instead of “How little can we do?” How-much thinking carries these assumptions (even if your managers don’t agree): People are a scarce resource, and that we should put all of them to use immediately, working
Don’t depend on a work breakdown structure to keep your project on target: Write it out to help managers, team members and stakeholders find consensus. “I can’t get senior management to agree on what I think the project is supposed to do,” a project manager recently complained. “The developers don’t believe me when I tell