Pool, POD or Team? Deciding DevOps related people structures – by Gunnar Menzel

But, if this is the case what is a Team and what is a Pool of people? Or are these constructs not available, possible or needed in a DevOps world? Assuming that there are still Pools of people and Teams of people, how do you decide on the best construct? What are the main criteria?

As I mentioned in my previous notes connecting people and taking down barriers, sometimes also referred to as “walls of confusion” between Developers (Dev) and Operational Staff (Ops) is one key objective of DevOps.

The typical solution lifecycle is a bit like a relay race [see 1 to 6 for more detail] – someone takes a baton that has been handed over to cover a part of the entire solution lifecycle, each losing time, impacting quality as well as getting further away from the actual “real” business

To speed up the entire process and to ensure that quality is being increased, a DevOps approach is suggesting to establish joint Pod’s – so “a people structure” that includes all people capabilities to own and cover all inception, construction and operate related aspects. This is certainly how organisations like Spotify, Netflix and amazon are organised.

Yet, for most organisations it is impossible to move from today’s silo’ed and tower based model to a 100% Pod based DevOps organisational structure in one go. Nor is a Pod the only possible structure for an IT organisation to speed up, increase quality and value for money – there will still be teams of people as well as pools of people.

Team:

• A group of people with a full set of complementary skills, working together to achieve a certain outcome typically not covering an end2end accountability
• The objective or the team is typically outcome based

Pool:

• A group of people with the same skillset executing the same activities
• Outcomes are activity and not outcome based

POD:

• A POD are cross-functional and multidisciplinary team that connects design, build and run in order to deliver the right customer products.
• PODs are typically formed by up to 10 people that cover business, application and infrastructure knowledge as well as key personality skills (see here)

The key decision points when deciding what structure to follow are typically related to the following questions:

• Is/are the objective(s) outcome or activity based
• Is there a high level of change?
• Do we have the number of people that can be placed into a POD?
• Are there any location related restrictions?
• Is customer close proximity needed?
• What makes best sense to drive speed, quality and value for money?

Summary
In reality organisations will have to find their own blueprint from an organisational perspective (see Matthew’s blog in [7]), as what works for one might not work for others. Also, changing and defining a new or different organisational blueprint must not be taken lightly – it’s a major change and requires close and detail considerations.

And remember: Back in 1967 Melvin Conway said:” Organizations which designs solutions are constrained to produce designs that mirrors their organizational and communication structure”

Thanks for Reading.

About the Author: Gunnar Menzel has been an IT professional for over 27 years and is VP and Chief Architect Officer for Capgemini’s Cloud Infrastructure Business His main focus is business-enabling technology transformation & innovation.

Further Reading: [1] https://www.linkedin.com/pulse/devops-what-best-organizational-structure-me-gunnar-menzel [2] Step-by-step approach to reach your DevOps Target Operating Model [3] Agile, DevOps & Lean Unlocked [4] DevOps; a simple answer to a simple question? [5] DevOps – Don’t be left behind [6] DevOps – The Future of Application Lifecycle Automation / Part 6 [7] Matthew Skelton, October 2012, https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/

Culled from Capgemini: “Pool, POD or Team? Deciding DevOps related people structures”  by Gunnar Menzel