Agile in the Ether #54 / 17th February

We talked about these topics (with some links shared along the way).

(Much richer notes this month, thanks to Andrew Maier)

How do you help make decisions stick? I struggle with things getting decided then forgotten, revisited, and reinterpreted.

How might you articulate the value you bring to teams as a delivery lead/program lead or agile coach?

Everyone is afraid of change. It’s an evil word. What do you use instead to induce organisations to face up to issues and adapt?

  • How, if at all, will people’s roles change? Will responsibilities change?
  • Build delivery principles into the business case rather than focusing too much on the technology itself  (
  • Have frank conversations about what’s not working
  • Embed people using the current system into the team — bringing people affected as close to you as possible
  • Change is associated w fear. Create psychological safety; make it easy to admit when things aren’t going well. Run a workshop. There’s a lot of reasons people don’t feel safe.
  • Be clear about the decisions you had to discard/forego and why.

What do I need to do to help the team I work with accept more uncertainty and vagueness in the work presented to them?

  • How can we invite developers — even junior developers — into the design process at a point where they see the uncertainties we’re reckoning with… while also protecting the young engineers from the chaos? Someone else adds “from thinking?”
  • We can’t alienate developers from problem framing. We need to bring developers into the process by which we set the agenda for user research. […] Here are a few ‘how might we’ statements that came out of user research.
  • Ask the team to define how they’ll know when the project is done. Reference to Will Myddelton on discovery.
  • Agile was predicated on changing requirements and dealing w uncertainty, but that itself is predicated on having the technical proficiency to be responsive. While scrum ceremonies give us a baseline for being responsive, it also suggests that we intentionally limit our focus so that we are better able to respond to changing our understanding over time.
  • “This sounds like engineers are too siloed into thinking that all they do is deliver code that meets acceptance criteria” We’ve somehow tricked ourselves into thinking that our job is just delivering design, delivering code, etc. We need to change our frame to running experiments by which we might affect outcomes.
  • “Coding to a requirements specification is like walking on water: Both are a lot easier if you can freeze things before you start”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.