Often directors, managers and other decision makers talks about an advanced challenge they have: What can we automate, who should automate and what tools to pick. There more and more I listen, the more I hear – they have not applied any models of the problem at hand. And there usually is a model of the problem space already. Any old model is preferable over no model at all. But it can be hard to see in the middle of chaos.
Recently it came up how to have a successful agile transformation. There’s a paper for that:
it will not be sufficient to settle for an extraordinary development team and committed middle managers if the top management support is lacking.
The Agile Success Model: A Mixed Methods Study of a Large-Scale Agile Transformation,
Recently It came up how to organize an Test Automation as a Center of Excellence – there’s a (Team Topologies) model for that:
I prefer to think of a CoE as an enablement function. On the one hand, a CoE is there to provide a product (i.e. the automation) but on the other hand it exists to enable consumers (i.e. the product and development teams) to consume this product. It does this by providing a set of repeatable standards, governance frameworks and best practices for the rest of the business to follow during the cloud migration.
Building a Cloud Centre of Excellence in 2020: 13 Pitfalls and Practical Steps,
Recently it came up what engineering activities to drive in order to have a high-performing team, there’s a model (and a book: Accelerate):

And I could keep on
These things aren’t new to the global industry – but they might be new to specific teams. It puzzles me. My current model is that the teams that ask don’t have a learning / generative organisation or the team members don’t seek knowledge on their own. Or it could just be my scientific schooled mind that sees patterns and models everywhere. It might be an unique quirk to the people being active and engaging.
And it can be hard to know on the Interwebs where to dig for the gold. But the first step is to realize that things can be different. And you have to realize that getting to information is key to keep up – as everything changes.
Much can be said about old frameworks and classic test approaches, but I would rather follow an old map than none at all.

[…] #263: There is a Model for your Trouble Written by: Jesper Ottosen […]
LikeLike
“…it is the willingness to learn, and willingness to learn requires two conditions: a mismatch between mental models and reality and enough of free processing power to notice that mismatch.”
from https://www.kda.zone/post/wardley-mapping-is-not-for-everyone
LikeLike
[…] 263: There is a Model for your Trouble – Jasper Ottosen […]
LikeLike
[…] “good market practice” is rather codified know-how of how things used to work at the time of writing. Even the authors of the much-hyped “Spotify model” (from 2012) say that their article […]
LikeLike
[…] With digital solutions there is a ongoing urge to release often. A quest for feature toggles and continuous deliveries of new features and fixes. Automation of tedious tasks do help to drive consistent deliveries and aids in driving high-performing teams. There is good research to support that. […]
LikeLike