Show newer

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

What's more, the team are learning loads from the experience of running the manual service, and are able to feed the insights from that into delivery of the strategic solution

Show thread

So they asked developers to build a manual workaround to see them through the gap. The architecture isn't pretty. It's not what anyone would have wanted. But it works. Users are getting a service

Show thread

On initiative A, the team learned that a "strategic" solution to their needs would not be ready in the required timescales

Show thread

Code is cheap; ignorance is costly

In the past few weeks I've seen two different responses to team interdependencies in software products. I like one much more than I like the other

"Often IT systems complicate rather than support integrated, multidisciplinary care. That’s because IT is just a tool; automating broken service-delivery processes only gets you more-efficient broken processes."
The Strategy That Will Fix Health Care hbr.org/2013/10/the-strategy-t

"Technical solutions alone are not transformative, nor do they satisfactorily mitigate risk. Now more than ever, solutions must be socially constructed, collectively owned and collaboratively delivered"
Psychological safety as a cornerstone of improvement - NHS Providers
nhsproviders.org/news-blogs/bl

After a hiatus due to change of job, the pre-election period, and all-consuming work on a new service, it feels good to be back and posting among the crew weeknot.es/

When applying, please speak to us about how we might be able to accommodate a flexible working arrangement. If it works for the service, we will do our best to make it work for you

Show thread

* Experience leading strategy and change in large complex health and care environments
* Excellent user centred design understanding, especially in the health and care context
* Experience of championing diversity and inclusion

Show thread
Show older
mastodon.me.uk

Open social media for the UK