"Being abstract is something profoundly different from being vague … " - Dijkstra
Same goes with "Agile" - regardless of how heavy your pitch is; if you are clueless and directionless, no methodology can save you.
Here are a few tell-tale signs of a very anti-agile structure and culture prevalent in most enterprises obsessed with "agile" -
- Fat layers of management/key decision makers who neither understand how softwares are built, nor how they work. Higher the ignorance, more the need to "control" that which you do not understand.
- Presence of legacy systems with ownerships spread across heavy departments/units; and ceremonious meetings to negotiate integration contracts.
- Dozens of connections/dependencies pointing to one person - the dreaded "God Class" that knows and does too much.
- A constant tension between productive work v/s overheads demanded by management. Reminds me of Kipling's words - "She sends 'em abroad on her own affairs, From the second she opens her eyes— One million Hows, two million Wheres, And seven million Whys!"
Agile is about a bunch of smart builders coming together in "self-organizing teams" - you are either smart at domain or, tech. There are no dimwits to be "managed". It's more of a choreography than an orchestra.
#antipatterns #antiagile
Let "teams" not be a sheer brute force of numbers. May they feed and nourish each other, and reinforce each other's faith in "team-work".
One dozen piggyback'ing on one individual is not "team-work". An individual's potential sacrificed in the name of the greater good of the team or the organization is not "team-work". Dumping all real work and risk onto one individual, while keeping yourself busy with routine or fancy work is not "team-work".
Ayn Rand beautifully portrays the horrors of the "one in all, and all in one" collective society of "equals" - where the quick-minded child with scholarly ambitions, who understood even before the teacher had spoken, is ultimately "chosen" for the vocation of a street-sweeper; as penalty for transgressing and rising above his fellow-brothers in having a "preference".
"He was enslaved by his birth, by his kin, by his race. But he broke their chains. .. But then he gave up all he had won, and fell lower than his savage beginning. .. What brought it to pass? What disaster took their reason away from men?.. The worship of the word "We.""
#Leadership #Team #Nourishment
It's a sad myth that managers "manage" dev projects/teams. Your dev leads are the real ones doing the bulk of the project management, in their carefree, by-the-way style - without making an ostentatious show out of it. That's "white-box" project management - they are not just blindly tracking an opaque task list prepared by the team. And that's in addition to their technical job - individual contribution, tech leadership/guidance and, of course, tech representation in all stakeholder meetings. Everything about planning as well - from scope evaluation, work breakdown, estimates, the right parallelism, the right scheduling, the right skills/people-needs - is done and can only be done by an SME, not a manager.
Before beefing up your management layer while ignoring the bandwidth demands of your technology leadership, do assess whether that need is so real after all (the need should be external-focused). Too much of excess bandwidth at a layer that has no subject matter understanding, and no individual contribution to make (layman review and interference doesn't count as individual contribution - though Trump meddling with scientists is the unfortunate world we live in!), can cost an overloaded team tons of productive hours in fancy meetings and asks, and fancy action items as takeaways from such meetings.
As a pure-play manager; if you sincerely wish to contribute to the team's success, and not otherwise - practice and learn to step out of their way; and realize that it's incredibly taxing to answer all your layman questions; shield the team from all kinds of man-made complications and drama; and strictly refrain from "using" the team to fill up your excess bandwidth. If you feel empty without meetings, find yourself a like-minded counterpart and do yourselves the mutual favor of filling up each other's calendars.
#management #myth
[Re-posted from my recently authored posts on LinkedIn]
Input: x + y = 10. Ask: Solve x and y within a 10% error margin. You look at them with rolling eyes. You tell them that's an infinite space of possibilities!! No takers for your answer. You are outnumbered - they are 20, you are 1. Sounds familiar?
#commonsense #majorityrule
To the layman user, the world begins-ends-and-revolves around the user-interface. S/he is happily unaware of the vast complex universe behind that makes the system a (pleasant) living reality. And that's perhaps how it should be.
When it comes to businesses, however, it is not only childish but also suicidal to be ignorant of; or, to wish away the role, size or, complexity of any work that is not directly "demoable". Businesses particularly have a hard time appreciating any effort spent on the non-functional; as they are the most "invisible", hardest-to-track by non-techies, and not instantly encashable in fancy demos.
Every architecture scales and performs in powerpoint. For businesses overly exposed to presentations, the quality attributes are mere clichés which magically get realized. Whereas nobody has ever seen a ppt execute to prove itself; code does everyday.
The next time you hear wild words being thrown at you - "quick", "agile", "demo", "mvp", "ai/ml" - with tons of features squeezed into a crazy timeline; you know exactly where the person is coming from - the user interface is his/her universe; and the vast complex system beyond simply doesn't exist. Sherlock Holmes would have remarked - "Dear Watson - You see, but you do not observe!" :-)
#seeing #observing
Architecture/Design is not just about drawing and connecting boxes. Coding is not just about typing syntax. Just like the last book you read - unless it was absolute crass - was not about frantically typing away words on paper.
Any finished artifact you "see" is the outcome of a creative and intellectual thought-process. The thought-process itself cannot be "seen". The only way to understand it is to have the ability to (critically) appreciate the artifact itself. Length is not a reliable measure of the thought or work that has gone in, and may well have an inverse relation. Whoever said it (Mark Twain?) - "I didn't have the time to write a short letter, so I wrote a long one". Economy of expression is often a sign of a clear, well-rested mind performing at an optimal, but controlled speed - whereas length is often a sign of rawness, noise and unfinished work left behind due to intellectual lethargy or lack of time.
Any team rightly deserves a manager who understands the work they produce. You are not a mail-forwarding proxy server, and you are not a calendar. Those functions can be automated. They look up to you as a human being in possession of a sound mind that can independently think and judge; and a spine that can stand up for what is right.
#knowledgeindustry #leadership
[Re-posted from my recently authored posts on LinkedIn]
Uncle Bob, in one of his lectures that has stuck with me for years, asks you to imagine yourself having an out-of-body experience and watching over your own open-heart surgery! How would you expect your surgeon to behave at this moment, even in the face of his deadline? Careful, deliberate, knowing what he is doing? The only way to go fast is to slow down and do a good job, and the bad code you wrote yesterday will slow you down today; he firmly reminds you.
Code Quality is perhaps the hardest-to-quantify metric in the industry. In many organizations, it stands for a bunch of static code analysis reports that gets fed to management dashboards. While certainly a good starter, they are far from adequate. Just like you can write a perfectly crappy novel even with the help of a writing assistant (for writing is way more than just structure, grammar, and textbook rules), so it goes with code.
Coding is akin to writing – it takes skills, experience, and thought. A prerequisite to sound thinking is "thairaav" (for lack of a better word in English) – the antithesis of what in Zen is symbolized by the "Monkey Mind" jumping around from one unrelated activity to another, settling on nothing. Building a coding culture in any organization starts with this realization.
#coding #culture
One of my favorite poems I recall particularly on this day is Tagore's "Let my country awake". Most Indians are familiar with the famous first line, of course. The poem is a grand vision of a truly "free" and progressive India; but the message is so universal and ageless that it applies equally to a progressive world, a progressive organization or, even to an individual's personal world and awakening. It reminds us of all that in our culture imprisons versus liberates us.
Here's the full version from Gitanjali, translated by the Nobel Laureate himself -
Where the mind is without fear and the head is held high;
Where knowledge is free;
Where the world has not been broken up into fragments by narrow domestic walls;
Where words come out from the depth of truth;
Where tireless striving stretches its arms towards perfection;
Where the clear stream of reason has not lost its way into the dreary desert sand of dead habit;
Where the mind is led forward by thee into ever-widening thought and action–
Into that heaven of freedom, my Father, let my country awake.
#tagore #culturetransformation #india #republicday
There are no unqualified problem statements in the real world. Any real-world objective function comes with it's (externally) stated set of equations/inequations that bound the feasibility zone of finding an optima. An optima that goes beyond these extremities is hence a mathematically impossible ask. A mutually contradictory set of constraints can even make this feasible zone vanish completely, making the problem itself an infeasible one to solve. Often times, while judging the merit of a solution, one gets too obsessed with the objective, while being lazily ignorant of the set of constraints the objective was subject to.
#problemsolving #review
[Re-posted from my recently authored posts on LinkedIn]