The Latest

Peter Clark's company recently embarked on a "Lean Office" initiative. Now, Peter thinks many of you have steam shooting out of your ears just from reading those words. You probably think that it is just another lame management initiative that will take valuable time away from what is really important: coding and (maybe) testing. But in this week's column, Peter explains why this is the best initiative yet.

In January, StickyMinds.com introduced a new eNewsletter that covers tools and automation for the software development lifecycle. In this month’s Tool Look column, the editors of Better Software magazine and StickyMinds.com present a sample of what you can read each month in the Sticky ToolLook.

Have misplaced priorities or a lack of focus allowed your development project to run wild? Don't let a stampede of defects, repairs, and requirements change drive your project. Follow Robert Galen's advice, and corral that development with release criteria.

Poor software design will slow down even the most well-meaning code. Code smells are one element of poor design to watch out for in your projects. C. Keith Ray explains how you can start washing away your code smells with a dose of code refactoring.

When a crisis hits a business, you've got to work hard and fast to mitigate the negative consequences--a process which includes communicating with your clients. In this week's column, Payson Hall reminds us that keeping clients in the know is critical to a successful recovery and will stabilize the clients' faith in you, even when all has failed. Drawing from a recent crisis in which he was the client, Payson gives us key points to consider the next time we are overwhelmed by customers who want to know when business will return to normal.

True confessions of a certified project manager, tempted to abandon all she has been taught for her one true passion.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Agile Manifesto principle 12)

A cornerstone of agility is the team's commitment to continued reflection and adaptation. For most teams, there is a natural cadence to this process as iterations occur frequently, typically every one to two weeks apart, and releases occur every two to four months. As such, the iteration boundary represents a frequent opportunity for immediate feedback and quick mid-course correction, primarily focused on the team's ability to simultaneously define, code and test new functionality in a time box. At the release boundary, the measures move to those things that reflect the team and the organizations ability to move that functionality from "inventory" to delivered product or system. In this article, we'll describe a set of iteration and release metrics that have been used to good effect by a number of agile teams. In our experience, teams that are effective in using these iteration and release metrics have the best chance to achieve the maximum benefits of agile.