Barry Boehm famously said, “Poor management can increase software costs more rapidly than any other factor.” If that’s true, then we should be attending as much to management practices as we do software development methods. In this article, the author describes five pragmatic practices that will help managers focus on the right work and create an environment for success.

Lessons learned during a Scrum training at Ericsson about the transition to agile software development.

Scrum promotes cohesive, self-organizing teams. Scrum teams are tasked with finding the most optimal way to accomplish the work. To do this, they make decisions ranging from how best to meet goals to who should work on which tasks. Reaching group consensus can be difficult. Some opinions are more dominant than others; some voices more hesitant to speak out. Even in agreement, true consensus might not exist. One manifestation of this is the Abilene Paradox.

John Brothers discusses his successes and failures in implementing agile processes in his workplace, and draws conclusions on the general acceptance of these methodologies.

Back in the '90s, self-managed teams were gaining popularity, but they had a high rate of failure mainly because team members lacked people skills. These ideas of self-managed teams were borrowed by the Agile movement when, in 2001, they formulated a ‘new’ way of working, based on Agile principles. These principles value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. For these ideas to work in practice, Agile team members must know something about teamwork, and this means understanding a lot about human behavior and why people do the things they do!

This article introduces the idea of "Gold Cards" to Extreme Programming. Gold Cards are intended to allow programmers to work on tasks of their own choice which the authors claim leads to increased innovation and a higher sustainable pace on the project.

This article is a look at situations where communication among team members is a critical factor in the potential failure of a program or its success. This is not a deep technical article, but I believe it is thought-provoking. When humans communicate in written, verbal, and non-verbal forms, many times the receiver misses the intended meaning. The “failure to communicate” is the root cause for many program failures more times than we would admit or appreciate.

After a short introduction to what the Personal Software Process (PSP) is, we will highlight the ways in which individual engineers (and their organizations) can benefit from adding the PSP’s Personal Quality Management techniques to their professional repertoires. We will take a brief look at the benefits that have been achieved by those who have already learned to apply these principles in their work. Then we will examine in more detail the specific activities PSP-trained engineers engage in to manage the quality of the software they produce. We will look at everything from simple defect logging, to personal and peer reviews, to developing a personal quality plan and using it to guide your work.

The best-known writers in the software field have been advocating the same four recommendations written in the “Agile Manifesto” for decades. While many in the field continue to ignore their recommendations, others are re-discovering their sage advice.

This article discusses specialization in Scrum teams.