"Agile" Means Disciplined SCM (Software Configuration Management)
This article is also published on CM Crossroads.
Topic: Agile, ConfigMgmt   •   Date Published: 19 May 2010
For many people, Agile software development congers up the thought of "undisciplined" software development. The reality is that using an Agile approach to its greatest benefit requires discipline in a variety of ways. And none is more critical than the discipline of Software Configuration Management.

In Search of the Elusive "Best Practice"
This article is also published on CM Crossroads.
Topic: Process, Standards   •   Date Published: 21 Apr 2010
A friend and fellow consultant has been known to react quite strongly to the phrase "Best Practice". "There is NO such thing as 'best practice'!" James will inform you in his not-so gentle manner. "There are only good practices that are appropriate under certain circumstances!" While I tend not to be as adamant as James, I certainly agree with his thesis. You can't assume something will work for you just because it works well for someone else.

The Agile Customer:
Making Your Supplier a Bit More Agile
This article is also published on Project Connections.
Topic: Agile, Management   •   Date Published: 31 Mar 2010

"We are adopting an Agile method for our internal development projects. But on my project, some of the development work is being done by an outside contractor who is decidedly non-Agile! How can we be Agile when they are not?" Agility is relatively easy when you control all of the parts of the project. But when others are involved, barriers to Agility can begin to spring up. The best way to overcome those barriers depends upon your situation. So let's explore options for injecting some Agility in spite of the Waterfall raining down on you from your supplier.

Quantifying Risk: The Purpose of Testing
This article is also published on CM Crossroads.
Topic: Quality, Risk, Management   •   Date Published: 16 Feb 2010
Testing is such an integral part of our software projects that we often don't stop to think about why we do it. We must do it! What else is there to know? It is obvious that software that has not been tested is unready for deployment. But as painful experience has taught us, testing does not guarantee that the software is fit to deploy. Even rigorously tested software may still have hidden fatal flaws.

Fix It Fast vs. Fix It Right
This article is also published on Project Connections.
Topic: Management   •   Date Published: 13 Nov 2009

They were already doing Root Cause Analysis (RCA), but they were failing to get any real benefit from it. The heart of the problem with their RCA process lies in the fact they were mixing and confusing the two distinct and different ways that you can respond to any problem that comes along: 1) fix it fast, or 2) fix it right. They were trying to do both of them at the same time, which often isn't possible. They learned how to fix things fast, and so the "fix it right" part of the equation kept failing, even though they were trying to make it work. A deliberate Root Cause Analysis process will help them get to the bottom of a problem and fix it permanently, not just quickly.

Employee Recognition in an Agile Team
This article is also published on Project Connections.
Topic: Agile, Management   •   Date Published: 3 Sep 2009

Fred sent me this question: "I've read that recognition (in whatever form is most valued to the individual) is an important motivator. In the context of Agile team dynamics, I'm guessing that individual recognition could be counterproductive to everyone working well together, but recognition would be a better motivator if it were directed toward the entire team rather than just to a few individuals on the team that stood out. What do you think?"

The Agile methods are designed to make the work environment itself a motivator for the team members. But well-placed recognition can be a powerful addition – if it is done in an Agile way!

Change Management is not Change Control
This article is also published on CM Crossroads.
Topic: ConfigMgmt   •   Date Published: 20 Aug 2009
A key part of planning configuration management for our projects is determining how we will manage change. After all, "change happens", and any good configuration manager is concerned with how it is managed. Unfortunately, more often than not, our processes focus more on controlling change than on managing it! That is, we put a lot of effort into trying to keep change from happening, and relatively less effort into ensuring that when (not if, but when) change happens, we manage it effectively.