Eric Ries' lean movement is picking up steam and is really extending agile software development to the wider organisation. Its interesting to see over time how some organisations have changed in a more competitive market in recent times. REA Group, the company I work for, have made some significant changes over the past few years including:

• Adopted the agile software delivery process throughout IT replacing the traditional waterfall method
• Slided and diced 'development / delivery' resources in different ways to provide accountability to the segment of the business they are working on
• Adopted a more collaborative approach between IT Operations and IT development/delivery

The traditional That being said, there are many companies that arrange teams like

• Development - the people making the code
• QA - the people writing and executing automated testing
• Operations - the people that take the code and run it at scale 
• Network / security - the people that own infrastructure networking 
• DBA - the people that performance tune and own databases

using dedicated infrastructure. The start upIn contrast a new start-up website may have a very small team of

• Development doing QA and 'deployment' 

using a public cloud service like heroku, dotcloud, Rackspace Cloud or Amazon Web Services.

Now lets assume that start-up is successful and needs to scale fast to complete in the market, would they scale by subdividing teams in the 'traditional model' or use an alternate model that fosters being 'lean' and 'agile'? I actually think the team structure would be

• Small infrastructure team - providing infrastructure services like 
  • spinning up new (disposable) instances
  • a monitoring / alerting service / framework
  • a standard deployment tooling service / framework
• Large delivery team based around a service. The team would consist of 
  • Amazing coders on the technology
  • A QA consultant to assist those amazing coders with the ability to write test coverage and automated testing
  • A operations consultant that can either take the infrastructure tooling and extend it to the project/service  - or work the the 'amazing coders' to enable them to build and deploy systems at scale

So where would the 'DBA' fit? This is where I'm not too sure. I would think they would fit into an 'infrastructure' team - providing  a PaaS database service that the delivery teams would hook into when they needed a whatever datastore.
My thoughtsI think there are some interesting times ahead for traditional model IT organisations and having teams based around development and operations just will not work. Operations can no longer afford to be a 'lights running' type gig. It has to be an enabler of infrastructure services to the wider IT community. "I wont be the 'pager' person, ill provide you with a monitoring and alerting system that you can hook into when you build your 'lean' minimal viable product".  Your thoughtsI would be interested hearing about organisational structure and role changes with the boom of cloud, agile and lean. How do you think an IT organisation should be structured to provide the best culture, environment and challenges while also delivering significant business value?