For anyone not (yet) in the know, the tech industry invented and popularized the business approach of Agile. It started in web consulting and then found its more permanent home in software development. Scrum is by far the most common way to implement Agile.
I’ll write a bit about what Agile and Scrum are. But I also want to hear about the experiences of readers.
Agile
We know a lot about Agile at a broad level, but it remains schematic and squishy. It’s little more than an idea and set of principles – things that set out an approach to certain kinds of business problems. Unfortunately, most people who think about Agile catch themselves in its various means of implementation rather than the core ideas.
In short, Agile stresses business agility – a bit of jargon that means little more than ‘dealing with change.’ Especially change in a digital world. Companies claim they implement Agile in order to adapt to change in the digital age.
Digging a bit deeper, we can find some of the ideas that motivated Agile. These ideas came to us from the tech industry (first web consulting, and then software development) of the 1990s and early 2000s. Particularly, there’s the idea that the people doing work should organize their own team and closely interact with the customer. Teams cut across types of work and they work iteratively, constantly seeking feedback both from one another and from the customer. And so, we find some of the ‘libertarian’ tech impulses behind it.
Again, in theory they do these things to avoid the confusion and headaches that come from teams designing and building technology independently from one another for customers who are deeply confused about what they really want. This made sense in web consulting – where customers were almost always deeply confused – and software development, where that’s often the case. New products and technology confuse customers. It makes far less sense in industries that don’t change their products often.
Agile Manifesto
We can find the clearest expression of these ideas in the Agile Manifesto, a software development document. It includes all the hits: iterative work, feedback from the customer, people working together across areas of the company, and so on.
It further warns companies against focusing on processes and tools (i.e., how people do the job, what gadgets they use for it, how they show their work, etc.) over people (i.e., the people who do the work). In short, it warns companies against the field of project management. Project managers, by the nature of their job and training, put processes and tools over people. They built their entire profession around the fetishization of processes and tools.
By contrast, the Agile Manifesto arguably promotes the elimination of the project manager role. Teams can eliminate the parts that don’t need to be done and distribute the rest across team members.
That’s the idea, anyway. Implementing it is much trickier.
Scrum
And there’s the rub. Agile is really just a few ideas. Companies then have to implement it, and most use Scrum to do so. But it’s hardly the only way. They might choose, for example, a Kanban (i.e., work process board) approach. Or many others.
So, hardly anyone argues against business agility. But plenty argue against how companies implement Agile.
With Scrum, companies break up their staff into semi-autonomous teams that closely collaborate in their work. They divide their work into short ‘sprints,’ usually 2-3 weeks, where they complete a bite-sized piece of work.
In business theory, this goes nicely with Agile because it allows teams to do work in small batches. This allows – again, in theory – for work teams to experiment and iterate. People can clearly see what work needs to be done, and they can see what everyone else works on. Assuming team members work at about the same rate, this evens out workloads and keeps anyone from working too hard or having too much free time.
The accuracy of all this theory is a separate issue. Companies can use or abuse the data in all sorts of ways. The company looking to weed out slow workers, speed up the line, or annoy the hell out of their best workers can all find plenty of material to accomplish these things with Scrum.
Your Experiences
So, I’ve described Agile and Scrum a bit in this post. In the software world – and increasingly in the business world – this all takes on the status of a religion as much as a business method. Companies regularly try to apply some of these ideas (Scrum, SAFe Agile, et al.) well beyond their original applications and in areas where they’re extremely unlikely to succeed.
There are also deeper issues I might explore in other posts, such as the ‘class war’ components of all this – e.g., deskilling the work, ramping up productivity or efficiency without compensation, et al.
But for now, I’ll ask some questions of readers. What’s your experience of Agile? Has your company implemented it? How did it go? What industry do you work in?
