Show newer

"far too ready, even after investigations that clearly included the express discovery of bugs in code, to ascribe possible user error to the effect of bugs, errors and defects"

Show thread

User error bias - “a tendency or bias regularly to blame the user of an IT system for something"

Show thread

Bank holiday evening in with the highly readable and instructive Technical Appendix to Post Office Group Litigation Judgment (No.6) “Horizon Issues” bailii.org/ew/cases/EWHC/QB/20

Never been a football fan, but delighted to make a second visit to Elland Road today

In all 3 scenarios, I reckon we're better off for having put a product into the world. But what am I missing?

Show thread

Ugly reason: The organisation is a feature factory and lacks commitment to continuous improvement. You're not alone, this stuff is hard. But at least you now have a working product delivering some value and producing daily evidence of its own deficiencies

Show thread

Bad reason: There was never really a commitment to build the strategic solution. Congratulations, you've just dodged the pain of being dependent on vapourware, and can now move forward by making your MVP more sustainable

Show thread

Good reason: Your MVP has generated new learning, that the core value in this product is smaller and more concentrated than you first thought. Congratulations, you just avoided wasted work on features that turn out not to be needed

Show thread

This problem is real, but let's consider 3 reasons why it might happen: the good, the bad, and the ugly

Show thread

After I posted this thread, several people whose opinions I trust raised the same point: What if you get stuck with a temporary workaround and the better, strategic thing never gets delivered?

Show thread

Inspiring to hear NHS Digital, NHS England, and NHSX urgent & emergency care colleagues talk about the huge strides in digital delivery for the sector during the pandemic
digital.nhs.uk/news-and-events

Bonus link: "The bad news is that a strong culture of 'managing dependencies' will hinder the implementation of the fundamental solutions" scrum.org/resources/blog/elimi

Show thread

The agile way is not to wait. Build alphas and betas. Deliver value to users sooner. When the time comes to throw away that code in favour of something better, value all the learning we gained in the time it was live

Show thread

Any "target future state" is merely that, a target, until it is performing in the world - in the words of the Internet Engineering Task Force - as rough consensus and running code

Show thread

Agile teams don't accept and manage dependencies, they work actively to eliminate them. In particular, they should never accept a dependency on something that doesn't exist yet

Show thread

This seems so wrong. It rests on a misunderstanding of scarcity and costs in digital service delivery. Here's the thing: code is cheap; ignorance is costly

Show thread

While they wait, the team will be disempowered. Their users are getting no value, and worse, the team are not learning anything about the real user needs

Show thread

Meanwhile on initiative B, the team is being asked to wait for another team that has a similar "strategic" solution on their future roadmap

Show thread

When it does arrive, the strategic service will be based less on guesswork, and more on learning that can only be gained by having a live service in contact with real users and real data at scale

Show thread
Show older
mastodon.me.uk

Open social media for the UK