A couple of weeks ago I saw an exchange on Twitter about constraints, which spurred me on to write this post that I’d been mulling over for a while. I’d been thinking about self-organising teams, and what constraints are needed to help direct their self-organising efforts. Then I noticed this conversation on Twitter:
@ourfounder (Jim Benson): Professionals hate constraints. Often people we think are lazy or angry have simply given up on the system. #agile #kanban
Retweeted by @flowchainsensei (Bob Marshall)
@nrcantor (Noah Cantor) : @flowchainsensei @ourfounder Whose constraints? @jasonfried says ‘Creativity loves constraint’ in #Rework. YMMV?
@ourfounder: minimal constraints are loved. Beyond that is undue burden.
@flowchainsensei: Two meanings for “constraint”?
@nrcantor: That’s what I was wondering.
@flowchainsensei: Violent constraints vs nonviolent constraints?
@nrcantor: Boss imposed vs circumstantially imposed?
@flowchainsensei: Something like that
All those involved in this exchange seem to agree that ‘constraints’ are not always a burden, they can be a positive influence. But what makes a positive constraint? Are acceptable constraints minimal, non-violent, circumstantial, or something else?
There’s a fair amount of blog writing on the ‘myths’ of self-organising teams; the most common myth being that self-organising teams need no management, they just get on with their jobs without external direction. Countering that myth, Jeffrey Palermo points out that “Self-organisation does not require self-directing”. “A team that is self-directing will likely not accomplish anything significant. A software team within a company cannot make every decision. It can only make certain ones. For instance, what market segment to compete in is a decision that has likely already been made; however, what unit testing framework to use might be up to them.“
The point Jeffrey Palermo doesn’t make, and nor did the tweeters @ourfounder, @flowchainsensei and @nrcantor, is the distinction between constraints on ‘what’ the team is trying to do, and constraints on ‘how’ the team should do it. Which market segment to compete in is a ‘What?’ constraint. Which unit testing framework to use is ‘How?’. I suggest that some constraints on ‘What’ to do are essential for a team to achieve cohesion and a sense of purpose. ‘How?’ constraints, on the other hand, are the ones that are likely to chafe and irritate smart, capable team members. This is especially true where the constraint relates to business process. Many businesses have ‘how?’ constraints relating to technology choice, e.g. for compatibility with existing systems. ‘How?’ constraints relating to process, however, must demonstrate their benefits to the team, as well as to the wider business, or teams will resist them.
If you’re familiar with Tom Gilb‘s work, you may have heard him talk about the distinction between ‘Requirements’ and ‘Design’. In Gilb’s view, a function requirement only qualifies as a ‘requirement’ if it does what the business exists to do. A cornerstone of a bank’s business model (if we can leave cynicism aside!) is to lend money and charge interest. “Calculate interest” is justified as a requirement. Anything less fundamental than that is a design decision. Requirements and Design should be clearly separated, but they are often confused and mistaken for one another. Many people try to dive into design too soon, before top-level requirements are clearly understood. My distinction between ‘What’ and ‘How’ constraints corresponds with Tom Gilb’s Requirements and Design definitions. ‘What’ to develop is a requirement; ‘how’ to develop it is design.
Following Gilb’s logic, decisions about ‘what’ a business is trying to do should be taken by the business leaders, and provided as requirements (aka constraints) to development teams. Those are healthy constraints, without which the team has no purchase and will probably struggle to achieve a shared understanding of their goal. Decisions about ‘how’ to meet those requirements should be devolved to teams as far as possible. Going back to that Twitter conversation: I’d suggest that excessive ‘how’ constraints are the kind that @ourfounder‘s professionals hate.