On Agile

“Agile”, “Scrum” and “Kanban” all get a rather bad reputation among developers on the internet. They seem to work well for some teams, but for others these are “waterfall or spiral development in agile clothing”.

At worst, teams take tasks off a todo list however they would anyway and call it ‘agile’.

At best, maybe the differences can be explained as “‘agile’ works well for some kinds of development work; but not well for others” (I’m not convinced by this as-such) or “‘agile’ works well for good teams. For good teams, anything would work well”. (Which wouldn’t mean ‘agile’ is useless; so much as, it’s not a silver bullet).

But part of the disagreement, I think, comes from the ol’ “people using the same words to refer to different things”. Especially people with different understandings, let alone experiences.

I’d come across the terms ‘kanban’ and ‘kanban board’ for years before I picked up a book which discussed kanban. I was surprised to see the idea of a kanban board was related to principles: visualize the workflow, limit work in progress.
“Either a worker is idle or a task is idle”. The idea is to maximise ‘flow’ of tasks. Limiting work in progress and visualizing it on a board ought to help identify bottlenecks, which can be addressed.

Beyond that, there are all sorts of details as to tactics and techniques for implementing this. But the basic idea sounds ‘obvious’ and intuitive and, for some workflows, a good idea.

I, uh, don’t know if a ‘kanban board’ can properly be called a ‘kanban board’ if these principles aren’t followed. I suspect places which just use the column-of-tasks aren’t likely to follow “limit WIP”. But I suspect most places which don’t follow “limit WIP” are still happy to say they “do kanban” and are agile.

In any case, it seems unprofessional that so many development teams would be using ‘kanban’ or ‘scrum’ but without following (or knowing) the key ideas. I think this is because agile sounds hip.

Being surprised about ‘kanban’, I’ve decided to read up on ‘scrum’. (The one with ‘sprints’ and stuff).

At a glance, it seems to have the same “oh that makes sense” as kanban, as well as “…because of these underlying values”.

But the book I was reading pointed out: of course if the team doesn’t have psychological safety / trust / respect for each other, then ‘scrum’ isn’t going to work.

I’d guess there’s still value in following a process in order to try and surface problems. But surely a political and unsafe team isn’t going to identify or address problems easily.

I think, then, the hype over ‘agile’ is a bit misplaced.
Not because the ideas around it are worthless so much as the heavy-lifting of effective teams seems to be the psychological safety aspect.
From there, I think the ‘agile’ ideas make sense for a reasonably wide variety of work. (I imagine obstacles like: e.g. a focus on small improvements may obscure long-term strategic mistakes).