Agile isn’t about producing products faster than other methods. Agile isn’t about working faster than other people.
The single most fundamental concept in “agile” is the speed of feedback.
There are at least 2 very important sources of feedback that can be leveraged in this way.
One is the work accomplished to date, seeking confirmation and reaction from its potential customers / users / buyers. Users’ experiences with a product can provoke appropriately creative new ways to extend that product, or product concept. These are ideas that weren’t stimulated into existence PRIOR to an interaction with that product. Action sequences can be reorganized, refactored, based on mockups, prototypes, and indeed, even complete iterations on infrastructure and end-to-end use cases or user stories, as the work takes shape. This is appropriate and ought to be leveraged by teams with good work practices – why let good ideas go to waste just because they weren’t in the “signed off spec”?
Another is life itself. What can break other execution models and methods is that in the time it takes to perform a a plan, or even just a single stage of a plan (be it specification, elaboration, design, coding, etc.), the world can change in the time it takes to perform that stage. Big plans have big components of the plan, typically. These stages take time to perform. If during this time, the world (read: customer needs, business ecosystem, market conditions, world events, available technologies…) changes, then there is little opportunity to reflect these changes, except via laborious and high-overhead (speed-killing) “change control boards”. So viewed this way, you can see that complex plans that involve months of execution, where planning is done in detail up front, historically haven’t accommodated the “life changes” reality of “s*** happens”. If you cannot adapt a plan to the reality of business, as it happens, then you operate in another world than the one you’re trying to execute in.
Corollaries
1. You don’t have to consider or adopt agile if your world isn’t likely to change much (id est, the ways you plan and execute aren’t going to be changed much by days that pass by). Perhaps the construction industry is like this. Perhaps flower shops, or dental offices. (In our business, maybe accounting software…?)
2. You don’t have to consider or adopt agile if your user customers’ experiences with your product isn’t like to change, and you are quite familiar with those experience modes and patterns, and can predict
3. If your world *does* change… as in plans could be affected by world events, details that are only realized as prototypes become available, then what in your current methodology allows you to adapt to such change? Is it that you can reneg on commitments? Is it that your colleagues and/or customers are just really “reasonable” and tolerant? or do you need something more explicitly aware that such change is not just possible, but likely?
The Take-Away
Inertial guidance systems that controlled expensive long-range missiles gave way to real-time dynamic control systems that could course-correct on the way to a target. Point, shoot, and hope-for-the-best was fine when that’s all that was available. With expensive business weapons like teams of software engineers and architects would your business trust a point, shoot and hope-for-the-best method of execution, if real-time dynamic course-correcting methods are available?
