If you work in project management at any level, then you will almost certainly have come across the term “agile”. Many project managers like to think they are doing agile projects but this is not always the case. In fact, whilst most managers would suggest that the adoption of an agile approach is a priority, only a small percentage of them believe that their organisation is, in fact, performing with a high level of agility.
As much as project managers want to believe that they are using an agile approach, there is, in fact, a good deal of confusion between the reality of the implementation of agile projects and the aspirations that companies have in that direction.
What is Agile?
Essentially, agile is a somewhat iterative approach to project management. It can be used to help teams when it comes to delivering value to their customers in a manner that is not only faster but also with less stress. Instead of putting all of their team efforts into a “one shot” completion for the project, a team who is using an agile approach breaks their work down into smaller, more manageable tasks.
They work on each of these small tasks as “mini projects” and complete these before moving on to the next one. These smaller increments make the project less overwhelming and make it easier to see the progress that is taking place. The requirements of the project, together with the plans and any results, are continually evaluated. That way, the project team have a more natural mechanism that they can use for responding to any changes in a timelier manner.
Agile is also sometimes used as something of an umbrella term that is applied to a number of development frameworks. However, agile does not simply refer to Scrum or Kanban. Much of the confusion that has arisen around agile has come about as a result of teams associating the agile approach with the idea of using an “Agile Framework”.
An Agile Framework is one that is very attractive because it is offered up as a simplified solution that is used for common issues in project management and in projects that are more complex. These frameworks undoubtedly make up a significant part of agile implementation. However, they also require a strong foundation to build on.
If a team is looking for agile success, then they need to be able to adopt a more agile philosophy. Often, this means changing the way in which they think about things like work ownership, management and also the duty and relationship with regard to customers or stakeholders. Without this thought process, frameworks like Kanban and Scrum can fail.
What is fake agile?
You may already be aware of fake agile but have heard of it under another name. It is sometimes referred to as:
· Agile in Name Only (AINO)
· Zombie Scrum
· Agile BS
What these have in common is that they are lacking in that essential spark that is necessary if you want to facilitate the possibility of true agile success. When it comes to measuring agility, there really is no true standard form of assessment. Agile was originally intended to be more of a philosophy than a framework, but it may have strayed a little from its original path. This is implied by the statement “be agile” rather than “do agile.”
What’s the difference?
The big difference in this context is that “being” agile suggests that whatever framework is used, it really shouldn’t matter. There are still some core values that should be upheld. Almost all frameworks that can be classified as “true” agile will, in fact, share the same core values.
If a project team are creating a significant number of working project deliverables with the sole intention of facilitating feedback from customers, then it stands to reason that this will involve a significant amount of waste – in other words, plenty of work that really does not hit the mark.
This can sometimes occur as a result of management forcing their agile agenda onto the team in a rather heavy-handed and undemocratic manner. Or it may happen because a project lead, who is well-meaning, might be looking to improve the productivity within the team as a result of using a new approach. The main reason for fake agile projects is that a system is really not performing in the manner that it should be.
In other words, fake agile is fake simply because it is not properly upholding the agile principles. Fake agile could be considered to be a rebranding of a more traditional methodology but with new jargon.
Why does fake agile happen?
There are three simple reasons that fake agile might occur:
Doing agile is easier than being agile
It is a relatively quick process to adopt an agile framework and then follow it but adopting a philosophy or mindset that is agile needs the culture in an organisation to change and this can take more time and more determination.
Teams often mistake agile tactics for agile outcomes without refreshers
There is a good chance that a successful agile team can fall into a rut with their agile routine. When a team has plenty of experience and is comfortable doing agile, they can actually forget to be agile.
Organisations block agile via technical architecture and inflexible governance
Agile delivery teams and all of the products that they support need to have a degree of continuous improvement with regard to governance and technical architecture.
Why is fake agile bad for your project team?
When it is executed well, agile can be a very good concept. However, there are, unfortunately, many ways in which it can go badly.
A team who believes that they are following an agile approach will often believe a number of things, such as:
1. They are being far more productive
2. Individuals take precedence over processes
3. A product that works is much more important than any documentation
4. The ability to be resourceful and adaptive is a more valuable skill than the ability to be able to stick to a plan
Whilst these statements certainly contain some truth, there are many implementations of agile that can twist them and make them something that is far less clear.
Fake agile could be looked at as “building the wrong thing, righter”. A prime example of this is when you add too many features to a product because it makes it look impressive, and seems to add more customer value. Yet if the function created by these additional features could have been achieved with fewer features, then what is the benefit?
Ignoring users
Under an agile approach, communicating with everyone involved in the project is vital for the success of the project. However, when fake agile comes into play, communication becomes of less interest. In addition, what little feedback there is isn’t always consistent, which can seriously hamper the way in which the project progresses.
Time management
A truly agile approach looks to prioritise the work and knows that rapid iteration is important. Under a fake agile approach deliverables are often not ready and milestones are constantly moved.
Responsibility
With fake agile, the project manager often defers their responsibility and acts as though it is someone else’s job. True agile sees the project manager taking this responsibility more seriously and ensuring their involvement is clear.
Streamlined processes
Process in a true agile approach is automated where possible so that the greater focus is placed in providing value for the customer. With fake agile, processes within the project are more likely to be manual, even where there is the option for them to be automated.
Importance of functionality
True agile will focus on the development of a working product with feedback from key individuals, whereas fake agile will be more focused on the paperwork for requirements and compliance and a working product is simply a bonus.
When this fake agile route is taken rather than the true agile one, many of the important skills of project management are lost. There is less communication, and priorities shift. This can result in a team that feels less valued, and team members are not as connected with the work that they are doing. There is a danger of dissatisfaction that could lead to people actively seeking alternative employment elsewhere. This, in turn, can be bad for an organisation. High employee turnover is never good to see and can be a clear indication to stakeholders that there are problems on a project.
How to avoid fake agile
The goal of “true” agile is to work towards the timely development of the product required by the project with the best interest of the client in mind. If you want to avoid fake agile, it is a good idea to consider the four core values that are associated with agile:
- Interactions and individuals over tools and processes
- Working products over comprehensive documentation
- Collaboration with customers over the negotiation of contracts
- Responding to any change over following a set-out plan
It can also be a good idea to go back to basics and ensure that you and your team are fully conversant with the 12 principles of agile that can really help you to remain on track.
How to spot a fake agile team
It isn’t enough to simply consider the differences between fake and true agile, it is also important to look at the way in which a team works. Asking some key questions will really help to gather insight into how they work.
Agile relies on the feedback that is gathered from customers if it is going to work as it should. A team with relatively little experience may accept just a small amount of feedback, but with agile, feedback needs to be continuous, and it should always be built into every step of the release cycle. If a team looks at feedback as an exception, then they really are not being agile.
Feedback is only the first step, as it should be a part of a continuing cycle so it is important that there is room in a team’s budget to cover this. If a team have not reserved some of their budget for unknown costs, then they may feel inclined to abandon feedback later on in the project due to a lack of funds. A team that is following true agile will have allowed for the implications that can arise from customer feedback because they understand just how much value this can actually carry for their project.
Why training matters
Whether agile training has taken place a long time ago or more recently, the importance of such training should never be underestimated. Good agile training is essential in ensuring that team members truly understand the agile approach. The difference in how to “do” agile and “be” agile are concepts that need to be understood. Many of the fake agile issues that can be seen in project management stem from members of a project team forgetting what they have previously learnt about agile concepts, and retraining can do much to change this, ensuring that everyone returns to following true agile approach.
