The common thread for all human pursuits is our nature. This is best exemplified in our current economic crisis and the events leading up to the dénouement. Peter Schiff is a market participant and analyst who was scorned and laughed at for his prescient conclusions on the US financial markets and economy.
Read the full story »
Jerry’s challenge with raising the target donations is similar to the challenges we face in estimating and delivering software projects on time. He has no way to precisely estimate how much money he can raise in the 24-hour event, yet he has a target, and he always exceeds it. Similarly on software projects, teams are asked to deliver a fixed set of requirements on a fixed date, but unlike Jerry, we are rarely successful in delivering everything on time.
Recently, when playing FreeCell to take my mind off an essay I was writing, a thought occurred to me: FreeCell illustrates the value of upfront analysis and design. On a number of essays on yuwantitwhen.com, I’ve advocated that doing proper upfront analysis and design on our software projects is the best way to secure success for your projects and to shorten schedules. Similarly, in FreeCell, I’ve won more games on the first try when I devoted more time to upfront analysis and developing a strategy.
by Mary Poppendieck
Mary Poppendieck speaks at a Google TechTalk on the role of leadership in software development. She presents an interesting history on the philosophy of management and how it has morphed over the years to …
As a subscriber of Businessweek, I usually start from the back. That’s where Jack and Suzy Welch answer questions from the readers. In the June 30th publication, there is a quote from the Welch’s that hits upon a recurring theme of mine, and I’d like to share it. They talk about the challenge of balancing future requirements with current requirements.
The second quarter was another successful three months for yuwantithwhen.com. A number of essays were very popular with the site’s visitors. The most popular essay for the quarter was “Why It Takes So Long.” Thanks to Steve Johnson over at Pragmatic Marketing for directing his readers to the posting. There are often very good reasons it takes longer than expected to deliver a software product, but there are things that we often do to make projects take longer than they should. I’m thinking of writing the sequel to the essay: “Why it Takes Longer Than it Should.” I’m not sure when I’ll pen that one, but it’s in the queue.
The web changes everything. Now that so much software is offered for free, the cost barrier for switching vendors is gone. Consequently, high quality is even more important when the barrier to switching vendors is nearly zero. Many times, quality is more important to your customers than new features.
David Starr argues that Agile doesn’t work because business operations aren’t Agile, and his remedy is to have Agile business practices that embrace change: “Embrace continuous integration of the enterprise.” Customers don’t want continuous change; they want a great product the first time they purchase it, so they can spend more time serving their customers and invest more money on other important needs. While your product delivery is most important to you and your company, it’s likely not the most important need for your customer. Agile simply solves the wrong problem.
Delivering software requires courage. In “Extreme Programming Explained”, Kent Beck explains, “Sometimes courage manifests as patience.” The practice of software development requires the leaders and the team to have faith in their development practices and the courage to stay with them when fear gives you doubts. Who said software development is easy?
They said it wouldn’t happen again, but it did. The American auto industry wouldn’t be caught unprepared again when another energy crisis were to hit the economy. Sure, consumers were all too complicit by indulging …
Project management is a continuous process of planning, executing, measuring, and re-planning. It’s the process of meeting your commitments in spite of all the change and obstacles along the way. It’s a tool for managing change and complexity. It’s hard, and because some aren’t successful with it or don’t do it well, it doesn’t mean that project management is not valuable. Sometimes we blame poor execution on the process or the tools, but too often in software management it’s the skill that is at fault. The difference between the 300 Avg. batter in baseball and the 200 Avg. batter isn’t the bat, the ball, or the rules of the game, it’s the skill of batter. If we can focus on the skill rather than debate the need for the tools, we can progress the practice of software management to higher levels because skills can be improved with practice and education.
