Normalize: to make normal, especially to cause to conform to a standard or norm.
Denormalize: the process of attempting to optimize the performance of a database by adding redundant data.
Interesting words. Heartfelt comments on denormalizing versus normalizing your data, provoked by a Ludicorper's presentation on Flickr: "Normalised data is for sissies". Lots of discussion there on technical best practice, but only a little on that other stuff: the people. Well, we know nothing about database design, but Matt Webb's suggestion that (de-)normalizing can be a socially-driven choice - as much as it is a technically-driven one ("half of software architecture is making sure that somebody can fix a bug in a hurry, add features without breaking it, and be lazy without doing the wrong thing") - sounds right given that so much of everything else in Getting Things Made is social.
Alistair Cockburn, following in the footsteps of Brooks, DeMarco et al, has been Characterizing people as non-linear, first-order components in software development since 1999, advocating picking the methodology that fits your team, or at least allow the nature of your team (as well as the project) to influence which method into practice, and how. Better that than forcing your team to adopt a process that won't work for them. No one Capital-M Methodology fits.
But Frederick Taylor lives on in many offices, where the managers want the men to be interchangable, and there is often a constant effort to "normalize"* the team (Tuckman's "forming/storming/performing/norming" model of team development names this explicitly perhaps): to pursue replacability, repeatability, predictability and directability (often at the cost of innovation and motivation - DeMarco's Slack is good on this), to remove redundancy by making redundancies...
... Yes, that's probably a totally different sense of "normalization". This organisation-as-database trope is worn, exhausted, redundant.
Comments