During the many years Lee Copeland has been a software consultant, he's logged quite a few travel miles and amassed numerous tales from all over the world. This story, originally published on StickyMinds.com in November 2001, takes place during and after the September 11 attacks.
Assembling a group of people and declaring them a team doesn’t make them one. Do you have the conditions necessary for the team to form? What activities have they completed to help them find an identity, their purpose, and how they’ll interact with each other?
The portions of projects that are not yet complete occur in the future. Since the future is an uncertain place, there will always be surprises. Some surprises are so obvious that they should hardly be called surprises at all. This is the kind of surprise that project management helps to avoid.
On the surface, a Broadway musical, a newspaper, and software may not seem to have much—if anything—in common, but they have one common thread. All are delivered on a fixed schedule. But of the three, software tends to stray the most from the fixed schedule. In this week's column, Jeff Patton says that by focusing on the readiness of the entire product—as done in theatrical performances and when publishing a newspaper—and not just on the completion of the planned bits of work, you can produce software on a fixed schedule that you know is ready to ship.
The pace of production depends on the capability of those at work. When an increase in profit is desired, production is sped up. Yet those forced to work faster aren't necessarily more productive. Unhappily experienced at being forced to work harder and faster resulting in less productivity, Clarke Ching found a way to slow down expectations and increase productivity.
When it comes to the conversation between a project management team and a client, many complaints lead back to the same root cause: failure to manage expectations. Here, Payson takes a look at some of those complaints and reminds us that work product definitions aren't the enemy.
Nirav P Assar uses Malcom Gladwell's best selling book , The Tipping Point to discuss what's necessary to fully, and successfully implement agile, in order to take advantage of all that it can bring to a software development team.
Whoever claims that work has no room for play or play might not be a form of work may not know about the serious purpose of agile games. You can learn from games, use them to instigate change, innovate, and make product decisions. This week's column explores how Mary Gorman selects, plays, and designs games. Mary explains how games improve collaboration, deepen learning, and help teams focus on value delivery.
Imagine yourself as the owner of a fishing company in need of improvement. Fortunately, a management consultant has come to you with his Fishing Maturity Model and its promises to save the day. Now, as a fisherman or a software tester, will you accept the maturity model hook, line, and sinker?