Post #3528739

2026-04-13 07:08 UTC

Organisational Dysfunction of the Day Forming–storming–norming–performing Context: When putting together a new team or making big changes to an existing one, many recommend using Tuckman's "forming–storming–norming–performing" model to turn the team into a coherent and well-oiled unit. It begins with Forming (orientation), moves to Storming (conflict), progresses to Norming (cohesion), and ends with Performing (high productivity). Leaders are advised to manage this process closely as progress is not linear; teams may slip back to previous stages if new members join or goals shift. And conflict is regarded as necessary, as the "Storming" phase is essential to growth. OST explains: Tuckman's model only makes sense in an autocratic bureaucracy, especially those of the Theory X type, and aligns with Taylor's view that people must be managed to perform properly. This is classic DP1 thinking, whereas in the DP2 style, McGregor's Theory Y is the model, which assumes employees are self-motivated, enjoy work, and thrive under trust, empowerment, and autonomy. Grouped into self-managing groups that have designed themselves using Participative Design. No need for either storming or norming; the teams jump right to performing after forming. #OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Replies (1)

@trondhjort@hachyderm.io 2026-04-14 09:18

Organisational Dysfunction of the Day Analysis paralysis Context: An agile team is working on a rewrite of an existing legacy solution and feels that its success depends on the function parity it must have with the old one. They therefore end up doing a detailed and extensive analysis to account for as much as possible, even tracking down former developers to get details on some of the more obscure parts. And, even more problematic, they have to figure out which business people own which parts and who all their users are. This drags out in time, and although they have started the work, the extensible analysis prevents them from releasing anything. They are stuck. OST explains: Agile as a concept is pretty much designed to handle these kinds of situations; at least that is what many may think. It focuses on small increments and puts things in front of the users as soon as possible to tighten the feedback loop, so it makes sense. The thing, though, is that this is not product discovery, as it is an existing product with external product owners and users, both internal and external, and the team has no real product ownership of the app apart from the technical bits. They are not a self-managing product team as a DP2 style should be. Only when they have end-to-end ownership of the whole product, not just a part, can they take full responsibility and accountability so that they can manage it as they please. #OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Open ##3528737