Agile Methodology was founded in the early 2000, but it picked up pace in the early 2010s.

Since then, more and more organisations try to be agile in their core values and practices (People call it “Living Agile”), but others following them just boast about being agile and call it a day, without solving core issues and following its principles. (Call it “Lipstick Agile”)

In this article, We’ll revolve around Lipstick Agile and answer the following questions:

Why do we call it “Lipstick Agile”?

What are its traits?

When should you be alarmed? and

How can you overcome it?

Let’s get started then!!!

Why?

First, Let’s go through the term “Lipstick Agile”.

I apologise for borrowing the term from Stefan Wolpers, But the term is surprisingly simple and complex at the same time.

A basic explanation of why it’s called “Lipstick Agile” is the simple illustration of the first image in this story where a pig is forced to apply the lipsticks and makeup to make it look good. It’s obvious that even though we apply as many lipsticks, a pig at its core is still a pig and it will do as good as a pig even if we expected it to be better after applying lipstick.

Likewise, If you try to enforce the Agile manifesto under individual’s throats without addressing the organisation’s and individual’s static and rigid mindset, you are falling in the trap of Lipstick Agile.

Though it’s a very simple explanation of the term, the complexity of this term lies in finding out if you are using Lipstick Agile or not?

So I’ll try to address and declutter that complexity in the next segment.

What?

Now, What are the traits of Lipstick Agile? How can you identify if you are falling into Lipstick agile or not?

For that, as an individual/leader, you would need to ask yourself these questions by being true to yourself. Don’t give answers by your theoretical knowledge but by answering it from what you practice.

Ready?

Here they are:

1. Is your team’s or individual’s mindset rigid? Do they or you welcome changes as they come than resist them?

2. Is your appetite for numbers like revenue, contracts and customer retention strong? or can you be flexible for negative numbers?

3. Do you stick to the processes and tools set by your organisation/team? or do you empower or motivate individuals to explore various processes and tools?

4. Is working software important to you over the history of tickets and documentation?

If the answers given by your heart are on a scale of No to neutral, then you are definitely using Lipstick Agile. Even if you said yes to most of it, I would burst that bubble in just a moment. But before that, you might be wondering, these questions seem familiar. And you’re right!!! These are taken straight from the Agile Manifesto.

So even if you said yes to the above questions, let’s break those further down.

1. Do you stick to the agile ceremonies even if they are not fruitful? Do you keep doing the standup meetings even if it’s just status updates? Do you even work on good, bad or improvement points from retrospectives?

2. Do you believe that increasing revenue or new contracts or customer retention ratio are the primary metrics to measure success? Do you put numbers like those, preference over customer satisfaction?

3. Is Burndown chart, Velocity, CFD, Throughput, Time logs, Bug counts, Jira reports and sticking to processes set by the organisation/team more important to you than the business value of features and an individual?

4. Do you prefer everything should be documented, be it in Docs, Jira Ticket or Commits? Do you rigidly maintain the history of work done by individuals than worry about the impact of work done?

Now I assume, your answers might have changed because that’s what most of the “Self Trained Agile Organisations” do.

Now, don’t get me wrong, I do not say that numbers like revenue, contracts, retention ratio etc and metrics like burndown, velocity, reports etc doesn't matter. It most certainly does. But it does only when team & individuals have matuared enough in Agile Transformation.

Following them rigorously and making decisions based on that while your team or individuals still don't have an Agile mindset or are not trained for it, is of no use. In fact, It may adversely affect your team/organisation.

Lipstick Agile works fine for most of the teams & organisations who take pride in being Agile even if it’s false agile. It only starts to get painful when things start to go sideways. That’s when you should be alarmed. We’ll discuss those alarms in the next section.

When?

When you should wake up from false pride in using Agile while you are actually using Lipstick Agile? What are the signs of that wake-up call?

Well, for starters, the first and major indication would be your customers. If they are not happy with what you deliver or they don't find business value of the features you have delivered, then you should be alarmed.

The second would be the satisfaction of individuals. If the individuals feel that the work they are doing is not making any sense, or they feel the meetings or several agile ceremonies are wasting their time without giving any fruitful results, or they feel that the processes and tools they are using are rather an overkill than facilities, then you should be alarmed.

Third would be your feeling about the deliveries and performance of your team. If you think that burndown, throughput, bug count, bug severities etc.(Yes, I admit here, metrics are relevant) and most importantly, the business values of deliveries are going sideways, or the teams or individuals are not in sync with themselves or with stakeholders and they are still working in silos, then you should be alarmed.

Now that we know what are the indications of a wake-up call, how can one overcome that? That’s what we’ll discuss in the next section.

How?

Now, Let’s circle back to the first question I asked in the breakdown questions in the “What?” section. Because the best solution to overcome the trap of Lipstick Agile lies there.

The question I asked was: Do you even work on good, bad or improvement points from retrospectives?

The retrospective is a very important ceremony which allows the team to focus on what went well, what didn’t go well and what we need to improve.

Most of the organisations/teams that are using Lipstick Agile either get away from this important ceremony totally or perform it just for the sake of … well, performing it.

The prime reason the retrospective is being done for name’s sake is that individuals and stakeholders lose their interest in performing it over time, as the points like what went well, what didn’t go well and what needs to be improved etc. stay in retrospect board only. It doesn’t translate into action items for future sprints.

To overcome the trap of Lipstick Agile, one should empower and trust their teams, individuals, stakeholders and end-users to provide actual feedback rather than imposing fear or letting them have disinterest in that ceremony by not making it fruitful.

Another way to overcome it is to envision and tackle real-world business values. Measure the work done by the team on a business value scale. Empower the individuals to raise red flags when they feel the work they are doing isn’t adding any value.

Ask individuals to remember to raise red flags by asking them to remember:
“If it doesn’t make any sense to you, it shouldn’t be there”

Once you fix those 2, the third alarm goes off automatically.

Hope you found it useful and practical.

Happy Learning!!!