Thread by @astralwave

@allenholub Perhaps Scrum simply isn’t “ergonomic” enough to encourage the right behavior, for those who follow it.

Scrum adds a lot of cognitive load in the form of ceremonies and tooling. A tool like JIRA and their ilk can add additional cognitive load, too.

@allenholub The higher the cognitive load, the much harder it is for those who follow the process to engage in high-uncertainty tasks which require mental willpower.

@allenholub I’ve found Scrum and JIRA (the most common combination) to be increase team cognitive load such as to make folks more resistant to change, less open to uncertainty, and more defensive about their “work hours”.

@allenholub A huge part of this is how Scrum shines a (really bright) light on the constraints of time, which brings out the worst of people’s anxieties – “there isn’t enough time for me to deal with this uncertainty right now!”

@allenholub Worsening this, is how Scrum encourages the worst behavior of the org’s middle management layer, viewing it as a way to change their minds every 2 weeks.

@allenholub I’m not saying this happens with every team or every org’s middle management.

There are some superhuman teams out there who can put up with the cognitive load, and some managers who “get” the cost of high WIP, context-switching, and lack of empowerment.

@allenholub But the fact remains that many orgs adopt Scrum when they begin their journey toward agility, and common among these orgs are exactly those traits I’ve described.

It doesn’t help that Scrum has a reputation for being “agility for dummies”.

@allenholub So, rather than Scrum disallowing continuous improvement, it appeals to a certain type of org and brings out their worst anxieties.

Especially when they already view their ability to innovate as non-existent, and are frustrated about too slow to market.

@allenholub Shining a very bright light on the time constraints of the software product development process isn’t actually helpful, counter-intuitively.

The speed wasn’t the problem, obviously. The problem is in the org’s obsession with “pushing” assumptions down to teams to execute.

@allenholub Perhaps this is why Scrum has a bad reputation. It emphasizes time-to-market, which attracts orgs with problems with that specific problem.

Counter-intuitively though, it’s better to focus on market-pull (frequency of learning) rather than feature pushing (velocity of dev).

@allenholub What Scrum gets wrong, mostly, is how it discounts one half of the software development process, the part where you discover risks and learn about your customer. This results in awful adaptations like “dual-track agile” that force teams into a mini-waterfall process.

@allenholub Kanban is far better, adopting a limit for in progress items, which helps teams focus and spend less time on analysis-paralysis or premature-optimization, without shining a light on how long something takes and inflaming anxieties around “how slow everything is”.

@allenholub For teams transitioning to a state of agility, Kanban also excels in shining a light on these common org problems:

- Dependencies
- Lack of focus
- Handoffs
- Deferring risk (conducting research to “validate” instead of “discover”)
- Waste (documentation, specs, meetings)