Building Agility in Big Organizations

Big organizations usually have many large, moving pieces—functional departments like compliance, fraud, finance, privacy and so on. And these all serve important functions.

The organization designed itself so that those are separate departments and groups. You can think of them as services within the organization. They serve each other to a certain degree. They serve outside clients as well. And so when you’re doing some work, you need to get service from these other parts of the organization in order to decide how to proceed, whether it’s approvals, checks, information or audits.

But this can often be a barrier to a true Scrum implementation because, in most organizations, you can’t just restructure. So how do we organize services so that they work well together and the flow of work is effective?

Blow Up Big Organizations

Scrum’s answer to that question is to blow up the organization. It asks you to remove all dependencies. If you need an audit for something that a Scrum team is building, the audit needs to exist within the Scrum team somehow.

That just isn’t practical for many big organizations. Blowing up the organization means blowing everyone’s heads in the process. It’s just not feasible.

And it’s important to remember that that’s not necessarily a bad thing. These structures exist for a reason. We might not agree with it personally but there’s a history and effectiveness inherent to these departmental structures.

But if we want Scrum, we’re supposed to blow them up. And that’s extremely challenging in large organizations. But if it’s agility we’re looking for, we don’t necessarily have to blow them up. We just have to do some rethinking.

Think Small

Consider the rise of FinTech startups within the larger financial services industry. The big banks are looking at these new small, aggressive upstarts and they’re a bit afraid. And it’s mainly because of the way these companies are able to operate.

Think of an eight person startup: a bunch of buddies who get a little bit of funding together and decide to do something cool. They may have some dependencies, but mostly they just go for it. They do everything.

What the banks don’t realize is that, in order to be agile, ultimately they need to embrace that concept. You put a small group of people together and let them do anything. It’s really hard but it’s not impossible.

Large institutions have a very long history of skunkworks projects; the business unit that says “I don’t want to wait for that stupid I.T. department that’s going take six months to do this crap. I’m just gonna get a bunch of people together, some contractors and I’m just going to do it myself.” And they do. It happens all the time.

Change is Hard

But there’s this resistance on the part of bureaucrats and that resistance exists for a reason. It’s not a value judgment. It’s very understandable. But that’s kind of the mindset change that has to happen to get the highest levels of agility.

We structure big organizations differently when we improve agility. And it can be done very incrementally and gradually, which is what most of the big banks do. Sometimes, they try to go a bit faster but there’s always pushback on that.

Occasionally, especially if an organization is in crisis, they might make the change quickly and effectively. One of the earliest case studies of Scrum is from a company called Wild Card Systems. It was about 500 people at the time and they were on the verge of bankruptcy. So they had Ken Schwaber, one of the founders of Scrum, come in and talk to the executive leadership team on a Friday night to talk about what Scrum was and how it could help them.

Over the weekend, the executive leadership team continued to have these discussions and, on Monday morning, they sent out an announcement to all five hundred staff in all departments telling them that the company’s organizational chart was now history. Every single human became part of a Scrum team.  They started doing one-month sprints out of desperation. They did this radical restructuring, and it worked.

There are a few other case studies of this kind of “big bang” approach, but it only works in a situation of desperation. If your company is near the verge of bankruptcy and you really need to change and shake things up, the big bang actually works quite well. Better than everyone losing their jobs, right?

Shifting Big Organizations

But large organizations can still strive for agility without resorting to chaos, without blowing up the organization, and without being on the brink of collapse.

It comes with steady, incremental change and a fundamental shift in how the organization functions and how work flows through it.

This of course can still be a challenge, especially for middle management. Their purpose is that they’re responsible for the smooth functioning of the organization. Their training will be about creating processes and policies that create that smooth functioning and, therefore, they’ll be resistant to anything that’s disruptive or requires change.

To help those people become more agile, they need to understand that the new smooth function is change. It’s not always easy, but it’s a solved problem in the Agile community. The biggest change is a shift away from controlling the people to controlling the flow of work. Improve the flow of work, and actually changing what you’re working on becomes easier and easier and easier.

Kanban and Agility in Big Organizations

The Kanban Method is ideally suited to this challenge because it can be applied to any work environment and scaled to suit the needs of the organization. You can use Kanban at the team level. You can use Kanban to manage multiple teams and the dependencies between them. And, you can use Kanban at the portfolio level or enterprise level.

You can manage anything from tasks to long-term quarterly goals and beyond. You find blocked work when you use Kanban as a system. What is causing slowdowns in a system that’s moving? Where are things stuck? Are things stuck in some sort of dependency or handoff?

And by making the work visible and using Work in Progress limits, you’ll find that work moves quicker and you force teams to be more focused by not allowing them to be changing contexts. As focus is one of the principles of Scrum, Kanban enforces that focus within these limits. And when you have a limited amount of work flowing through a focused team environment, more work gets done, fewer things are left idling, and bottlenecks in the process become very obvious.

Big organizations can achieve real agility through a systematic process of evolutionary change. Kanban provides specific techniques such as STATIK to help your organization evolve.

Find out more about evolving your big organization with our Kanban Management Professional training program.

—

This article was adapted from a transcript of a recent Certified ScrumMaster class Mishkin taught in Toronto.

If you found this useful, please consider contributing with our “Value for Value” model.