Lots of people (including me) keep saying you need to understand the fundamentals of Agile before tinkering with it. We keep saying working in iterations, doing stand-ups, doing TDD, sitting altogether in a room is not enough to claim you are “doing Agile”.
This is true for any approach, Agile or not: you have to understand how, when and why it works before starting to customise it.
IMHO this is the main reason why you are supposed to apply an approach sort of “by the book” before starting to change it (through retrospectives, of course! 
). This is also why people talk about Shu Ha Ri as a way to approach Agile.
A common advice is to always change things once you got the core values behind them. Even better once you got the principles who fill the gap between values and practices. The real problem, as usual, is the complexity surrounding these aspects and the far-from-the-books reality of the day to day troubles.
To help organising ideas and possibly cut through this complexity many interesting and useful perspectives have been proposed both on the Agile side of the pond and the other. For example, David J. Anderson’s Recipe for Success:
“Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize”
Nonetheless people keep having problems with the complexity that often prevents us from seeing the bigger picture. We have problems in cutting through this complexity and go back to the building blocks.Most of the people I meet though don’t even consider these building block, their focus is on the process/approach/method/methodology itself.
This is limiting, this is not why we have (and discuss) methodologies in the first place. This is what I was referring to at the end of my “From Technicality to Business Awareness: now what?”.
Everyone agrees that not all the processes should be managed the same way. Processes differs in particular depending on the four Vs:
- volume – high volume ones can exploit economies of scale and be systematized
- variety – high variety ones require enough built-in flexibility to cope with the wide variety of activities expected of them
- variation – high variation ones must be able to change their output levels to cope with highly variable and/or unpredictable levels of demand
- visibility – high visibility ones add value while the customer is present in some way and therefore must able to manage customers’ perceptions of their activities
Generally speaking high volume with low variety, variation and visibility make it simpler to have low cost processes while low volume with high variety, variation and visibility all increase process cost.
Nonetheless all these situations have common building blocks and to make them very clear and easy to understand and remember I’ll borrow some definitions from the business world:
- cash generation
- return on investment (as combination of margin and velocity)
- growth
- consumers
That’s it! Everything else emanates from these core ones. These are what any process/method/methodology/approach/whatever should ultimately enable. If they don’t they are getting in the way of the fundamental building blocks. If they don’t it doesn’t matter whether your are doing all the good Agile stuff or not: you are not doing the right thing.
These building blocks exist, with the appropriate adaptations, at every level of the supply network of any organisation. From the strategic level down to the operational level and that’s why any process MUST address them.
In the next few posts I’m going to write a bit more about these building blocks, why they are relevant and I’d like to introduce the three levels which constitute any business operations: the operation itself, the supply network and the single processes. This way I hope that by the end it will be clear why I’m putting together all these things.
) and greatest Italian eXtreme Programmer – has launched:
