How We Grow Junior Developers at the BBC

Exactly. I would rather take a first-semester web development student who shows those foundational bright spots than a 20-year developer who does this as a 9-to-5 job.

I work with people who did things their own way for 10+ years, never worked as team, never kept up with a quickly changing industry, never improved their skills, that now they're opinionated, they feel that as long as something works it's good to go, etc.

Introducing them to a code review workflow exposed how truly uneducated they were. Code review turned into education sessions, explaining how fundamentally they've misunderstood or misused CSS, javascript, or the tools we use.

It's dramatic how much money and time is wasted because no one with authority to fire them wants to. Back when I ran my own studio I let people go the instant it became clear they weren't going to make it, but these people couldn't pass a simple interview with me.

My company sees it but keeps trying to find ways to solve the problem. You can't throw training at it, you can't throw more meetings.

> If you had to design a better agile process, what would that look like?

It would have a well-defined process and standards for proposing, testing, evaluating, and adopting process changes.

In fact, that's all it would have; you'd start with that and apply it to the combination of itself and your pre-existing dev process, whether or not that process claims to be “agile”.

If your process isn't centrally about continuously optimizing itself to business circumstances, tasks, and team personalities and skills, it's not agile.

> Is this the case for every company doing scrum? I find some benefits in scrum:

I find a lot of benefit in many agile methodologies on paper.

But where the rubber meets the road, the principal decision makers have a vested interest in not holding up the principles of agile.

> It is not about 'tracking', but rather encouraging effective communication to converge on the best path forward.

For any path forward, managers need to answer these questions:

* What needs to be done?

* How long will it take?

* Are we on track, behind or ahead of schedule? (This needs to be answered at least once a day.)

* What, exactly, are the pain points? (Again, once a day at least.)

These can be summarized in a Scrum standup, but what managers really want to see is a detailed analysis. Hence the need for:

* Detailed task breakdown of each story/ticket

* Detailed time estimates on each task

* Detailed daily-at-least time logging on each task

So yes, it absolutely is about tracking. Tracking is the central component of any corporate software process. Tracking is what enables your manager to get a picture of what currently needs to be done and how far along the team is in getting it done. Inasmuch as agile processes can exist in this environment, they must be reshaped to accommodate the tracking requirements. Which means they won't be agile anymore.

Tracking also provides the benefit of an auditable paper trail, so that when government regulators come sniffing around they have a nice log of who did what when on the software.

In short, Agile has by and large failed. It does not adequately meet the needs of upper and middle management of a corporate shop, for whom time is money and there are strict accountability requirements.