Branding has positives and negatives. For agile enthusiasts, it can be a curse especially if we are acting as the transformation agent while using the term “Agile”. If we want to transform a culture from traditional to agile mindset, the last thing we should focus on is the term “Agile” and should keep it inside our post-it satchel. While learning it the hard way, I have effectively used unbranded agility, I call it the “No-Name Agile”. Oops, just branded a technique which probably most agile transformation leaders use.. the Irony.

To market a term, we just need to enclose it in a quote, throw in a slide during a presentation and we are golden – “WE” are golden but the community may not be, who it was originally intended to. From that moment, a golden journey begins for the entrepreneur among us and the phrase is thrown into every event, technique and books around us, adding more and more quirky terms in the dictionary. Therefore, the last thing we need is the term “No-Name Agile” to convey my message to the community in this article. Reason why on the One Rule (1R) Development Framework also known as Xtreme Decoupled process Engineering (XDE), every role is named as less quirky as possible. 1R/XDE Framework focuses, lives and breaths unbranded agility. Unbranded agility, hence, takes over “No-Name Agile” from this point onward.

One might wonder why would we need unbranded agility? Let’s say, we are consulting a company representative who is leading a team working in the traditional way. We believe they might be intrigued to learn about “Agile”. An inexperienced agile transformer will assume the company representative will say something similar to “That’s an interesting new approach, let’s try that !”. That’s the perfect little world right there, everything is sorted. May be it’s just me but unfortunately I have never seen anyone respond with a similar phrase.

Scenario:

An organisation has already been exposed to frameworks which supports theAgile Manifesto, unfortunately in a horrifying way and they may have lost the faith completely in anything that has “Agile” as a suffix or prefix. Here’s one of the real life situations and the most polite conversation I had with someone from such an organisation:

Me: Probably we need a different approach. I have seen something work pretty good in my last workplace, Agile Development. We basically started faster feedback cycle and were able to set a good pace of delivery. Have you ever tried it?

X: Yeah we tried a “flavour” of it last year, it was pointless. The Project Manager ended up spending double budget than originally suggested.

Me: I think the implementation is to blame. As a new member, I can see some very basic concepts are missing among the team members. We should try it by book first and then try to formulate a flavour which suits us later.

X: No offence but Agile is not an answer to everything. Sometimes it just don’t work at all. Scrum wouldn’t work for us. We certified the PM to play the SM role a while back but the velocity kept going down and he didn’t get much time to play that role anyway. We have tried it all in the past year, all was a disaster.

Me: When did I ever mentioned Scrum? It’s one of the ways to be agile, not the only way.

X: Ye ye, Scrum or Agile or something else all are the same; it’s always “green on the other side of the river”.

A failed attempt to be an agile advocate on the second week of work; to suggest something better using the brand “Agile”. What went wrong? Well, I took the same approach and made the same mistake like others who tried and failed before me on this company.

The mistake was in not explaining the principles behind it, first.

There is a reason we have an Agile Manifesto which documents the principles effectively,. Weeks later, I started experimenting unbranded agility and here is the conversation (not verbatim but close enough):

(Context: The development team have build the product wrong as the shared understanding was missing during the implementation.. no feedback cycle.)

X: We need to find out what is happening in that team. It’s affecting all our SLAs, it’s appalling. Why are the developers suddenly saying the requirements were ambiguous when the PM explained it very clearly last quarter and shared it with them. Seems like no one reads their email any more and nodded when asked.

Me: I think we should have added few “official checkpoints” to understand if we were all in the same page. 3 months is too long and I wouldn’t be surprised if they were nodding just because they had to, knowing their line managers were in the same room.

X: What you mean by checkpoint? You mean like a requirement re-visit session every month?

Me: Well, not a requirement revisit as it seems like the stakeholders were assuming it will never change. I meant like a frequent huddle; more frequent, like everyday.

X: Oh.. you mean like a daily stand up with all those 20 developers together? We did it before as you know and it was the only thing I liked about Scrum.

Me: *coughkillmecoughkillmenowcough* Exactly, all 20 together sounds good (..NOT). At least we will know what they are working on every day and we can clear the confusion regularly.

X: Let’s do that, I will speak to the PM. Let’s see if it works out in the next quarter.

Phew.. right there, a small win in the very beginning of a year long unbranded agile transition plan. At least a stand up was finalised, I ignored the “all 20 together” fallacy to raise hell by itself. Soon the organisation realised that we were wasting time on a hour long stand up and voted for shorter feature focused stand ups. We were so happy to see a “brand new” approach and only 15mins time-boxed “digest”. Following that conversation, I have started gathering the following terms and still use them for key discussions during a transition:

And so on… This list can re-use so many known terms and we need the community to help us collect them all !

Sometimes, the resistance towards a branded term is not always professional, it is personal.

Some management entities may never like the way Agile Manifesto focuses on collaboration and try to (indirectly) advocate empowerment, removing most middle management or convert them. Self-organisation and Self-managing teams sounds extremely fishy and sometimes a load of horse faeces to traditional mindset.

If someone has spent majority of their career to be where they are now and did things they are proud of, they will not screw it up just before their retirement.  Let say, if I was a Project Manager with an MBA, PMP certified (or similar/more) and have 10-20 years plus of experience, do you really think I will sacrifice it all easily? Good luck with that.

Many will agree that a majority of traditional management persona are often very insecure and extremely reluctant to change and transform to agile values. They will resist everything which can burn their position of “Command and Control” down to a Servant Leadership. Down – because they think it is below their current status, to be a servant of a team they micromanage now. Only way you can get through to them is with compassion and assuming that they may never change for that moment of time.

Not everyone among the traditional Project Managers are resistant though. Many of my close friends who used to work as PM have realised it on their own and happily changed their ways of thinking. Unfortunately, their employer will not change the job title so easily, it gets much more complicated. Point is, we shouldn’t force them; rather, communicate with them through the principles.

When the “Role” becomes insignificant without losing any employee benefit and they are being agile while producing desired value, please leave them alone.

You got what you wanted as an Agile Transformer. Our goal is to make it happen and as long as we know we have done it, just get a chilled beer and celebrate. We just have to make sure what we have helped establish is a stable and sustainable culture and doesn’t fall apart.

Unbranded agility, helps us to implement agile mindset without making it a bigger deal.

Agility is common sense which we usually forget to remind while explaining. What we need is a good amount of patience, focus and integrity sometimes without getting any appreciation at all. The professional satisfaction we gain is much more valuable than taking the credit for a change which we can do another 100 times if given an opportunity.

Let’s collect & re-use:

The table above is to give us a simple example which one agilist alone can’t/shouldn’t create. It’s intended for the community and community have to build it together.

Let’s unbrand “Agile” for the sake of making someone agile.

Please send all your suggestions on comments or private messages. They will be collected in one place, shared while crediting the contributor. Hope to hear from you soon.