There are two generally held perceptions about agile. One, that agile is a kind of anarchist model with no processes, and second, that agile means no governance. Let’s look at the first perception that agile means no processes. We can understand how agile looks at need of processes by applying a well known principle called Occam’s razor which states that ” one should not increase, beyond what is necessary, the number of entities required to explain anything”. The principle helps us to remove those concepts, variables or constructs that are not needed to explain a phenomenon. By doing this, it becomes easier to create a model which resembles reality much better and redundancy and inconsistency is removed. In essence, Occam’s razor stipulates that when multiple theories are available to explain a problem, the simplest one is preferred. Nature likes simplicity. Ocaam’s razor when applied to project management methods would imply that a Project should have only those processes which are required and not more. This is exactly what agile paradigm means with its use of low ceremony, just enough processes. Agile teams chose processes which are most relevant for them to meet their goals in their context. It means you do not pick set of pre-defined, rigid processes in a bunch and deploy them on a project. A process is good as long as it adds value to project; or it should be discarded or amended. So, why is to so hard to agree with this!
It is possibly due to the fact that traditional management methods have relied heavily on process standardization and execution efficiency. But it has not helped achieve predictability of results which is clear from number of IT project failures. Today’s business scenario is vastly different with constant change and dynamic markets. Project teams like Organizations need to adapt quickly. Traditional methods, which are based on “execution as efficiency”, find this hard to achieve because they inherently oppose changes in system. In a Harvard business review paper published in 2008, Professor Amy Edmondson identifies a different approach to execution, called “execution as learning” which looks uncannily similar to agile thinking of software development. She calls execution as learning “a radically different organizational mind-set, one that focuses not so much on making sure a process is carried out as on helping it evolve”. Agile practitioners would easily relate to her thoughts and “execution as learning” looks very similar to agile manifesto.
Second perception about agile is that there is no or very little Governance in agile methods. But the fact is that agile makes governance more effective as it puts onus on participation of all stakeholders in project. Traditional command and control governance models usually end up creating bureaucratic hurdles and illusion of control. Agile governance model on the other hand is about enabling the team and facilitating an environment where team can meet its objective without avoidable hindrances. Whole team principle is about shared vision and goals and that there are no finger pointing and putting the blame when and if things go wrong. Should project sponsor remain a distant illusive figure or rather become part of the team! Perception of agile being low on governance perhaps comes from principle of “self-organizing teams”. Scott Ambler explains this principle when he says that “self organizing doesn’t mean that you are out of control and doing your own thing. It means that team members are themselves deciding how to meet the goals. But the goals they have to meet, the resources used and timeframe, are governed by organization“. Agile governance he says is about keeping the baby and throwing the bathwater. And that might well summarize processes and governance perspective in agile.