From ad hoc to Agile
Darren Shipp made an astute observation during the recent Agile Success Tour event in Atlanta:
The problem is not transitioning from Waterfall to Agile. The real problem is transitioning from ad hoc to Agile.
This observation by Darren really resonates with me. Nowadays the preferred solution to various software engineering problems seems to be Agile. Latching to Agile, however, does not necessarily indicate that the software method in use has failed. Rather, it often indicates the lack of an appropriate software method/process.
Hence, my invariable counsel to folks who are about to embark on an Agile rollout: start by recording the state of affairs before the Agile rollout. For example, capture your productivity metrics for the period prior to training your teams in Agile. For better or worse, this is your true baseline.
The Agile Executive 
(Yes, really late to the party… 🙂
For quite some time now I’ve maintained an axiom:
* process must change your daily activities
I’d actually go so far as to say that process should change your hourly activities…
Waterfall, ad hoc, milestone based processes all can be easily gamed by spending your day doing… whatever. Then, when something important is looming you cram and deliver something.
Agile, Lean/flow, and any high-value and high-discipline process will change what and how people actually do things.
John Heintz
August 3, 2009 at 9:35 pm
A certain product line that was moved into my business unit some years ago was struggling big time. We did not understand why – the guys were no dummies. One of my directs ultimately diagnosed the problem: over the years we as staff became so Agile with respect to decision making that we made no sense whatsoever to the folks in this product line…
Israel
israel Gat
August 3, 2009 at 10:54 pm