Transformation is possible if you really want it.

Transformation is possible if you really want it.

I am often asked which projects or organizations should use Agile. Underlying the question is a feeling that there is some formula that indicates specific types of projects or organizations should use Agile and which should not. I feel the answer is very simple. Since Agile is at heart a philosophy, any project or organization that wants to embrace Agile can use Agile. The most important word in that statement is “wants”. We often say we want something, but that statement doesn’t translate to action — for many reasons. For example, I “want” to learn Ruby. I have even gone as far to put a card into the backlog of my personal Kanban board. However, I have not found the time to begin the process. Finding the time would require I change my current behavior (get up earlier) or to abandon another project. Really wanting to become Agile means making changes both to how organizations and teams work and interact. As we all know, organizational change is typically not easy. The recent re-read of Kotter’s Leading Change recounted and discussed a framework for generating major organizational change. The requirements for all changes requires focus, effort and constancy of purpose. A change to embrace Agile requires adopting the philosophy of Agile, abandoning much of the trappings of command and control and thinking more in product terms of than project.

Agile is a Philosophy – the Agile Manifesto is comprised of four values and twelve principles that create a philosophy for structuring and managing work. The focus is on the human side of delivering value. There are innumerable frameworks, methods and techniques for implementing those techniques. For example, while Scrum is the most popular framework being used in Agile projects, it is not the only method. Crystal, DSDM and xP are a few of the other common frameworks. How any of these frameworks is implemented makes them more or less Agile.

Abandoning Command and Control – Effective Agile teams are self-organizing and self-managing. Self-managing teams plan and manage their day-to-day activities with little overt direction and supervision. Command and control management techniques, which hit their heyday in the 1950’s and 60’s and are still common, make the assumption that managers will assign and direct individuals (read that as tell them what to do). Command and control management strips much of the team’s ability to quickly make decisions and to react to change at a tactical level, which slows progress and reduces productivity.

Taking A Product Perspective – Agile embraces short iterative cycles of development that deliver value continuously or in the form of frequent releases. Techniques such as gathering needs into a backlog, involving product owners in planning and prioritizing needs over several sprints and releases are a reflection of product thinking. This type of thinking fosters trust between the business and IT so that the onus is not on the business to think of everything they need at once. Projects, as opposed to products, have a discernible beginning and end and have a known scope or budget, which forces users will to try to maximize the functions they ask for from the project team. The incentive is for the business to ask for everything and to make everything the top priority.

Who Can be Agile? Unfortunately any team or organization can say they are Agile. Any team can begin the day with a stand-up meeting or do a demo or retrospective. However just using a technique or framework does not make anyone Agile. Anyone can be Agile, however only if they want to be Agile enough to make changes in how they think and how they organize their work. Being Agile is only way to get all of the benefits in customer satisfaction, quality and productivity organizations are seeking when they say they “want” to be Agile.