Three Agile Laws For Eternity

#1 Agile is a Culture

Agile is a culture and you are not able to create it. It happens [1] .

There are plenty of definitions what culture is, so let’s concentrate on that one, related to us, humans.

Agile culture is defined by all of the following elements of life collectively (based on [2]):

Language – Agile has its own language and you have to learn it. Try to avoid developing your own terminology, it’s already done. Be aware that even simple words like “value”, “waste” could have slightly different meaning in the agile world comparing to the well-known, common sense world.

Thought – Agile has its own way in which we perceive, interpret and understand the world around us. It is based on the two lean pillars: continuous improvement (kaizen) and respect for people. Tools that help us to be agile are Systems Thinking, Lean Thinking and Queueing Theory.

Spirituality – Agile has its own value system and gurus that transmitted it through generations, generations of project managers and their projects. You cannot achieve the aim of being agile during or after a single project. You cannot suddenly decide to be agile without believing in it. Agile needs time to evolve, to get mature. Agile needs to be part of your spirituality.

Interaction – Agile is strongly based on the social aspects of human contact. Without getting feedback you are not able to do kaizen, to do continuous improvement. Each agile method defines, to some extent, communication protocols and conventions. It is important to use those tools to be agile not only to do agile (see “cargo-cult” for further explanation).

Social activity – Agile has its own community, demonstrated in a variety of forums, blog entries, conferences and workshops. You have to be a part of these social activities in order to understand the complicated agile evolution process.

As Agile is a culture, be aware of the common misconceptions that are trying to communicate something else. The almost “endless” list of those misconceptions has been collected here “#2 Be Aware of Agile Misconceptions”.

Consequently, as agile is a culture, trying to be agile means always a culture shock for the environment involved. Further discussion about this topic can be found here “#3 Agile Causes a Culture Shock”.

[1] Fried J., Hansson D., 2010, “Rework”, “You don’t create a culture” p. 249
[2] Roshan Cultural Heritage Institute, 2001, Definition of Culture

#2 Be Aware of Agile Misconceptions

The first agile law defines what agile is (see “#1 Agile is a Culture”). This law defines what agile is not, means, it collects common misconceptions regarding to the agile management and agile software development:

Agile is NOT:

• Framework

• Tool

• Solution for a project at risk

• Only for geeks

• Only for high innovative and variable development

• Only for experimental development

Agile does NOT mean [1]:

• Democracy

• Anarchy or revolution

• No contracts

• No discipline

• No requirements analysis

• No goals, estimates or effort

• No modeling, design or architecture

• No documentation

• No release plan

• Iterative, incremental or timeboxed

• Delivering faster

• Fewer defects

• Higher quality

• Higher productivity

Agile means the ability to make impediments in a process visible, thus being able to react to by improving, changing the process.

[1] Larman C.; Vodde B., 2008, “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum”, Chapter 5 “False Dichotomies”

#3 Agile Causes a Culture Shock

Agile is a culture (see #1 Agile is a Culture). Period. A natural consequence for people used to use the classic project management (aka waterfall) in their projects, when they try to be agile, is the culture shock.

As stated in Wikipedia, the culture shock is a difficulty people have adjusting to a new culture that differs markedly from their own. Even the Wikipedia’s definition corresponds to the challenges people arriving to a new country are confronted with, we can easily recognize similarities to the challenges of a project team and its members that are changing the classic way of managing projects into agile software development.

At the beginning, in the so called honeymoon phase, the differences between both ways of developing software are seen as a positive change. Especially because of quick fixed provided by most agile frameworks (e.g. clearly defined goals, acceptance for change, daily meeting etc.), the team and environment are enthusiastic about this new way of building software. This period is full of observations and discoveries, but usually ends quickly because of difficulties originated in lacking of agile spirituality (see #1 Agile is a Culture for the complement).

The end of the honeymoon phase comes with the beginning of a new one: negotiation phase. Due to the differences between old and new culture some team members are getting frustrated and angry or even depressive. It is the core task of management to get closed this phase as short as possible by concentrating on communication, knowledge-sharing and problem-solving solutions. Disappointment is a one of the main enemies of any innovation.

After some time you should expect the next phase named adjustment phase. Agile spirituality is getting developed. Many things become more normal, positive results are often; the attitude is changing to optimistic. The culture begins to make sense.

Depending on the assertiveness of the agile precursors, the adjustments phase should transfer into mastery phase. In this phase the project team is able to fully participate in the agile culture. Agile way of thinking, processes and tools have evolved and got mature. The culture shock has gone.

It is not uncommon that the negotiation phase ends with the project disaster. Disappointed and frustrated members of the project team are not able to deliver results fast and in quality.

It is extraordinary important to be prepared and act pro-actively against the result of the agile culture shock.



Popular Posts