The talk is insightful. He argues that Scrum is not agile and that it imposes a very strict set of rules that have nothing to do with true agility.

While I am convinced that Scrum isn’t agile, I’m not convinced that we don’t need processes or habits at all. Another talk of his is this:

Basically, what agile boils down to is self-managing teams composed of self-managing people working in close collaboration with the customer. This requires an endless supply of motivation for development. If we take the team is motivated as a given, then it’s certain that hindrances from rigid processes don’t make sense. For me, for Allen, and for many others, this may be true, but my experience shows me that those who are really motivated to develop even for free are in the minority. For most folks out there, development is a job like any other. Their supply of motivation is limited, and when we make them self-govern, they might not actually do the work; they might just read, doodle, spend their budget on useless things, get bored, and jump to another job.

In his second talk, he says, “We assume we’re grown-ups.” I’d like to assume that as well, and I certainly assume this for myself—I’d do development on my own time. Most of my development in the last 25 years has been essentially for free, without an explicit financial goal. However, when I’ve managed projects, I’ve seen that real life doesn’t always support such an assumption. Software development is a lucrative profession. If we start with mainly financial motivations, self-governing becomes a bit of a dream. If I’ll earn the same amount whether I work today or not, I might skip the work and engage in another joyful activity. In my case, that activity is another kind of development, but does it matter?

This doesn’t mean Scrum is good and should be endorsed. I don’t like it and haven’t used it much anyway. But the ideals Allen discusses can’t survive on their own. They need some way to supply motivation, some direction, some form of soft governing. Agile in its original sense looks like anarchy, but anarchy often gives birth to some form of governance at some point. In the past, there were people who had no hierarchical management, but when hierarchies were invented (or introduced by others), they became powerful.

We can continue to believe that developing like aboriginal tribes, in a people over processes fashion, leads to ultimate success. That may be true in certain scenarios, but in general, those tribes can’t maintain coherence after a certain size. Development teams, in my humble opinion, are similar.

There is a common delusion that if people are busy working, they are contributing. However, true contribution often stems from taking calculated risks.

Why should they take the risk? It is often more rational for employees to focus on small, low-stakes tasks than to take on challenges that push boundaries. Why should they bother improving software performance, for example, when the most frequent requests they receive are related to minor UI changes? The former carries a higher risk of failure and is technically more demanding, while the latter is easier to achieve and often more visible, making it seem more rewarding.