Your Agile Might be Fake

Oppong Paul
4 min readDec 2, 2020


“Agile” is a term commonly used in organisations of all shapes and sizes these days.

When I go into organisations, I hear leaders saying, “We use agile”, yet digging deeper, I find things aren’t quite, well, agile, in fact sometimes not at all. A fake idea of agile implementation is commonplace, and managers say the agile words without really understanding the principles and concepts behind them. This means that the team is not truly agile at all, and not reaping the rewards of being agile either. But what does fake agile look like, and how can this be diagnosed in an organisation?

Symptoms and Signs of “Fake Agile”

There are numerous signs and symptoms that an organisation is not being genuinely agile. One of the most common is perhaps the idea that a team can take the elements of agile that they like and use only these, discarding the rest. People who have implemented this approach will make comments saying that they use agile techniques while then going on to say, “Well, it’s not quite agile, we used what we liked from a few different models.”

Another common challenge is not really understanding the core concepts of agile, while still believing the team is working within them. For example, agile is fast, meetings should be fairly quick, while covering the activities of yesterday and today, and discussing barriers. The idea of a daily Stand-up meeting for instance in a Scrum or Kanban agile implementation is to keep it concise and to the point. Some teams find they are having stand-ups that last multiple hours. This indicates the agile implementation might be what it is meant to be and not really working. It might mean that the meeting probably has too many attendees, and in which case it might be possible to work in smaller groups instead. Alternatively it can mean the team is working in a hierarchical manner, which is not the point of agile.

When a team is truly agile it will continuously deliver value to customers. This is a critical underpinning principle of agile. The reason for introducing this concept to agile, was that in the past, developers would work on a project for months, deliver it to the end customer, and by the time it was delivered, requirements would have moved on, or it would not do quite what the customer needed. This means that there is a need to understand customer needs throughout the development process. This is an idea that agile is built around, and hence the principle of continuously delivering value. This leads to the ability to pinpoint other clear indicators of fake agile. It follows that if teams are not securing feedback from customers regularly, and looking at it quickly, then they are not continuously delivering value to them. Feedback is a regular and integral part of agile. What is more, if no time or money is budgeted for change to the project then the team is probably not agile. This is because continuously providing value will invariably require looking at ways to change the development, so it more closely aligns with customer needs, once feedback is received.

Three Key Questions to Diagnose “Fake Agile”

There are some questions that can be posed to those leading so-called agile programs to determine if they really are embracing agile concepts. You might ask, “Do real users see iterative working version of the product, and if so, how often?” If the answer is no, agile is not in place. It is also a problem if customers only see iterations every few months. This is not agile project management either. The end users should be seeing and feeding back on iterations with regularity.

Another question that you could ask is, “How frequently is feedback from users converted into work activities for teams?” If the answer is never, the team is clearly not agile. If the leader responds that this happens within time frames of less than one month, then it is possible that agile is operating as it should. After all, as we have seen above, agile operating is all about meeting customer requirements by taking on board feedback and incorporating it into the project.

A third key question to ask is about team empowerment. You may ask, “What level of empowerment do team members have? Can they change processes and requirements based on user feedback and on what they learn?” Empowerment of team members is a core principle of agile operating. Leaders that say any answer that includes, “Yes they are empowered but…” are probably not following agile methodology. Any indication of hierarchical, top-down decision making goes against the agile way of working.


Many business leaders think they are being agile. They also like to say it, because agile is a popular buzz word. That does not mean they actually are agile. Any so-called “agile” approach that just takes the parts of agile the leader likes and ignores the rest is not truly agile. Underlying agile is fast, iterative development, with feedback taken on board along the way, to continuously deliver value to customers. Where an “agile” solution does not do this — beware! It is almost certainly going to be fake agile.

Yet another enquiry to make is whether the whole project operation is agile. This will help pick out those leaders that think they have got the best of both worlds by using some agile principles combined with other more traditional forms of project management because these are more palatable with their idea of control and command. If the answer is no, then the team is not working in an agile manner. In fact, if the answer is “Partly”, this is also still true. When agile teams work in an agile way to start with, and then use bureaucracy later on in the process, this is not agile operating. The only correct answer to this type of question is, “Yes” without any caveats being applied.

Originally published at



Oppong Paul

Author, Management Consultant,15+ years of consulting experience. Empowering clients to achieve their goals through evidence-based solutions that add value