Skip to main content

Ten Mistakes to Avoid While Adopting Agile

By September 23, 2015June 8th, 2021No Comments

When an organization decides to adopt Agile, the way it is structured often has to change. An Agile way of working also brings along new practices for teams and managers, and usually impacts the organizational culture and mindset. Here are 10 mistakes to avoid while you are adopting Agile in your organization.Mistakes-to-avoid-while-adopting-agile
(1) Ignoring the Manifesto
Understanding the manifesto is more important than solely focusing on the ‘process’ part of Agile.

(2) Assuming Agile is a Silver Bullet

  • Seek clarity on which of your problems Agile may solve.
  • Let the ‘nature of your work’ be the driving factor (e.g. Kanban may suit better than Scrum for support teams).

(3) Using Traditional Managers for Scrum Master or Product Owner Roles

  • Agile roles need the servant-leader mindset, traditional managers may find it hard to transform.
  • An authoritarian person will hinder self-management within the team.

(4) Forgetting These Agile Recommendations While Building Teams

  • Willing to try Agile
  • Mature and honest
  • Cross-functional
  • Co-located
  • Self-organizing

(5) Having an ineffective Product Owner

  • ‘Collaboration with customer’ is a cornerstone of Agile philosophy. The customer has to be willing to invest time and energy to work with the development team.
  • Assign a Product Owner with sufficient bandwidth and authority.
  • Do not change priorities or meddle with scope while a sprint is in progress.

(6) Trying to Scale Agile Before Getting It Right

  • Start small – inspect, adapt and then scale.
  • Start with a white-board instead of buying software tools upfront – give flexibility to the team to figure out what they need.

(7) Making Too Many Compromises
Agile is flexible, but if we compromise the fundamentals, it is obviously not going to work.
(8) Expecting Granular Estimates for the Entire Project in Advance
Estimations in Agile are progressively elaborated – one sprint at a time. If you are looking for a precise year-long plan with granular details, understand that for software projects, (a) it is an unrealistic expectation and (b) such a plan will become useless in responding to change.
(9) Over-doing Change

  • Agile embraces change, but that does not mean one can change requirements and priorities at random.
  • Product Owners should be able to commit to requirements and priorities before a sprint begins and then get out of the team’s way.

(10) Failing to Help Agile Teams
Agile teams like you to:

  1. Think through and define ‘done’ well in advance.
  2. Review ‘working software’ carefully rather than asking for status documentation.
  3. Give candid feedback in sprint retrospections.