- Why Agile?
by Paul Ellarby - October 5, 2012
“We need to change our culture” – how many times have I heard that when I am working with organizations trying to adopt an agile approach? Well, I hear it almost every time I give one of our workshops, and it has driven me to change the way I start each workshop by trying to discover the culture of this particular organization, and what it might mean to the workshop participants. In this way I am able to tailor each workshop a little to be as effective as possible for the participants, and have the best effect upon their organization
In his book “The Reengineering Alternative: A Plan for Making Your Culture Work”, William Schneider introduces a simple, four-part framework for organizational cultures. While most organizations have multiples types of culture, there tends to be one culture-type – “the way things get done around here” – that influences the vast majority of people working in that organization. Understanding this culture serves as an excellent guidepost to determine if adopting agile will be successful, marginal, or a failure.
These four types of culture are described as follows:
Collaboration – “We succeed by working together”
Typically, the words I often hear to describe this organization are diversity, teams and teamwork, partners, trust, and interaction.
When I work with organizations in this cultural space, I usually discover that they are truly agile already, but that they do not really know it, nor o they have the framework or techniques in place to take full advantage of what they have built. Consequently, I spend my time introducing agile techniques, and helping people to understand how best to adapt these techniques to their situations. I love these organizations!
Cultivation – “We succeed by growing people to fulfill our vision”
Note the words “to fulfill our vision” – these organizations typically are so focused on what they believe their customers want that there is little room for debate. They know the right answer, and this becomes the path they follow no matter what.
At the same time, though, these organizations understand that their employees are key, and can greatly contribute to the success of the company. Consequently, they allow a great deal of flexibility, creativity, and growth among their employees, so long as it is focused on the end goal.
This is an interesting type of organization to introduce agile. The techniques are often accepted very quickly, as it allows the development teams to be creative, and work with the internal business product owners. Where it becomes a challenge is in introducing products (working software) to outside customers, and these customers giving honest feedback early in the development cycle – often in a negative way, perhaps that the product does not do what the customer actually wants. This news is usually greeted by such statements as “They don’t really know what they want”, and “We know the market much better than them”.
Sadly, I find these organizations usually stop getting feedback from their customers, and charge ahead in their traditional “we know everything” model. These organizations can be viewed as a success in adopting agile, but will never understand what it means to deliver value on a regular, consistent basis.
Competence – “We succeed by being the best”
Once these organizations decide to do something, they typically do it better than anybody else. They use words like experts, craftsmanship, professionalism, and efficiency to describe the people who work there. They already know they are the best, and they often believe they need no help in introducing new techniques or approaches, because they already have all the efficient processes and smart people they need.
Introducing agile in this organization is often a failure, as there is there is an inherent lack of interest in a new approach, new techniques. This is very hard work.
Control – “We succeed by getting and keeping control”
These guys plan everything they do, and stick to the plan, no matter what. They want complete predictability over everything they do, and have the rules, processes, and hierarchical organization in place to do it.
You would think this type of organization is impossible to introduce agile methods to, wouldn’t you? Well, while it can be difficult, I find that using a management technique that maintains this control is easily adopted. Consequently, I find Kanban techniques for managing the flow of work very effective, and increasing visibility to management. It also provides a very rich vain of data – flow of work, delay time, work-in-process, etc. – that the Project Office love, and can use to improve their standardized processes.
So, which organization do you work in, and do you understand the likelihood of success if you are introducing agile? And what are you going to do now you have this information?