|
Advice for the New Leader As a new manager it's easy to fall into the trap of taking on more of your team's responsibilities than you should. Learn how to guide your team to success by stepping back and letting team members solve their own problems, learn from their mistakes, and most of all do what you hired them to do.
|
|
|
The Mission Is the Message A mission statement is supposed to guide and inspire the members of an organization as well as define the organization's purpose, the business it is in, and its responsibilities to its clients. Is your statement sending the right message?
|
|
|
The Myth of Risk Management Risk management is an illusion. We must recognize that software projects are inherently risky and admit to ourselves that it's not the known problems that are going to cause our projects to fail. It's the risks that are unmentionable, uncontrollable, unquantifiable, or unknown that make projects crash and burn.
|
|
|
Eight Reasons Retrospectives Fail Retrospectives work for most teams, yet some teams are convinced that retrospectives will never work for them. When Esther Derby came across several of these teams for which retrospectives had failed, she questioned why and discovered eight common reasons for those failures. In this column, she details these eight reasons and offers solutions for each one.
|
|
|
Applying the Inverted Pyramid to Agile Development Modern day reporters tend to write their articles using what is known as the "inverted pyramid" style. They start with the most important information in the first sentence, followed by the next most important, and so on. This format not only gives the reader the biggest bang for his buck as he reads it also gives both the reporters and their editors huge flexibility in their uncertain and fast-changing environments. Clarke Ching shows how modern software development techniques use the same idea to give customers the best bang for their buck—in equally uncertain environments.
|
|
|
When to Step Up, When to Step Back Leaders can stifle progress when they unnecessarily interfere with team processes. However, as a leader, you don't want your project to go over the cliff and fail miserably or deliver the wrong results either. There are times when leaders should stand back and let the team work things out for themselves—and other times when leaders should step up and really lead.
|
|
|
The Chivalrous Team Member Using the ten virtues described in Brian Price's modern code of chivalry, Martin and Mike illustrate the similarities between the best performing software team members of today and the Knights of the Round Table.
|
|
|
Opening the Door to Better Open Door Policies Many managers claim to have an open-door policy. They want to be available to their employees. But do they really have an open-door policy, or is it a handy name for a commendable intention? Naomi Karten describes the flaws in open-door policies and offers suggestions for making them work.
|
|
|
A Change Would Do You Good Visit any bookstore these days, and you will be faced with shelves of books whose titles claim they can make everything—from cooking to exercise—more interesting. In our industry, boredom is a problem that can affect your ability to solve complex technical problems. Discover how change can spice up your software processes.
|
|
|
Incremental and Iterative Development People get wrapped around the axle trying to understand the difference between incremental and iterative development. The Unified Process authors in the 1990s didn't help by indiscriminately calling everything iterative development. The two are different and must be managed differently. Successful teams do both at the same time, usually without thinking about it. Then someone starts thinking about it and does one without the other. Bad news follows.
|
|