Fragile Agile in the Indian IT industry
For some time now, almost every other IT company is buzzing the term – Agile! Buzzing – because I do not think that the Indian IT industry is ready to adopt Agile methodologies. My fear is that it may never gear up for this change.
Well, not many IT industry folks in India are going to like this observation. Many may also rubbish it as absurd opinion about a divine hymn that the whole industry is singing in unison. Well, that is a common reaction to any diverse opinion, and the very first reason why we are not ready for this change. As an industry, we like to listen and repeat. We like to idolize. We like claim. But we never adopt anything which disturbs our servitude. We are essentially servile.
Before anyone gets worked up about these observations I want to state upfront that these are not blanket statements applicable to everyone in the IT industry. But I do believe that it concerns almost 80-90% of the organisations. If you are from the industry, please do not ask for data. Simply place you hand on your heart and ask yourself what the truth is. If your heart disagrees, do not read further.
To delve deeper into what Agile is all about and why it is not going to work in India, let us try to understand and interpret the manifesto for Agile Software Development which states that –
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Let us explore what these four values mean to us.
Individuals and interactions over processes and tools
This seems to be partially true for us. We do prefer people over processes but that is because we disdain processes. We consider them as scriptures or roadblocks. One half of the society is singing paeans about the scriptures while the other half is busy monetizing them as roadblocks. Our preference for people is also quite funny. It is more about personal trust than about professional trust. Professionally, we seem to trust documents of people more than people themselves.
We seem to prefer tools over logical interactions though we have a lot of time and energy at our disposal for Illogical interactions. Some of these are facilitated by processes and some by the deep desire to disown responsibilities, which includes decision making.
Working software over comprehensive documentation
Working software? Well, what is that?
It may not be exaggeration to say that we are mostly busy making alpha versions. To own up working software one needs to know how-it-works. And that is what we are least interested in. We usually try to understand software through our so-called geeky lens but never through the real world eyes that interact with a system while dealing with real world issues. Our real world understandings, at best, are nothing more than nuggets.
Our lack of interest in documentation is not due to priorities but because we are historically bad in documentation. Most tech people seem to dislike documentation. We also do a lot of copy paste job which makes documentation an uphill task.
Customer collaboration over contract negotiation
Collaboration is a bad word of us. Historically, we could never collaborate. No wonder it just took a bunch of British to overtake the entire length and breadth of our nation.
It would not be way off the mark to state that we look at customer with suspicion and due to that suspicion we spend hell lot of time in contract negotiation. The same is true when we are on the other side of the table as well.
Responding to change over following a plan
We love causing fire and then spending all our energy trying to douse it. So yes, we are very responsive. But it is largely about the mess we helped create. The ‘change’ for us is not a logical entity hence cannot be discussed. Change is a promise that a salesperson or account manager or project manager or someone at the top has made to the customer as an instrument of pacification. This could be due to some error caused by us or due to the idiosyncrasy of the customer. The cause does not matter because we hate calling a spade a spade. It all about, “It will be done. Are we good now!” Who cares for logic? And who cares for a plan?
The agile manifesto says – “while there is value in the items on the right, we value the items on the left more.” The manifesto of Indian software industry is slightly different. We seem to value confusion and chaos. And the way we think and function, there is indeed lot of value in this confusion and chaos. It gives us a feeling that we are busy and being busy is labeled as the biggest virtue of the modern world. I also think that we love rising from the dust because they make great stories!
Now let us discuss the twelve principles behind the agile manifesto and see how they fit into our fragile software development ecosystem.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
It all depends on what one understands from the term ‘satisfy’. If John asks us to build a nuclear shelter with cowdung, we do that to ‘satisfy’ John. It really does not matter whether it will work or not. And then we wonder why John is unhappy.
We are bad at early and continuous delivery because we do not believe in design thinking. In order to release a workable product, in bits and pieces, one needs to fundamentally understand what the product is going to achieve and how. In spite of being a part, it has to work as a whole. We do not seem to agree with that concept at all.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
As stated earlier, the change requirements are commitments made at the ‘top’, many a times without even understanding what that change entails. In the absence of design thinking and well-thought out product plan, changes are largely knee jerk reactions. Even when we are doing something as logical and straight forward as upgrading an enterprise application or technology framework, we end up responding to similar ‘change’ requirements. Many a times the senior front-ending people work merely as courier boys, due to which we ‘change’ the logical to illogical and then revert.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This is like asking a ‘nagin’ dancer to perform ballet. Nagin dance is a popular dance move witnessed in north Indian marriage processions. They are random steps which seem to belong to a dance form but are actually memorized movements enacted under the influence of alcohol.
It is impossible to deliver ‘working’ software in bits and pieces without understanding what the software is all about. If most of the team works a mason, not knowing whether we are building a temple or a dungeon, how can we even dream of making working software? To deliver software in this mode we need a completely different outlook and I do not think the Indian IT industry is even ready for it. I fear that, due to our social systems, we may never gear up to this challenge.
4. Business people and developers must work together daily throughout the project.
You must be joking! They hate each other. Business people are the zamindars (landlords) and the developers are the labourers. They simply cannot work together. Our mindset, our society, our organisations… nothing is designed to function that way. We are fundamentally a different species, which loves hierarchies. Power is our poison.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This is a good line for a poster printed as part of an environment design exercise. Almost every reader thinks that this line is for their boss. The boss thinks that it is for the board.
It is also a CXO speech punch line. Some of them say ‘we are creating’, some say ‘let us create’ and some say ‘we have created’ the said environment but the ground reality is almost similar everywhere. Hence whether the statement is uttered in present tense or past tense depends only on the self-confidence of the speaker.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I get with strange feeling that we somehow dislike face-to-face conversations. They are reserved for heartbreaks. Our conversations are largely one sided, even during open houses. We love ‘meetings’. As stated earlier, one of the prime drivers for this is our disdain for owning up decisions. Neither do we want to make and own decisions; neither do we want the same for others. In the name of ‘collectiveness’ we peddle fuzziness so that we get more opportunities to spend time fixing the blame. Or better still, absolving everyone of any blame!
7. Working software is the primary measure of progress.
Sorry! For us primary measure of progress is delivering the codes as per the specifications and getting payments released for the same. If someone wants to build a temple in the dungeon that is least of our problem. We are essentially skill providers – and our entire system, from educational institutions to organisations, is designed for that.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Yes, we do maintain constant pace but not for sustainable development. We love predictability. To achieve that, we love falling in line. Nothing else matters.
9. Continuous attention to technical excellence and good design enhances agility.
Design is something that Indian IT industry never understood. The UI/UX/CX side of design is still regarded as a paint shop job. They may call it whatever but their heart only responds to one word – Beautification! One the technical side, please do not kill me for saying this, writing the specs dictated by the customer is akin to design.
To understand design, one needs to internalize wholesomeness but we love being and functioning in parts. I do not think this is just the industry thing. It is probably our social makeup as well. Overwhelmed by gurus, celebrities and power centres, we always want to look up to someone. Amongst many things, it illustrates our lack of faith in ourselves and our fear to question. Just because HE said it makes IT true!
10. Simplicity – the art of maximizing the amount of work not done – is essential.
Our industry is essentially servile and thrives on daily wages. When we claim to be an IT superpower, we make a mockery of ourselves. Our sole focus is daily wages and hourly rates. And to enhance those, we love complications. We want to increase the total resources spent. We love shipping people to on-site locations. We do not let employees explore various technologies, disciplines, sectors, etc. because confining them to one domain enhances their daily wage rates. In that context, we did manage to make our lives simple – but not to maximize the amount of work not done! The British sent us on-site to plant sugarcane and bananas, and now we are going bananas about going onsite to plant codes. Means may have changed but our methods essentially remain the same.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
We believe in ‘led’ teams though we love talking about self-organizing teams. If people self-organize, we label that as rebellion. Self-organisation, self-governnace, self-motivation – they are all seditious terms. No wonder we are rather bad with architecture and design. And we have managed to make requirements gathering a clerical job.
Another reason for this is the fact that our organizational hierarchies are not based on core skills. They are based on so-called ‘leadership’ skills. More cattle you can manage, bigger the zamindaar you are. If you love your skills and want to remain by its side, you will be soon labelled as an unambitious loser. Hence all good technical hands and design hats are transformed into ‘managers’ who get the work done from rookies. This is yet another example of how our daily wages based IT industry has ruined the chances of us carving any space for ourselves in this big wide world. We can aspire to be the best service providers but we are yet to find an opening to carve a door for going anywhere beyond.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If you are from the IT industry, or any other industry for that matter, you already know what team reflections stand for. We do reflect regularly, but that too is a must-do task in our task list. It is like the staff rangoli gathering during Holi or Onam. We dress up for the occasion, work together to create pictures for social media and staff reports, and then get back to our daily lives, looking for to the next HR-initiated togetherness.
And the changes that we aspire for often reflect our deep seated fears and biases, complex belief systems, archaic social structures… and what not.
***
Please do not view this article as an angry outburst because the write-up is more about frustration with regards to our missed opportunities. I seriously believe that we had a good shot but we refused to take it. That window of opportunity is still not completely closed so we do have a chance, provided we are willing to fundamentally mend our ways – socially as well as professionally.
And let us not get into the debate of how worthy or unworthy Agile really is because these problems haunted us much before Agile became a buzzword!
