The story about the organisation is actually quite short due to their relatively simple design – it is all about teams
The ETS organisation shape iterated from the early start like this…
…to this
In all not that much difference between the two, with core components being:
- Solutions Leadership Forum – essentially an advisory board including co-opted representatives from teams outside development, including Security, Architecture, Technology Operations and Business Change
- Solutions Delivery Leadership – the ETS management team
- Solutions Governance – Guardians and coaches on key capabilities and standards such as Customer Experience, Integration, Development Method, Development Standards, Data Modelling, Security
- Architects & IT Security – who were in terms of organisation line outside ETS but essential contributors in the development eco-system
- Commercial Management & Support – providing vendor relationship management, contract management, sourcing & negotiation and project support (a very limited PMO function, called “Air Traffic Control” at one point, since the development teams were largely responsible for their own progress reporting)
- The Development teams – the main bulk of people, with both generic project teams, and some more specific functions for Security, Treasury systems, LiveFix and .Net (a developing technology practice area, Egg at that time being mainly UNIX based)
- Solutions Integrity – Guardians of quality and the overall integrity of live systems, managing the system test environments and working with the Egg Technology Operations to take systems into live operation
Move to a flex resourcing model
The major area of difference between the old Egg IT development model and the new Agile arrangement, was in the use of flex resourcing partners. In the old, more corporate structure, most of the people were permanent employees (especially after a temp-to-perm campaign on late 2001/early 2002), and so there was a high fixed cost.
During the Transformation, the resourcing model changed to a mix of the core permanent development teams, supported by partners who would provide both scale (up to 10x flex), and specialist skills (e..g, IT Security)
Partnership Model
As already discussed, partners were an important part of the resourcing mix, not just for cost reasons, and had some key expectations of them:
- Augment our capability
- Provide scale and flexibility
- Add breadth of expertise and skill (supplement and augment)
- Deepen pool of experience
- Challenge how we do things – feedback/mentor
- Are in context with Egg
This last point was especially important as it was essential for partners to be able to interact with and be like Egg People. Indeed, in order to maintain the level of Agility the Agile people criteria was used as part of the process by which partner people were evaluated for the suitability to work as part of the Egg agile teams.
As an aside, having a generally compatible culture was an absolute requirement for any aspiring Egg partner – the counter-case example being Midlands development firm, Zeda [also now departed this mortal coil, having closed in 2008], who being more used to Government and Police contracts mistakenly entertained the Egg team to a slap-up meal in the grand dining room of their vast Nottinghamshire mansion headquarters – and were unceremoniously dinged from the partner selection process for being so out of culture!
The diagram below lays the structure of the partnership model. At the core are the Egg people, who create unique solutions with high customer interaction and significant customer experience component, and the main generators of Egg IP and users of the latest (exciting) technologies; on-site off-site partners, who are like Egg People and supplement them; off-site partners who work on developments which have lower customer experience content, and more routine development that can be well specified in advance; and suppliers, who are not partners but arms-length vendors who provide commodity items and non-unique solutions.
Next…