While Nigel has you thinking about how you govern your agile projects I want you to spend some time thinking about a man by the name of Melvin Conway. In 1968 he made this observation:
“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
I often paraphrase this as:
“Your system’s architecture will match your org chart”
Even with the flattest, non-hierarchical org structure the way you organise your teams, even the way they are physically situated leaves a lasting finger print on any technology platforms you build. If you have three teams which are fairly autonomously building a large system, don’t be surprised to find three different applications communicating via a series of APIs. If you have a geographically distributed team, expect to find highly modularised systems with lots of code focused on decoupling. If you have a large monolithic development team you’ll find a large monolithic application.
This is especially true of agile projects where decisions about your platforms are not taken by a command and control style group of enterprise architects but instead handed to the builders of individual components. Often when talking about org design I hear something along the lines of this … “There is no perfect org structure, so this one will do” … while I think the first part is true, take a moment to think if the org structure is going to breed a sustainable platform architecture before you decide if it will do.
“Any darn fool can make something complex; it takes a genius to make something simple.” – Albert Einstein.