“sprint based mini-IT teams” is the future IT structure

The classical IT structure that helps us to go through the last 20 years challenges is not helpful anymore. Silos of computing, storage, developers, operation, support and network engineers won’t help us to successfully address today’s and future challenges.


Business is being changed by disruptive technologies. As an IT organization, which needs to support business operation, we can’t create or predict the future technologies and business needs that the future ( and Darwin rules) will introduce us. What we can do is making sure that we are building platforms and IT organization that will enable decision makers to change business processes or practices fast, really fast.

The financial future is unpredictable as well, thus demanding agile, lean and dynamic IT organization that can support the business in the most cost efficient way.

To address the described challenges we, as IT leaders, need to stay away from the classical IT structure. The future IT structure should be build on the principle of one IT team with one common goal. The classical silos needed to be break into hybrid teams build from different IT specialist with different skill sets. I like to call them mini-IT, since each team is a fully functional IT group ( including infrastructure, networking, operation, development and support capabilities). Mini-IT teams have the spirit of a small IT group supporting fast growing companies. In such teams any task can be done by anyone. These teams are all about fast and efficient execution of IT tasks, that needed to support fast pace business needs.


The drawback of Mini-IT groups is that over time each group become totally separated and distinct from other groups. Such an environment is obviously not a good enabler of one big IT group. To deal with this challenge the Mini-IT groups are actually “sprint based mini-IT” groups. Each sprint mini-IT group is created every sprint and staffed with different IT professionals, based on the need of the sprint. Actually we have two different structures. HR structure and sprint structure that could be different every sprint. This approach drives people from different IT domains to work with all other members of the IT group, thus creating one IT team.

Sprint based mini-IT groups have other benefits than creating flexible and fast pace IT groups such as decreasing finger pointing inside IT and increase service quality and customer satisfaction.

In this blog I’m going to share the success stories and challenges that we experience through the transition from classical IT structure to sprint based mini-IT structure.

About friedkin companies CIO

Friedkin Companies CIO
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

7 Responses to “sprint based mini-IT teams” is the future IT structure

  1. Kevin Behr says:

    you may want to explore the concept of ephemeral crews and how they can function in socio-techical systems. I would argue the classic functional org has never worked hence where we are today.

    You will need a strong strategy deployment discipline (see Art of Action) for a great primer on directed opportunism. You will need this to inform your self organizing crews.

    also consider expanding your insights around cognitive anthropology and cynefin to better work with the humans in your complex adaptive system. Also sprints can be effective but consider building a flow based system that is flow efficient all of the time not just in sprints.

    my .02


    Kevin Behr

  2. Funnily enough I see the same data but some up with the opposite conclusions – I think sprint-based mini-teams are a terrible idea and stable, product-oriented teams are the way to go, particularly if, as Kevin says above, you are optimising for flow.

    My personal preference is articulated well by Alan Kelly and Steve Smith where they talk about “#NoProjects” here – http://allankelly.blogspot.co.uk/2013/10/noprojects-why-projects-dont-make-sense.html and here – http://allankelly.blogspot.co.uk/2013/10/beyond-projects-beyond-noprojects.html

    The overhead of forming teams and reaching a level of productivity is always massively underestimated – after all, we are all just “resources” to be allocated to “projects” and we are supposed to have perfect clarity of objectives, clear lines of communication and all required resources to complete the project from day 1, right? Tuckman (1965) pointed in the right direction but it appears that nearly 50 years later the message still hasn’t gotten through – http://www.mindtools.com/pages/article/newLDR_86.htm

    Kevin’s use of the phrase “self-organizing crews” makes me nervous though – “self-managing to achieve an objective” I agree with, but if “self-organizing” means that “the team picks its own members” then I see several problems with that:

    (1) it assumes that all the team members know the abilities of all the other team members and can make rational choices about who should staff the team to achieve the given objective

    (2) people aren’t rational, they’re tribal, so #1 is highly unlikely to occur.

    • I might be wrong or right, but if I won’t try it none of us will know it for sure 🙂

      I know one thing for sure, our current IT practice is not the one that can support future businesses. we need to be bold enough to try new solutions.

  3. DaRe says:

    Isn’t teams temporarily setup for a task exactly what we did in the 90:th? I’ve been in so many definitely functioning organizations were teams are short lived and just setup for a specific task and then reformed. Yes it works, but after seeing what long lasting teams can do, I will never go back without a fight. 🙂 Thinking about the times I have seen teams truly evolving into efficient fighting machines brings tears to my eye and it is clear to me that to reach there, time together in stable teams with directed team building efforts are needed but so worth it.

    • I don’t think that we have teams composed from Dev and Ops in the 90 :-). What I’m trying to build is one big IT team with mini IT teams. From management perspective teams have advantages and disadvantages. Coming from special forces back ground I’m a believer of one units with dynamic ad-hoc teams.

  4. Pingback: Implementing DevOps (non-hierarchical structure) within hierarchical organization | The Friedkin Group CIO

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s