About a month ago, I wrote a post on Agile – a set of ideas, business methods, and (perhaps) ideology. I invited readers to share their experiences with it, and I reflected a bit on my own. There’s also plenty of business literature available to those who want to find it. In short, Agile starts from the need for business agility (i.e., adaptability to change), and then it moves to a variety of methods of implementation. Scrum stands out as the most common.
With a month behind us, let’s take another look at Agile!
Theory and Reality
Agile can be slippery. For one, companies can do it well or poorly. We have now a million ways to implement it. We find this in its natural home of software development, but we find it to an even greater extent as it moves into non-tech areas.
In light of that issue, I’ll focus mostly on non-tech, white-collar uses in this post. Writers have already spilled plenty of ink talking about Agile in software. I’m more interested in how business ideas and jargon move well beyond their starting points. I’ll also focus on both theory and implementation.
In terms of the bigger picture, one of Agile’s biggest challenges is that business agility simply isn’t as important to many parts of the business world as it is to the software and web consulting worlds. That’s not to say it’s unimportant. Rather business agility stands out as a constant, relentless issue in tech in a way that most of the world doesn’t match – and doesn’t need to match.
Many rank-and-file office workers do fairly stable work. They, e.g., work on contracts, work on standardized work, build established products, and so on, that have precisely specified rules and don’t change much. If they followed an iterative process in their work in the way Agile prescribes, it would mean they’re bad at their jobs, wasting time, or developing things contrary to what the customer wants.
Not so great.
Collaboration and the Usefulness of Scrum
And then there’s the issue of how companies implement Agile. Most do so using ‘Scrum.’ In Scrum, small teams work on small, defined projects they can complete in a week or two. They call these time units ‘sprints.’ Larger companies might build it into a much more complex system like ‘Scaled Agile Framework‘ (SAFe Agile). With SAFe, in particular, the biggest danger is that it tends to be too top-down and bureaucratic, which places it in tension with the original ideas for Agile.
But the basic point is that a ‘work group’ consists in a small number of people working together constantly. And – here again – we find many differences between the software world and the non-tech, white-collar world.
Some white-collar work involves collaboration. Some, however, does not and, ultimately, should not. We find tighter limits to the usefulness of this kind of collaboration in non-tech fields. In this respect, we see a major gap between business theory and jargon, on the one hand, and the actual workplace, on the other. Business theory treats ‘collaboration’ as the greatest thing since Adam Smith. Often that just isn’t so.
In fact, many white-collar job roles just don’t fit Scrum very well. The job either involves mostly individual work, or it involves work that can’t be broken into short units, or it involves non-iterative work, and so on. There’s a big danger in white-collar work of forcing onto a company a model that doesn’t fit.
Class Struggle, Capacity Planning, and Project Management
Finally, we see some notable issues here of class conflict and struggle. Some companies use Agile as a way to plan work or even deskill work. Business theory typically teaches managers and leaders that one of their jobs is to measure work in order to gauge worker capacity. But if the work is specialized or requires specific knowledge, those same managers might not understand the work very well. Or – even if they do – the work might not lend itself to easy measurement.
In that case, those companies use software tools like JIRA to turn the work into measurable units. Perhaps this works in software, which is what JIRA seems to have been designed for. It rarely works anywhere else. And it carries risks for both manager and employee.
For the employee, it promotes mindless focus on the quantity of work over the quality of work. It breaks their work down into parts that might or might not match how the work is best done. It also requires excessive documentation and surveillance. And the for the manager, it encourages short-term thinking of a kind that’s dangerous to the company over a longer horizon.
A related danger is that many forms of Agile implementation involve investing dangerously high amounts of power in project managers. Sometimes the ‘project management’ hides behind other job titles, such as Scrum Master or Product Lead. This amplifies problems with JIRA because project managers, by trade, tend to put processes and tools over democratic team management.
The Usefulness of Agile
If the reader needs a take home lesson it’s this:
Companies can do Agile well or poorly. In general, the more decentralized and democratic, the better. And the more centralized and fetishizing of processes and tools over people, the worse. The more controlling and Taylorist, the worst.
Agile tends to work best when it exemplifies the Agile Manifesto. The best forms of Agile put people (rather than project managers or leaders) in charge of the work and much of the higher-level decision making. In practice, however, Agile tends to diverge from this – at least in the white-collar world. And, on that note, whether Agile works well or not highly depends on the nature of the work itself.
Postscript: A Note on Agile Terms
I’ll note here at the bottom that, again, there’s a distinction between Agile the basic idea and methods of Agile implementation. In this post, I discuss Scrum quite a bit, but companies can do Scrum in many different ways.
While many business theorists attend to these distinctions – usually poorly – I don’t get too bogged down in all that in this post. If the system is so complicated that one can’t discuss it without writing a book-length glossary, then that itself is a big problem with a company’s way of doing Agile.
