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?

enter image description here

  • 1
    If your question is "are big, lumbering organizations really this big and lumbering," the answer is "yes." I currently work at a place where it takes multiple approvals and four months just to buy a computer. Commented Aug 12, 2019 at 15:36
  • Are orgs still doing this though? I thought one of the requirements of agile was having small autonomous teams? So how can you claim to do agile with a structure like this? Commented Aug 12, 2019 at 15:37
  • you do shadow IT
    – Ewan
    Commented Aug 12, 2019 at 15:37
  • That's a good question. Perhaps by working in a smaller department or team that is somewhat isolated from the juggernaut? Granted, not everything surrounding you is going to be agile, but that's what lead times are for. Commented Aug 12, 2019 at 15:39

3 Answers 3


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.

  • I like this approach but our management team is not crazy about the development team running off side hard ware and build / release pipelines. But ultimately we may have no better choice than to pursue this option again. Commented Aug 12, 2019 at 19:52
  • 4
    "Management teem is not crazy about..." Document the alternatives and the expected delivery times of each approach and ask them which they prefer. If the answer is "we expect magic" then look for a new employer. Commented Aug 12, 2019 at 21:00
  • 1
    yeah unfortunately we are expected to deliver magic Commented Aug 13, 2019 at 14:28

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.

  • thanks, although we might have to modify this schedule, we're seeing 2 months to get dev cloud resources is pretty normal for us. Commented Aug 12, 2019 at 19:49

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. :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.