2026-06-29
Before we discuss the specifics of any supposedly 'Agile' management methodology, we should ground ourselves in the Agile manifesto itself. Thankfully, it is extremely short:
All of these are good and true. But the intersection between these principles and Agile development in practice is approximately zero.
There is a very good reason for this: these principles are very good ways to work; they are very bad ways to show that work has been done.
The Agile principles benefit the experience of actually creating working software, to the detriment of institutional legibility. Working software is the best metric of success, but your manager may not have the expertise to assess your software, and they definitely don't have the time.
Your superiors' assessment of how good a job you do necessarily relies on proxy measurements: tickets completed, backlog size, velocity, blockers in standup. These proxy measurements are, at best, noisy correlates of the actual work you've done. At worst, they're totally uncorrelated. Nevertheless, you will be judged by them, because it is uneconomical to collect better data.
Lots of organizations make a big song and dance about being 'data-driven' and collecting internal metrics. This is almost always pure fantasy. More sophisticated executives understand it, but they rarely have the power to change this.
From the software industry's origins in the 1950s, software projects were managed using Waterfall, a system of project planning and management originally developed for industrial manufacturing. Why did they do this, even though the process of software development, like any knowledge work, has no resemblance to mass industry?
Because that system was optimized for legibility, not for productivity, and these are the revealed preferences of virtually all firms: it is better to have a giant spreadsheet telling you exactly why a project is failing than to be in the dark, vaguely hoping that the project is succeeding in places you can't see for reasons you don't understand.
The key academic sources on this division are Robert Jackall's Moral Mazes and James C. Scott's Seeing Like a State. Neither of these books are about technology or business management, but both are 100% worth your time. I'm also leaving several blog recommendations that apply these ideas to Agile and software development.
Now, based on all this, you might expect me to say 'legibility is bad, you should prefer illegibility'. No.
First, because you just can't run even a medium-sized organization like this. You'd have a panic attack within a week.
Second, because whatever words are printed on your job description, your actual job - the thing you get paid to do and which will get you raises and promotions if you do it well - is to deliver value for your employer. This is much more important than fulfilling the black and white text of your job description.
But if you want to reap the rewards for delivering value, you need to convince the people above you that this has happened. Value isn't a physical thing: you can't measure it with a thermometer. It's the textbook example of a social construct: you're delivering value if your superiors, who have the ability to define the social reality of a firm, believe you are delivering value. And they form those beliefs based on... indirect, unscientific proxy measurements, which can sometimes be totally uncorrelated or illusory.
Which is why I suggest you rethink your relationship to this monstrosity:
Officially, this is a tool for organizing and coordinating knowledge work. I do not believe this is the case. In fact, I can think of few ways less effective and more cumbersome to organize knowledge work. It's a C-Suite fantasy. But you can better accomplish your goals by helping to keep that belief afloat, and tools like a Kanban board are how you interface with this system.
You should use that tool intelligently. You should also use it ethically. First because you should generally be an ethical and virtuous person, I hope that goes without saying. But second, because this representation of reality cannot drift infinitely far from reality. It can drift very far indeed, much more than you think, but the longer and farther it drifts away the more likely it is there will be a sudden correction that ends with you out on your ass.
This gap between reality and social consensus -- recognizing it is there, and that you can manipulate it -- is not cheating, illegal, or unethical. It is one of the fundamental building blocks of all human organizations. It is where all the illegible work lives, and it is the lubricant that allows real delivery to continue while the C-Suite entertains high-modernist fantasies of organizational work.
These are the rules of the game, and you must play it, so play it with skill. Then use the rewards of playing it well to create places with different, better rules.
And it goes without saying, nothing I've said here should be repeated in earshot of executives. Zip your mouths if you know what's good for you.