Richard Veryard’s recent post on Emergent Architecture reminds me of the architectural meme “lines not boxes”. It’s a powerful approach that I followed explicitly in much of my time in enterprise architecture and web-centric development (“trust in open protocols and formats rather than closed technologies”) and I believe that it has value as a metaphor for process and organisational design too.
People aren’t boxes
Traditionally, we organise people by assigning them roles defined in terms of skills and tasks. Whilst some people seem to need the certainty that goes with this, it’s a practice I have actively resisted, whether as team member or manager. Putting people into boxes constrains opportunity, responsibility and creativity.
It seems to me more humane and more supportive of learning and growth if instead we make visible what needs to be done, define what good results looks like, maintain the minimum set of policies needed to ensure reliability, then create the space in which people can perform. And it can work for whole teams, where responsibility and creativity become manifested in self-organisation.
“Done” is only the start
Where there are different teams supporting different parts of a process, an over-emphasis on “what done looks like” has the effect of holding work back even when unfinished work could have considerable value downstream. In our “lines not boxes” metaphor, this is like defining the interchange formats to be used between systems but neglecting the communications protocols that carry them. An extreme example is the stage-gated waterfall approach to projects, where documents need not only to be completed but also reviewed and signed off before they may be acted upon in later project phases.
Under time pressure and faced with document-centric hurdles, smart teams learn to reach out and collaborate outside of the formal process. Smart organisations encourage this – making collaborative problem solving part of the process, building on successes rather than merely defending uneconomically against every eventuality (not to mention protecting every rear end). Once this is allowed to happen, it is my experience that artefacts start to get delivered in negotiated chunks and lead times take a significant turn for the better.
This is good news indeed: organisations build structures and introduce process overheads as they grow and rarely do they encourage flow. It is a relief to discover that bottom-up, flow-based approaches such as Kanban can prove effective even in the face of functional silos, not only helping teams to work more effectively within their functions but highlighting where a small investment in collaboration between silos will reap big dividends.