you should be able to change small parts of systems without impacting others
Its interesting to hear that such discussion, about starting with teams ahead of structure can…
Martin May
191

The trouble with this being that this line of thought works for engineering but not e. g. for product design. Modularisation, encapsulation etc. are all reasonable and proven strategies to conquer complexity when technology is your only concern and POV. Unless you just change something deep under the hood that has no impact at all on any human interaction with any part of the system, though, this ideal will not survive contact with the messy reality of contemporary products. We need better strategies that take into account that (technological) products are not any longer produced by engineers only. Which is the obsolete assumption from days of yore still implicitly held by Scrum and similar traditional flavours of agile that keeps informing the model of the agile team. If we do not allow for strong interdependencies between parts of a complex product, the experience of the product as a whole is going to fall apart into a incoherent mess. Good product design requires a way more holistic perspective than good product engineering, because the encapsulation of parts and modules that enables engineering teams to work autonomously on these parts is next to impossible in design (i.e. if attempted it results in severe detoriation of product quality). Therefore we probably need to let go of the idea of the completely autonomous team. The only sensible autonomous entity is the product – and thus the org unit concerned with the product as a whole –, not the team. (Unless this team would build the whole product, of course – which IMHO is the hidden part of the assumptions the concept of the autonomous team is originally based on.)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.