In the early days, we used to apply one size fits all methodology because we didn't know better (see figure 1). 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 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 and two polar opposite (usually competing) attitudes. Be warned, bimodal 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 and attitudes to cope with this. Structures that took this into consideration started to appear, in many cases we often 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 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 trimodal structures 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 learned that we needed to divide our organisations into self organising cell based structures e.g. a starfish model, two pizza models etc (see figure 4). Under such a model, the IT organisation is many small groups but 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.
Figure 4 - circa '07 to '09 - Cell based structure rules all, OK!
By 2012 to early 2013, a few of us had started to look at combining both cell based structures and trimodal concepts, heavily using techniques developed in the military to create more adaptive structures (see figure 5). Under such a model, the IT 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).
Figure 5 - circa 2012 / 2013 - 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. The majority of organisations are still at the very beginning of one department and one attitude.
Three things to note ...
1) Don't think for one second anyone knows the best way of organising stuff - 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.