How to detect false Agile?

Agile is very commonly adopted – at least when you ask people whether they are working in an agile way. Once you get a chance to take a bit closer look at it, often there is quite some room for improvement left in terms of the true Agile way of working.

So, how can you tell whether an organization has adopted Agile effectively yet, or not? Well, you may want to start by asking some questions. How about some of these listed below?
This is by no means meant to be a complete list. I am happy to receive comments or emails suggesting further meaningful and powerful questions that help understand the state of Agile adoption of an organization.

Simple questions to ask:

  • How do you gather feedback about your product(s)?
  • How much has the team budgeted on that development effort to accommodate customer feedback?

Once you have asked these or similar basic questions you may think about asking more detailed questions such as some of the following to get a more complete picture of the situation:

  • Are developers understanding the importance of involving users with the development and actively seeking feedback?
  • Are teams delivering working software to real users every iteration (including the first) and gathering their feedback?
  • Is the feedback from users turned into concrete work items for print teams on short timelines, e.g., 2 or 3 iterations?
  • Is the full ecosystem beyond development agile? Agile development teams eclipsed by linear, bureaucratic deployment is a failure.
  • Are teams empowered to change the requirements based on user feedback?
  • Are teams empowered to change their process based on what they learn?
  • Is there more attention on requirements or compliance than to deploy something useful quickly? Are ‘working builds rarely ready to show at the end of a sprint or get pushed out to the ‘hardening sprint’ or ‘next sprint’?
  • Is there Agile ‘terminology hacking’ by giving plan-driven practices Agile terminology facades, such as ‘QA sprint’ or ‘Hardening Sprint’?
  • Is there more focus on output than the outcome? E.g. the number of features delivered may seem impressive – but how valuable are they in the view of customers?
  • Are the development processes still mostly manual? Is there still a lot of scope for automation left?
  • Despite having nominally assigned agile roles of product owner and scrum master, are these individuals in practice still performing the exact same functions as a project manager in any traditional development framework?
  • Is the plan-driven project simple been broken down into sprints – without allowing for adaptation of the backlog sprint by sprint?
  • Is the product owner merely a ‘proxy’ product owner without real decision power about the product, accountability for its success nor control over the product’s budget, vision, or strategy?

While answers to these questions may not provide the full picture yet about whether or not the organization is effectively applying Agile methods, many of these answers will provide an indication for areas that are worth diving deeper into when seeking to improve business outcomes by continuously improving the way of working.

If you want to know more about this or have suggestions for more great questions, please leave a comment or contact us via LinkedIn or E-Mail . We are working on a set of diagnostics tools to help dive even deeper into the state of agile within an organization.