Tonight I watched Fundamental Principles of Organisational Design with Doug Talbot, hosted by Cambridge Agile Exchange.
Doug has built a model of organisational design which he uses to assess status, identify targets for change, prioritise changes, and design interventions intended to achieve them. The model is based heavily on experimentation, deep reading, and hard-won experience in the broad area of software development practices, projects, and companies.
The model identifies nine areas of importance using a matrix of three columns concerned with creation (teams and structures, building the right thing, building the thing right) and three rows concerned with company behaviours (leadership and principles, policies and tools, day-to-day practices).
In some sense this is a meta model onto which others can be mapped. For instance, Scrum is located in the lower middle-right (building/practices) while sales incentive programs are middle left (teams/policies).
Doug notes that actions higher and to the left tend to carry more weight and have a higher potential for systemic change. This rings true when, for example, the top-left box would include leadership imposing structural alterations on the company.
In turn, a hierarchy for prioritising change activity emerges: start at the top left to have the best change of a change having a wider effect. Starting at the bottom right, say with increasing test automation by developers, will tend to have less global impact and be torpedoed by most other requirements from further left or higher up. ("The sales team have sold features we haven't built yet, leave the tests for now.")
The nine boxes are not independent and so it is important to set them up to be consistent with one another. Scrum is a good example here; there may well be tension and conflict if short-cycle iterative practices in software creation are jammed up against weighty annual management project budgeting and planning.
Whatever change you're planning, Doug says, use systems thinking to help work through the potential effects, and side-effects. Take small, coherent steps and review after each, correcting your course regularly as you get closer to the end goal and the desired effects.
I can honestly say that this was one of the most information-dense talks I've ever watched, and it was delivered in a comprehensive and comprehensible way. My notes and sketchnotes barely scratch the surface.
Comments
Post a Comment