Are you an Agile sceptic?
Many people don’t believe in Agile. Some see it is another fad. Some of them are even anti Agile. What's perplexing and even amusing is that some people have strong "opinions" on Agile without knowing much about it. This article explores why that may be so despite the obvious benefits of agility. It offers suggestions for how to believe in the "Agile movement". After all, Agile has been widely embraced by the Software Industry to accelerate product development and value delivery to customers.
A simple checklist that each of us can validate our beliefs and attitudes towards Agile is presented below. Circle your answer to reveal your views towards Agile.
Note: It is better to limit the choices to Agree / Disagree to elicit gut responses. Preferences such as Neither Agree / Nor Disagree or grades of agreement or disagreement tend to complicate the findings.
Individuals and Interactions are more important than processes and tools. Agree / Disagree
Working Software is more valuable than comprehensive documentation. Agree / Disagree
Collaborating with the Customer is more important than negotiating a contract. Agree / Disagree
Responding to a change is more important than conforming to a plan. Agree / Disagree
Working Software must be delivered quickly and continuously according to the priority of value to the customer. Agree / Disagree
Requirements will change during the development cycle. Changes must be welcomed not resisted. Agree / Disagree
Business users and developers must work together closely throughout the development cycle. Agree / Disagree
If Teams are given the right environment and support they will get the job done. Agree / Disagree
The best method of communication is a face-to-face conversation. Agree / Disagree
There must be continuous attention to technical excellence and good design. Agree / Disagree
Simplicity is a virtue and is essential. Agree / Disagree
Teams must be able to organize themselves, with minimal or no supervision, to gather requirements, create the best architecture and design. Agree / Disagree
At regular intervals, teams must reflect on how to become more effective and adjust behaviours accordingly. Agree / Disagree
Teams must work at a constant and sustainable pace. Agree / Disagree
What was your score?
Agree score = 12 to 14 You are a strong believer in Agile.
Agree score = 8 to 11 You believe in Agile.
Agree score = 4 to 7 You are an Agile sceptic.
Agree score = Less than 4 You are strongly anti-Agile (Agile cynic).
Agile beliefs and Views / Opinions / Actions
This simple assessment is designed to reveal the strength of our belief in Agile. Informed readers might recognize that these are the core values and principles of Agile as stated in the Agile Manifesto. Even if our belief in these core values and principles is strong, It is possible that our actions and behaviours may be misaligned with the beliefs. There may be number of reasons for this, such as;
Deep rooted familiarity with other traditional practices / approaches such as Waterfall
Lack of in-depth understanding of the four Agile values and ten principles
Force of the prevailing culture in the team / organization (The way we do things around here)
Influence of transient resources in the team (Contractors / Developers on short-term assignments that go from team to team with no permanence of culture)
Interference in Agile adoption by mid-level Managers who feel they are losing their control, influence or power
Common examples of Anti-Agile Behaviour
Forcing Waterfall processes and practices on Agile teams (Work breakdown structure, Time boxing SDLC functions and calling them Requirements Sprint, Design Sprint, Testing Sprint, etc.)
Insisting that teams create long and wordy “Business requirements document”
Forcing the use of tools for project planning, time/effort capture, etc.
Asking for Project status reports from the team
Nominating a “Project Manager” in the team
Stipulating a set of documents (usually from PMI / PRINCE2 / Etc. methodologies) that an Agile team is forced to create
Demanding that the Sprint team create a “Minutes” of the Daily Stand up meeting
Expecting “complex solutions / outcomes” for “complex requirements” or “complex businesses”
Appointing a “Manager” to supervise the Agile team so that it can be "controlled and managed"
Cancelling Sprint Reviews and Retrospectives or making them optional
How to overcome value diminishing behaviours
Invest good time and effort in educating individuals and teams in the fundamentals of Agile (Refer the Agile Manifesto)
Design and Implement a continuous education program, especially the basics, so that newcomers and transient resources quickly adopt themselves to the “Agile way”
Implement a specialized and continuous education program for mid-level Managers throughout the organization on Agile Values, Principles and Practices
Nominate and promote “Agile champions” inside the organization to promote Agile values and principles
Nominate a minimal set of appropriate, relevant and critically necessary documentation that teams should create. Establish a good standard reference library for such documents – Product Vision Document, User Stories, Test Scripts, etc. All other documentation should be optional.
Actively promote the power of simplicity
Facilitate and actively promote cross-project retrospectives so that project teams can learn from one another and adopt Agile practices across the wider organization (Scaled Agile)
The Agile Manifesto http://agilemanifesto.org/