I've been focused recently on promoting the structure that exists in agile methodologies and the rationale behind it. In a great new article Ricardo Mestre eloquently assures us that agile is not random, or ad-hoc as many are lead to believe. 

I just want to expand a little on what Ricardo said and then I'll get back to the point. I support what Ricardo says that waterfall's fault lies in its attempt to predict what will happen in the project - and I would add that it does remain the project manager's job to predict what may happen (rather than will) in an agile situation - take risks and the plans necessary to mitigate them for example.

What happens in waterfall when the prediction it makes turns out to be wrong? Due to waterfall being so completely focused on financial control to the detriment of quality and delivery, when it goes wrong the project team becomes gripped with a deep negativity that the (whole) project cannot be delivered as planned because its spending contingency to quickly or run out completely. Waterfall is quite accustomed to offering the resolution that is to attempt to deliver the same value for less money and in less time than is physically possible - which usually "succeeds" politically but not technically or commercially because quality suffers. Even if a change request is the answer it takes too long for the financial controls to raise the new budget before anyone can start working to resolve the issue - and by then there are a dozen other issues since come to light.

So these are the reasons why agile introduces cycles or iterations. Ricardo talks about 3 cycles and I do too but I insert one other between his first and second (so maybe there are 4?) - one that has a variable length of 1-3 days and is therefore relatively fluid. This is a cycle that relies on card conversation confirmation (CCC) and test driven development (TDD) for its structure. These two work very well together; CCC takes input from the user/customer in the form of user stories (requirements) which are discussed across the team and satisfaction criteria agreed upon and supplied to the developers who build unit testing and the relevant code to deliver upon these criteria. All of which comes full circle with customer review (mmm some debate about how often to solicit a review - too often can cause too many stories to drop off the sprint - too few can result in too many changes at the end of the sprint). I swing towards having as many as necessary - which might sound like I sit on the fence. If the customer wants to see progress and there is something to show, then show it, and if the developer or manager needs some feedback, ask for it - don't be shy.

As always I'm keen to illustrate this so the diagram below attempts to do so. I like to use the word concentric as it assists the concept that all the process in agile "have a common centre" - that being quality and delivery.

Let's not forget that even in agile projects there must be some degree of financial control and that's what I'll get onto in my next article about boundaries in agile (which is what I was working on before Ricardo inadvertently inspired this).