How do agile teams deal with non-agile organizational structures?

Question

I've worked at the same employer my entire career (going on 13 years now). We're big and deal with sensitive data. Technology is not our product, but it helps support our main product.

I want to know how other large organizations are structured. Here we have silos of functional areas within IT. We have separate units responsible for Cloud Engineering, Identity Management, Application Lifecycle Management (maintain build servers and build definitions), Database Administrators, and Information Security. These separate areas all have their own separate priorities and marching orders.

I sit on a development scrum team. We represent the horizontal bar at the bottom. We execute project work that spans all the above functional areas. What this means for us is that when we want to execute a project we put in service request tickets to all these areas. Typically a new project will start with us requesting services through ~50 tickets. This is driving us developers nuts.

Is this how big companies do things? Is this probably more probable in companies where tech isn't their main business line? What alternative structures have you seen in your roles?

Answer 1

I have dealt with this in the past by using what I believe someone in the comments referred to as "shadow IT". If we need something done by one of the large lumbering orgs, we figure out a way to do it just well enough to get us what we need at the time, and plan to integrate the result from that external team at some point in the future.

For example, if we were to need to get a new VM to run a binary package server (nuget, etc.), but we know that can take a month, we would first set one up somewhere that we have control over. I think of that as prototyping, so that we can make sure it works before we make a potentially expensive request to IT. We make sure to implement things on our side so that we can easily switch the "real" server once it's in place.

You could do the same thing if you have a dependency on getting a database configured. Do it on a developer box for a while, then switch to the "real" one once it's available.

An advantage to this approach is that you can work at your own pace, and it sort of forces you to make sure the systems you design aren't heavily intertwined.

Answer 2

When you look at the common agile practices, with short iterations and maintaining a deployable codebase, there's actually a lot you can do. Essentially you keep things agile until you are ready to deploy. At that point you have to use whatever processes the Big Organization has in place to deliver.

All things that are required to support the big heavy process are tracked as tasks in your sprints. If there is paperwork that has to be supplied by a certain date, you add the task in the appropriate sprint and get the paperwork in.

The big issue is the cost of getting things done in the Big Organization. So you end up compensating by requesting resources much earlier than you can make use of them to be reasonably sure you can get them.

A release for us might look like this (each bullet a sprint or two):

• Sprint 1:
  • Request Infrastructure/Software required to be successful
  • Implement must-have features first
• Sprint 2: Pay down technical debt/more features
• Sprint 3: Fix bugs/regression tests
• Sprint 4: Submit release, plan for next release

This is just an example high level structure. Once we submit to the Big Organization (big CM), then that has its own life. We have a team that tracks that and is ready to perform the installation when the final approval comes.

Answer 3

You can be agile within your own department if you think that works for you. But when it comes to communicating with stakeholders and/or providers who will not play ball for whatever reason and you do not have upper management support to change this, there is little point in kicking that dead horse. Just go with the flow.

The ticket system, doing business-to-business within the same organisation, it may be deeply rooted. Your best bet may be to learn to understand the bureaucracy and make it work for you. Think ahead, put in requests early and ask for more than you expect to be needing.

It's not like nothing is possible without so called agile methods, agile should not be a goal just because it is all you know. That seemingly rigid system you have to deal with may have some unexpected possibilities. It may help asking first: "What do I have to do in order to get this or that?" Ask some of those folks you regard as representatives of the system you experience as frustrating. :-)