top of page

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.

  1. Individuals and Interactions are more important than processes and tools. Agree / Disagree

  2. Working Software is more valuable than comprehensive documentation. Agree / Disagree

  3. Collaborating with the Customer is more important than negotiating a contract. Agree / Disagree

  4. Responding to a change is more important than conforming to a plan. Agree / Disagree

  5. Working Software must be delivered quickly and continuously according to the priority of value to the customer. Agree / Disagree

  6. Requirements will change during the development cycle. Changes must be welcomed not resisted. Agree / Disagree

  7. Business users and developers must work together closely throughout the development cycle. Agree / Disagree

  8. If Teams are given the right environment and support they will get the job done. Agree / Disagree

  9. The best method of communication is a face-to-face conversation. Agree / Disagree

  10. There must be continuous attention to technical excellence and good design. Agree / Disagree

  11. Simplicity is a virtue and is essential. Agree / Disagree

  12. Teams must be able to organize themselves, with minimal or no supervision, to gather requirements, create the best architecture and design. Agree / Disagree

  13. At regular intervals, teams must reflect on how to become more effective and adjust behaviours accordingly. Agree / Disagree

  14. 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;

  1. Deep rooted familiarity with other traditional practices / approaches such as Waterfall

  2. Lack of in-depth understanding of the four Agile values and ten principles

  3. Force of the prevailing culture in the team / organization (The way we do things around here)

  4. Influence of transient resources in the team (Contractors / Developers on short-term assignments that go from team to team with no permanence of culture)

  5. Interference in Agile adoption by mid-level Managers who feel they are losing their control, influence or power

Common examples of Anti-Agile Behaviour

  1. 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.)

  2. Insisting that teams create long and wordy “Business requirements document”

  3. Forcing the use of tools for project planning, time/effort capture, etc.

  4. Asking for Project status reports from the team

  5. Nominating a “Project Manager” in the team

  6. Stipulating a set of documents (usually from PMI / PRINCE2 / Etc. methodologies) that an Agile team is forced to create

  7. Demanding that the Sprint team create a “Minutes” of the Daily Stand up meeting

  8. Expecting “complex solutions / outcomes” for “complex requirements” or “complex businesses”

  9. Appointing a “Manager” to supervise the Agile team so that it can be "controlled and managed"

  10. Cancelling Sprint Reviews and Retrospectives or making them optional

How to overcome value diminishing behaviours

  1. Invest good time and effort in educating individuals and teams in the fundamentals of Agile (Refer the Agile Manifesto)

  2. Design and Implement a continuous education program, especially the basics, so that newcomers and transient resources quickly adopt themselves to the “Agile way”

  3. Implement a specialized and continuous education program for mid-level Managers throughout the organization on Agile Values, Principles and Practices

  4. Nominate and promote “Agile champions” inside the organization to promote Agile values and principles

  5. 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.

  6. Actively promote the power of simplicity

  7. 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)

Recommended reading

The Agile Manifesto

Join our mailing list

Never miss an update

Featured Posts
Recent Posts
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square
bottom of page