My primary complaint about scheduling is simple: that people are willing to proceed as if they can look into a crystal ball about the future. They act as if they can plan out the future. As if they can control the future. It’s the control part that really gets to me. It bugs me because it’s a false belief. It’s simply not true. You can not control the future, and the belief you can is just so destructive of creativity, teamwork, spontaneity and interaction among one another. This false belief is just a complete energy zapper, an unwholesome energy sink. — Michele McCarthy This transcript of a Jim and Michele McCarthy podcast is the best discussion of scheduling I’ve read today, maybe ever . . . Read more →
EppsNet Archive: Software Development
We Don’t Need No Gantt Charts
One challenge we’re facing is that some high level executives are now concerned over how the project is progressing and want regular updates–they are used to Microsoft Project GANTT charts, excel charts with deadlines and stop lighting (e.g. yellow light, we’re behind schedule but it’s not critical). How do we map our agile process into the traditional project plans used by upper management for their corporate planning? — Mark A. Herschberg At the Deep Agile seminar he and I did, Jeff Sutherland told of being asked for a GANTT chart or such. He asked the execs in question how accurate those charts were. They replied that they were never accurate. He declined to do them. — Ron Jeffries Read more →
The Perfect Boss
In addition to the timely pay for acceptable services he offers, there are a few additional conditions that he imposes on you, if you are one of his subordinates. These are: What actions you take, you believe in. What commitments you make, you keep, What resources you have, you use. What words you say, you believe to be true. What you create, you intend to be great. He knows that if you buy something from an expert, you are wise to let them to deliver it on their own. . . . He requires that the team credibly believe itself to be doing something great, and also insists that all involved relentlessly pursue – and always adopt – what they think is the best available idea. . . . He never allows people to say, “People say…” If unidentified “people” have something to say, they can come say it.… Read more →
What I (Re-)Learned Today
An ironclad but widely ignored law of software development — you could probably substitute “product development” as well: Customers never understand how something is going to work until they see it in action. Thus spoke The Programmer. Read more →
Hitting a Moving Target
IT has got to be the world’s most unprofessional profession . . . I’m sitting through a dry run of a presentation for our CEO, explaining why the company’s flagship IT project has taken so long and cost so much, with no end in sight. It seems that, compared with two years ago when the project started, headcount is up 60 percent, sales volume has more than doubled, the product mix has changed significantly, as a result of of which, requirements and assumptions have had to be constantly changed. Of course! Two years ago, who could have anticipated that the business might look a lot different two years down the road? If you said “Uh, pretty much anybody,” you’re right. Thus spoke The Programmer. Read more →
Predicting the Unpredictable
A long range weather forecast should be obtained before leaving, as weather conditions are extremely unpredictable. — Natal Daily News I pulled that quote from a Ron Jeffries sig file. It’s a great Zen-like nugget that sums up the typical approach to software development, i.e., it’s an unpredictable business, so we’ll do lots of upfront planning . . . ignoring the fact that the inherent unpredictability makes dependable upfront planning impossible. Read more →
Something I Learned Today
When you’re meeting with the people responsible for a company’s software development process being the way it is, any suggestion that it could be improved is going to be a tough sell. Prepare to hear something like this: “We didn’t get where we are today by doing things wrong.” Thus spoke The Programmer. Read more →
Competitively Compelling
Ken Schwaber on software quality: I think what will happen is some places will really get it and will be so competitively compelling that others will have to rapidly change or go out of business. As an offset to that, consider that Ford has known for 40 years how Toyota builds cars. Read more →
The Can Do Manager
Staring your boss in the face and saying June 1 when you know that even a year from June would be optimistic sounds bad. It sounds like lying. But being a Can Do manager sounds good. — Tom DeMarco, Slack Read more →
When is a Release Not a Release?
On this morning’s enterprise IT conference call, one of our project managers announced the successful release of Project Foobar. Then a woman’s voice — I assume it was the business owner — came on and said, “We had to pull that back out.” “Is that true?” the PMO manager asked. The project manager continued on in the same tone as before: “We had to pull it out after release. The customers are using a manual workaround until we resolve the issues.” Business owners rarely participate in these calls. I assume that had this particular business owner not been on the call, the minor detail about backing out the release would never have been mentioned. Believe it or not, an argument then ensued regarding whether this could be credited as a successful release, with the additional work considered as “post-release” effort. Read more →
How Long Should it Take to Define a Project?
Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition. To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million. At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority. This reminded me a lot of an article I read a few days ago: What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher… Read more →
EppsNet’s IT Responses
Inspired by Don Carman’s Reporter Responses, a handy list for the IT professional: Good, fast, cheap — pick two. It’s not a show-stopper. It’s a show-stopper. It’s out of scope. It’s not rocket science. It’s not brain surgery. Let’s not reinvent the wheel. That sounds doable. I could do it myself in a week. That’s why I make the big money. It works fine on my machine. It was working fine 10 minutes ago. It’s a best-of-breed solution. It’s an enterprise-class solution. It’s a state-of-the-art solution. It’s an industry standard. It’s a best practice. It’s not one of our core competencies. We’re waiting on requirements. We’re waiting on design. We’re waiting on the vendor. We found some issues in testing. We’re thinking outside the box. Add that to the lessons learned. That’s a ballpark estimate. I’m working smarter, not harder. There are no problems, only opportunities. Since when did you… Read more →
Standard Methods = Standard Results
This is an excerpt from a job posting for a Sr. IT Project Manager: Develop project plans and ensure that deadlines are met on time and projects are delivered within budget constraints. You will use standard project management tools to define requirements and track project status. Manage and prioritize projects for the division using standard project planning methods and software through all phases of the project/development lifecycle. OK, let me get this straight: You want projects delivered on time and within budget — you don’t mention whether or not you want the software to actually work, but I assume you do — and you want it done with standard tools and standard methods. It may have escaped your attention, but that is not a standard result. The standard IT project is either late or over budget or fails to meet customer expectations, or all three. If it were possible to… Read more →
A Hug from Your Mom
Replacing an on-site customer with some use cases is about as effective as replacing a hug from your Mom with a friendly note. — Ron Jeffries Read more →
Practices vs. Accomplishments
Per our Head of Software Development, IT managers are henceforth being evaluated on the “quality” of their status reports. A little background on this: We have a weekly conference call during which managers report project status. Every week you the hear the same things over and over: We’re waiting on this. We’re waiting on that. We’re working on requirements. We’re figuring out the architecture. We’re doing the design. Very rarely does anyone say, “We delivered working software to a customer.” Even more rarely does anyone say, “We delivered working software to a customer, the customer is using it, and can’t stop raving about how great it is.” What would be our motivation for evaluating practices rather than accomplishments? When I do projects, I like to be evaluated on one thing: my ability to deliver business value to a customer. Everything else is waste. Thus spoke The Programmer. Read more →
Why Craigslist Doesn’t Have Text Ads
The privately held Craigslist has been approached about installing text ads on the site, and the potential revenue is “quite staggering,” [CEO Jim Buckmaster] said. But, Buckmaster deadpanned, “No users are suggesting we run text ads.” — Associated Press Craigslist is an exception to the rule that a lot of Internet companies talk about putting users first, but when it comes down to a tradeoff between what users want and a boatload of money, they go for the money. Read more →
Criticisms of the Standard Waterfall Model
There have been a number of criticisms of the standard waterfall model, including Problems are not discovered until system testing. Requirements must be fixed before the system is designed — requirements evolution makes the development method unstable. Design and code work often turn up requirements inconsistencies, missing system components, and unexpected development needs. System performance cannot be tested until the system is almost coded; undercapacity may be difficult to correct. The standard waterfall model is associated with the failure or cancellation of a number of large systems. It can also be very expensive. — “The Standard Waterfall Model for Systems Development” Read more →
The Prepared Mind
Chance favors the prepared mind. — Louis Pasteur Today is the dumbest day of the rest of your life. If you’re doing a software project, you should know at least a little bit more about the project tomorrow than you do today, the next day a little bit more, and so on. Don’t get into detailed decisions and plans at the beginning of the project. Defer decisions to the last responsible moment; that’s when you’ll have the best information available. Upfront planning is not for the purpose of generating plans, which quickly go obsolete, but for the purpose of creating prepared minds with which to face the uncertain future. Read more →
Three Reasons for Software Project Failure
Jerry Weinberg‘s top three reasons for software projects going over budget or failing to meet their original requirements: The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have). Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong — and something ALWAYS goes wrong. In 50 years, I’ve never seen a project where something didn’t go wrong. When it does, the project’s success is determined by the leaders’ ability to manage themselves emotionally. Read more →
A Forceful Dose of Reality
. . . there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project. Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements. — Martin Fowler, “The New Methodology” Read more →