There seems to be a buzz around scaling agile around lately. A couple of weeks ago I saw a tweet from Gabrielle Benefield that made me think.

Why is everyone hell bent on scaling Agile when they have trouble even getting one team going?

That question reminded me about a lesson I learned from Don Gause, and Jerry Weinberg in Are Your Lights On? What’s the problem? Who has the problem? And who should fix it? Let’s see.

What’s the problem?

A problem is the difference between a perceived state, and a desired state. In order to solve that problem, we may work on the state, the desire, or the perceiving. That’s the bottom line I got from the aforementioned book.

One question to ask in regards to the underlying problem folks try to solve when talking about scaling is what’s the problem they are trying to solve. Stick long enough with corporations, and some of the answers you receive for this are “we want to deliver faster”, “we want to deliver better quality”, and “we want to be more flexible”. These are all valid answers for the desired state.

As consultant, when entering a new client, one thing you try to find is has to do with the currently perceived state. The answer to that question lies in how good the client can currently perceive the situation. As an outside consultant you can often easily make the customer aware of some things he doesn’t see. That influences the perception of the current state in the organization. So to speak, as consultant us consultants help the organization perceive other things in their current reality, and thereby maybe shift their problem.

When it comes to agility, and the above quote from Gabrielle Benefield, the question probably should shift towards “are we really doing good in one team?”, “where are the problems with our current market situation?”, and “how can we deliver faster?” While trying to answer those questions, you might find out that you perceive your current situation differently, and scaling with 200 teams is not necessary, since 2 teams already can deliver lots of business functionality, while the other 198 teams can focus on conquering new markets.

What some of the fuzz around scaling agile right now is all about, is to shift the client’s perception regarding the desired state without challenging the perception of the current, and what causes some of the problems they are currently perceiving. I think rather than providing a solution to a perceived problem, or drawing a picture of a desired future state, we would be way better off helping the enterprises around to take a step back, and help them evaluate what they really want to do, and then solve that.

Who has the problem?

This already touches the field of who has the problem. When we talk about creating a desired state, my impression is that we try to impose a solution on all the large companies out there. I think that’s wrong because that focuses on the consultants having the problem of not being able to reach out to the large enterprises. So, all that a solution consisting of pre-defined practices solves lies in the utilization of the consultancy selling that solution.

In my current perception, that larger companies out there currently face that small startups can outperform them easily, and deliver better solutions more quickly. So, the one who really has the problem is the enterprise organization that is going to become extinct unless it changes something.

When talking about agility, and business agility in special, we should help those larger corporations to the agility that helps them outperform the competition. That probably means that we should engage with our clients, see their reality, and help them either shift their perceptions, or help them to really solve the problem.

Who should fix it?

You may have noticed I already shifted into this question a bit in the past sections. So, let’s focus on who should fix the problem of too few business agility, being too slow on the market, and so on.

What I perceive happening right now is this: a consultancy has invested large amounts of money in becoming certified for a particular method. They enter a new client, and sell that solution to them – because of sunken costs for their investment, and maybe because that’s the only thing they know.

That would mean that we really try to impose a solution on the client that has the problem.

With large organizations, as an outside consultant, I learned that I have limited influence on the folks. I don’t have budget responsibility for all the people involved. I don’t have payment influence for individual people. The only thing I can do lies in a servant leader role. I can help influence some people, but I can’t really put pressure on them – and that’s good.

Who’s the one that can effectively re-shape the current organization? Who’s the one that can effectively change team structures in the organization? Who’s the one that can create new teams from the existing structure? Usually it’s not the consultant that can directly do that, but the manager of the organization.

When introducing a new methodology, we shouldn’t rely too heavily on the solutions that outside consultants provide to us with their blueprints, practices, and direct actions. Rather us consultants should clarify how much we and the client will be able to agree, and have a 50:50 influence on the proposed solutions. I don’t see that the ivory tower blueprint solutions that consultants come up with will work out if we don’t make sure to connect with the ones that really have an influence on the organizational structure. And I think that they also shouldn’t delegate all their hard-earned influence onto us, the folks that have the fewest clue about the inner working of the organization at hand. We should do this together.

More Honest

When it comes to scaling agile, I think we should be more honest when helping others to implement a solution that should work for them. That includes understanding their reality, helping them see things they don’t see, and then help them to work on the resulting problems. When it comes to change management, there is still a bunch of stuff us agile consultant can work from change agents, and it’s better to join forces with our client rather than imposing our pre-fit solution, just because we thought about it. Thereby, we might eventually be able to help our clients – I hope that’s the problem that consultancies at large really try to solve.