Agile Is Dead (Long Live Agility)

Yes. I think this is one of the most important and yet misunderstood aspects of agile. You aren't throwing out the right terms, just re-prioritizing them.

> anyone who comes up with something bigger or more complex is just trying to sell you something.

I don't think being misled by snake oil salesmen is the only, or even the primary reason people get misdirected away from true agility toward 'agile'.

There are intrinsic motivations and interests in most human organizations which lead against actual agility.

A few of these include:

* The need for people in many positions to feel and be able to represent themselves as in control of the process and product;

* the desire to have someone else to blame when something goes wrong;

* the interest in shortcuts and magic bullets, instead of realizing how much work and time things will actually take (including from non-technical stakeholders).

There are social/organizational reasons that make true agility hard, especially in large organizations, especially in organizations where software dev/IT is just one component of a larger mission. But that doesn't change that actual agility is the only way to produce high-quality software efficiently. And we probably do need people investigating and suggesting how we overcome these barriers; but indeed, the 'agile' industry has not succeeded in doing so, they mostly take the easier path of figuring out how to cater to these barriers while calling it 'agile', instead of how to change organizational culture and surmount them.

Dave didn't seem to mind cashing the checks he got for all the "agile" books his company published. This piece would have been interesting in, say, 2008, but now he's just riding the wave.

While it's true that many people do not really learn or understand scrum, I do not think that just getting a good trainer is the most common problem. There is something way worse, and harder to cure:

You can't teach something to someone if their livelihood depends on them not knowing it.

For instance, if you start with an departments whose sole job is build software, and they make scrum teams that happen to have 5 people that only know the business, 3 testsrs that don't know how to write code, a dba who is the only person who can change DB structures, and 4 developers who do not talk to users, there is NO WAY you can make scrum work without major amounts of turnover. 13 team members is too many for a scrum. Scrum members have to be able to play multiple roles, even if they are only excellent at one of them. Otherwise, the team is not self organizing, and can't adapt to much.

Most large organizations around town that claim to do scrum follow that pattern, and the end result is that they are doing all the scrum ceremonies, but the teams are lumbering hulks of failure.

I agree with the article: Agility is more important than the process, and people have to carry agility with them. If your team is full of specialist that can't claim ownership of the totality of the team's output, there is no agility.

> Of course, this involves a fair amount of thinking, and the basic loop is nested fractally inside itself many times as you focus on everything from variable naming to long-term delivery, but anyone who comes up with something bigger or more complex is just trying to sell you something.

Basically, the process is recursive, but my explanation is more agile.