Are you “Doing agile” or “Being agile”?
Did you give a weird look to the above question? If yes, you are not alone my friend. My first expression to this question was similar.
I am currently working on a side project (will share more about it in future) which is based on some of the principles of agile. The above question popped up in one of the conversations I was having with my friend and then we went into the rabbit hole to find some answers. I suppose as you are already reading this article, you are aware of agile. Let’s jog up your memory and define it again. As per Atlassian.com (you know the JIRA guys), agile is:
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
That was a big one and I have highlighted some words which represent it in a nutshell. If you are looking to dive deep to understand what exactly we are talking about here, I have added some links at the end of the article.
Coming back to the big question in the title i.e. Doing agile v/s Being agile. Doing agile means that we are following all the rituals and are doing all things like JIRA Boards, retrospective meetings and etc. It means you are doing it for the sake of doing it so you can go ahead and happily say that you are following agile. Being agile on the other hand means you have the right mindset to change or move quickly while responding to the events such as feedback and customer needs. This includes all the process you follow or the products you build. Look at the above definition, if the process is not creating any value for your customer and your products always need Big Bang releases rather than small but iterative release, then you don’t have an agile mindset. Following the process alone and then lagging in other things does not mean you are being agile. It only means you are doing agile for the sake of doing it.
Being agile is not limited to the following all the process which some of the agile methodologies provides. It is a wider concept and everyone in your organisation needs to have this mindset. Smaller releases, the quest to understand the need of the customer, the development of the product, all should be designed in a way to achieve the ultimate goal of delivering the value to the customer faster and with fewer headaches i.e. iteratively. If it is not in the hand of the customers then it is not adding any value. It becomes a depreciating asset for the business. Here is another quote from Jim Benson(The author of the book Personal Kanban).
We cannot make informed decisions or create a quality product without first understanding why we are doing what we are doing. -Jim Benson
Applications in today’s world have increased complexity, volatility, turbulence and ambiguity. The agile methodology gives us better ways to develop complex products and embrace continuous change. All agile practices encourage splitting work into smaller manageable pieces and priorities to deliver the most value. One of the examples my friend gives is — “Every time there is requirement recorded, the tech team gets a nightmare of how to add this in our current product and the easiest solution is to make a tweak here and there, repurpose the old stuff without analysing whether it will be a good fit or not and adding some flags to process the stuff.” These are the clear signs that you are in doing agile mode and not in being agile mode.
The other scenario which is very common is, we developers start looking into the latest tech trends and start imagining the scenarios which we don’t know exists. We get excited and lays out the full tech plan. To understand it better, let’s say we have a need to create a calendar. The tech team will meet and start drawing up conclusions based on this statement. Where does this lead to in tech world, a calendar needs to have slots, a way drag and drop things and reschedule stuff from it? The estimate came out to be 6 months. Everyone is good with this. We have a flashy tech so developers are happy. Business people can go ahead and tell other stakeholders that we got a new complicated feature into our product. In all these run towards the flashy stuff, the actual value delivered to the customer is delayed. The Being agile way would be to first understand what is the customer trying to achieve? What do they mean when they say I need a calendar? We assumed that they want all the features of calendar. Talk to customers and build the minimum version of what they are asking for. If all they need is a presentation of what they have in that day, you will save yourself a lot of time and money by not building the flashy stuff. It will keep your customer engaged and eventually you will be able to solve the problem as you go. Once the customer is fully satisfied and their need is fulfilled, you can move on to solving another problems. This increases the return on investment as you are building only for the problem which customer is facing today.
One of the core values of agile is to focus on people interaction and having a conversation with them. This emphasis on individuals and interactions with them allows clear and effective communication making agile a people-centric framework. This is to make sure we get a better understanding of what the customer is asking for before we jumping to any conclusions. The identified solution to the problem will be divided in a better way removing the load on business and tech team. With the iterative plan, we can respond better than being reactive to an event like a feedback. Smaller releases and iterative approach saves you from a Big Bang releases and chances of blowing up things in the process. You will avoid choosing a technology for the sake of trying it out or it looks cool. Doing agile gives you exhausted engineers, frustrated product managers who have nightmare because of things which are not aligned to customer’s need. Being agile gives you peace of mind (happy customer), a happy life (something to look forward to improve the product) and a stable process (to add more value to the product).
Going forward, I will look more towards adopting a mindset for Being agile rather than Doing agile. I would love to hear in which bucket you land and if you are already in Being agile space, do share some tips.
