Dennis Mansell

Yesterday, two of my favourite bloggers go into a spat on Mastodon:  @tante accused Cory Doctrow of 'straw-manning' the anti-slop/Luddite movement in a blog .  Later that day, after a 'that escalated quickly' argument that is usually reserved for x.com, tante published another blog to address the reactions to the original piece.   At first glance, this looks like a ' straw-motte ' discussion - a bait-and-switch tactic that content creators use to capture attention: accusing an offside remark of being a straw man, then building an stone-clad counter argument (a motte), which is then accused by the original party of being a straw man, countered with a motte, which is a straw man, etc. ad-infinitum.  But on closer inspection, it turned out that there was quite a nuanced discussion going on - that is, beside the usual flame war.   The discussion went as follows: Doctrow mentioned in a blog that he uses an LLM to clean up his content.  In the blog...

 As 2025 draws to a close, I'm having quite a few conversations about what people want their organisation to look like in 2026. Normally I would of course make a hefty consulting engagement of this, but as this is a time of giving and good cheer - here is a do-it-yourself guide to choosing a transformation:  

 Agile (a.k.a. the agile industrial complex) is dead (or dying, or undead... read on). Of course Agile has been declared dead many times, but now we can see that there are fewer visitors to Agile conferences, fewer people looking to get certified as something Agile, fewer people are calling themselves Agile Coach. Dying The Agile conferences have talks about how very large companies do Agile, which tools they use to collaborate or how non-IT departments do Agile, topics that were also there ten years ago. Agile conferences have yet to adapt to topics like decentralized enterprises, fluid teams, remote-only organizations, AI helpers and commons governance. The certification crisis seems to follow a similar pattern: was this ever a good measure? Those courses were meant for setting off down a path that makes you better at discovering and uncovering effective ways of working - perhaps we're running out of people who have yet to start, whilst not offering enough to th...

  This was a blog post on one of the sites of Highberg , in Dutch.  The blog is about:  1) Agile is not a goal 2) Change should be continuous, not following a plan 3) Change should not be top-down or bottom-up but collaborative Drie Agile-transformatielessen van een Agile Coach In de wereld van Agile ontwikkeling deelt onze Agile Coach, Dennis Mansell, de drie meest waardevolle lessen die hij heeft geleerd. Ontdek de essentiële inzichten voor een succesvolle Agile transformatie. Hoe ben je in de wereld van Transformaties terecht gekomen? Bijna tien jaar geleden ging ik over van een leven als zeiler en ondernemer naar fulltime Agile coach en/of programma manager. Ik kende Scrum inmiddels redelijk goed uit de softwareontwikkeling en had wat Design Thinking ervaring. Dit was een zeer zeldzame combinatie, want veel bedrijven wilden toen "Agile" werken. Intussen heb ik organisaties gezien van startups tot eeuwen-oude familiebedrijven, online gemeenschappen tot overheidsinstant...

In November 2020, the new Scrum Guide was released, mentioning for the first time a ‘Product Goal’. This block is designed to help you find your product goal.  Attribution to The Liberators , the Scrum Guide and Harvard Business Review .   Preparation (online): Make a Mural from this template You need a video conferencing meeting with 'rooms' of up to 4 people Preparation (physical):  Super Sticky notes in at least 4 colours Print Elements of Value Pyramid as handout Flip-over sheets Flip-over of empty Elements of Value Flip-over of Wicked Questions Flip-over of Integrated ~ Autonomy Flip-over for Actions/Steps 15% Solutions

I've made browsing my CV a bit less cumbersome:

The Company to Consumer model under threat teambrunel.com Originally I became interested in agile software development when I started to discover a pattern between great teamwork in yacht racing and teams that produced software.  Some of the greatest software teams that I worked with were people working together on open source projects. Thousands of people worked together in self-organizing teams throughout their technology stack, much as if they had belonged to a single organization.  Could that model work in more organizations? There was an essential thing missing though - most of these teams were making things that were useful to themselves but not necessarily to a user who would be willing to pay.  Motivation was often very idealistic: working on free (as in liberty) software usually entailed working for free (as in beer).  Some projects became wildly successful, imagine a world without Linux , Wikipedia or Bitcoin .  But do you remember Joomla , M...