Ken McCormack
Sep 5, 2018 · 2 min read

Not sure about the term “The Daily Scrum”… it’s generally termed the daily stand-up meeting. TBH, I don’t agree that Scrum is always a positive force — I’ve seen it produce far too many negative outcomes, as it emphasises management over engineering. It can be pure theatre, giving the illusion of value being delivered, where often there is none. Very often, a product (architecturally) can be flowing quickly towards a dead end, but we don’t see this until late because we’re too obsessed with learning only in small, risk-free increments. To draw an analogy from the well-worn test pyramid, I’d suggest that “you have to plan and iterate at *all levels*, not just at micro level.”

Scrum is a micro-management approach, pure and simple, with quite an onerous time management overhead — for that reason I think it’s better suited to junior teams where self-organisation isn’t a strength! Lower frequency meetings can work better — the granularity with which you adjust the work stream depends on the complexity of the task at hand, the cost of context switching, how much tasks interrelate, and how much support the team needs from each other on a daily basis. Good technical practices — like open communication, pair programming, continuous testing and code review are far more important.

A recent example, I was on a core team of v. senior architects and engineers, split to only 10% of my time (i.e. 4 hours of a 40-hour week). The product leads were relatively inexperienced, newly certified Scrum practitioners, so they insisted on a 15 minute stand-up, every day, plus planning, retros, etc… this burned 56% of that 10% time allocation! The implicit assumption was that we’d all do overtime (to meet stand-up promises, to build products internal customers didn’t really want, then push them into production, to gain KPI points for the product owner), pretty toxic, a requirements waterfall, pure waste, even by enterprise standards. The poor sponsor kept saying “customer” and “minimum viable product” — all Lean ideals by which we work intuitively (anyone remember AGILE?), but management subordinates insisted their KPIs should take precedence!

In this context, Scrum quickly becomes an implement of torture, limiting the engineering creativity of the team, and in this situation, the customer would be far better off with developer anarchy — leveraging the raw talent of engineers to provide solutions to customer-focussed outcomes. IMHO ‘Enterprise Scrum theatre’ rarely gives better than -200% value, unless your team is ‘new’.

    Ken McCormack

    Written by

    Technology Leadership and Software Architecture for Continuous Delivery and DevOps