In the early days, we used to apply one size fits all methodology because we didn't know better (see figure 1, which is a system provided in a map form). We used to yo-yo between methods but in 2002, most of us in the open source world had gone "all agile" whilst the enterprise was mainly "all waterfall and all outsourcing". Under such a model, the IT organisation is one large hierarchical department and one attitude. Be warned, single methods fail to deal with evolution and tend to run into excessive change control cost overruns.
Figure 1 - circa 2002 - One size rules all, OK!
By 2004, in the open source world, we had learned that one size fits all didn't work. We had started to work towards the use of multiple methods. We knew agile was suitable in the early stages of evolution of an act but we also knew six sigma was better for more evolved activities. The foolhardy amongst us had started to organise by this "bimodal" fashion with groups such as common services or systems and development (see figure 2). Under such a model, the IT organisation is two groups in a hierarchy and two polar opposite (usually competing) attitudes - a bit more "bipolar" than anything else. Be warned, these structures tend to fail to hand over activities and lead to lack of industrialisation of common components, spaghetti junction and platform rewrites.
Figure 2 - circa 2004 - Bimodal rules all, OK!
By 2005 to early 2006, many of us had learned that the jump between the novel and the industrialised was too large. We needed a third group and a different set of methods, techniques, culture and attitudes to cope with this. Structures that took this into consideration started to appear, in some cases we formalised the "missing" group in our "bimodal" structures e.g. we went from development and common services to development, framework and common services. This three party system was also applicable across the entire business as a pioneer, settler and town planner structure (see figure 3). Under such a model, the IT organisation is three groups and three overlapping attitudes which can be made to work in concert through the use of theft (i.e. enforced evolution). Be warned, such three party structures contain strong hierarchies and still tend to create large groups creating communication and other issues.
Figure 3 - circa 2005 / 2006 - Trimodal rules all, OK!
By 2007 to 2009, we had started to learn that we needed to deliberately divide our organisations into self organising cell based structures e.g. a starfish model, two pizza models etc (see figure 4). It wasn't the case that we weren't doing this, it was more it had been a coincidence rather than a deliberate informed decision. Under such a model, the organisation is broken into many small groups but it has no specific attitude and no means of dealing with evolution. Be warned, whilst many of the communication and growth issues are better handled, the lack of means of managing evolution can create problems itself. The structure itself still has a hierarchy for management of the cells (often through fitness functions i.e. defined criteria for performance) but the cells themselves are autonomous.
Figure 4 - circa '07 to '09 - Cell based structure rules all, OK!
Sometime around 2012, a few of us had started to look at deliberately combining both cell based structures and using three party concepts to cope with attitude, heavily using techniques developed in the military to create more adaptive structures (see figure 5). Again, it wasn't the case we hadn't done this before, it was more a case that we didn't realise that we had been doing this and now needed to formalise it. Under such a model, the organisation is many small groups and three overlapping attitudes which can be made to work in concert through the use of theft (i.e. enforced evolution). The structure blends both attitude and aptitude with autonomous cells operating in a management hierarchy.
Figure 5 - circa 2012 - Adaptive structure rules all, OK!
By 2014 ... be warned, this process is ongoing. The above leads naturally to administrative structures (covering training, culture and attitude) along with what can be loosely described as "battle groups" formed to implement a line of business. The closest there is to something that remotely resembles this sort of structure can be found in military organisations which have had many hundreds of years to learn how to combine attitude, aptitude, hierarchy and autonomy into a useful structure. The majority of organisations are still at the very beginning of one department and one attitude. Once again, this idea of "pools" of resource is not new, it's more a case of formalising what had been achieved through experimentation but we had yet to realise the importance of it or why it worked at the time.
It might sound a bit odd but the formalisation of a method comes a long time after experimentation. That we had blindly fallen into a pioneer, settler and town planner structure using small teams back in 2005 is one of happy accident and fiddling. It took many years to realise what we had stumbled onto. Any illusions of great thought followed by implementation should be banished from the mind. This was always a case of fumbling in the dark and later on realising you had managed to accidentally pick up and put in your pocket a priceless treasure.
Three things to note ...
1) Don't think for one second anyone knows the best way of organising stuff in business - we don't. All we know are better ways than the past. Anyone who tells you they have the perfect way is talking horse.
2) Mapping an environment really helps with organisation or at least the exploration of the possible ways we might organise.
3) The use of mapping and high levels of situational awareness is a necessity for coping with evolution unless you have exceptionally talented people who understand that things evolve (i.e. they have their own mental models, can cope with inertia etc). Without extremely good situational awareness then I'd suggest you go for a cell based structure and hire rock star developers who work well with others.
