A different kind of Scaling problem

In the Lean Agile Open on April 28th, one of the sessions was on “scaling.”

And it reminded me that people use the word scaling to mean quite different things.  And often I or we do not think about this.  But each of the different meanings of Scaling is important, at least in some sense.  And each presents different problems or opportunities.

As many wise people tell us, if you define the problem well, then the solution is more likely to fit the problem and be useful.

So, define your problem clearly.

This is similar to the advice: “Begin with the end in mind.” (Covey) Also phrased as: Ask yourself what your real goals are.

OK.  So….

• One meaning (1) of scaling is that we have 3 or more Scrum Teams (or teams, anyway) working together to produce one product, or fulfill one vision.  This can be drawn this way:

 

 

• Another definition (2) of scaling is that we have a big group of people (let’s use 80 people as an example) in an Innovation group.

That is, we have business and technology people — working colaboratively — who can do innovation (maybe specifically, software development).  And scaling is how we “organize” those people.  So, below we have a “concept” drawing of “organize”.

 

 

Let me emphasize that “organize” has several possible meanings. It might mean: form into teams, set up reporting structures, establish departments and managers, relationship diagrams, processes and procedures, etc.  So, “organize” might be many things or very different things.  And the simple purpose of organizing in this case would be to achieve the purposes of that group better. One might say overall: to do innovation more effectively.

Let’s imagine that in the 80 people at least a few teams are doing “agile” (a bit).  But that each team is working essentially independently on a different project.

So, some people want to call organizing that group “Agile at Scale”.  And, thus, they get to the word “scaling.”

I hope it is now obvious that these two situations represent two very different ideas or problems.  Very different.  Although they have some similarities.

Let’s repeat a bit and remind ourselves of a few basics.

1. When working with others, it is always useful to have a shared understanding of the words and concepts you use.
2. Define the problem carefully.
3. Think about your goals.  (I think the goals in these cases are notably different, although perhaps roughly similar.)

Now let’s look more closely at the second problem: organizing 80 people.

My first suggestion is to prioritize.

For example, imagine you are a manager. You have just joined this company.  You have 80 people reporting to you in an Innovation group.  They are already organized.  They have a “culture” and a “way of doing things” officially or unofficially (usually both) that includes many things.

A typical situation is that your goal is to “show results” or “make an impact”.  Typically the company has some normal business goals.  Let’s imagine they are these (and they can roughly be measured or ‘sensed’):

• More innovation per quarter
• Contribution to increased firm revenue
• Contribution to reduced cost
• Faster deliveries (aka, being able to adjust more rapidly to changes in market conditions)
• Higher customer satisfaction

For now, we won’t quibble further about these (the wording, the relative priority, etc).

So, where do you start?

As I said, I think you have to prioritize.  In my experience, everything can be improved.  But not everything needs improvement as much. Nor will each yield as much benefit.  Nor will each thing cost as much to “fix” or change.

As one of my friends used to say: Understand the whole business-system.  Develop some pictures and concepts and drawings of how it currently works.  This probably should also include values and principles.  This probably is done best with a small group of people.

Then, probably again with a small group, think about where the big group (the 80) could be in 6 months to 1 year.  You might also think longer term, toward a yet-more-improved world.  As long as you do not do that for too long, that might also be useful.  But some people want to think too much, whereas they would do better to learn from acting, learn from the real world.

The Lean idea of “go to the Gemba” is relevant about now.  Get in the trenches and try to see what is really going on and what the most pressing problems are.

It is common at this point to have a “Future State” diagram and a “Current State” diagram.  And, as many of you can expect, you want to then describe the actions or changes needed to move toward the Future State.

The typical thing is that you are trying to get the best ROI for the actions or changes. The most benefit for the least “work” or investment.  And you do this by prioritizing your problems. Or that’s how we often put it. (There is more complexity here.)

Everything I have described in the prior 6 paragraphs has NOTHING to do with Agile or Scrum per se.  Or, it is not specific to Agile or Scrum.  These are general ideas about solving business problems and how to work as a manager.

So, is best thing to do next to improve things?

From my experience, I do not have a strong opinion.  It might be. It might not be.  And many factors.  Frankly, as a community, we do not have much data to support any conclusion.  As a manager, you could do many things, and maybe all could bring a positive impact.  The question is: will you do the best things in the best order?   And, as far as I know, no one knows the answer to this, although there are many with passionate responses.

Here are some of the problems when people give passionate responses (such as “You must do X first!” or “Definitely do not do Y first”).

• Confirmation bias
• Poor use of logic
• Insufficient data

There are others but that is enough.

A couple of comments. I continue to be surprised how often I use logic poorly (or not at all), so please do not think I am blaming only you.  I think it is a general human problem, and I think none of us was educated well enough about the uses of logic.

But I think the biggest problem is that it is so easy to feel (after so much frustration) that if something works once or twice, it must be “the solution.”  And really, only if the solution is repeatable by many people in many situations (maybe not all) can we start to think it is a good general solution. Cf. the scientific method.

My simple suggestion for the new manager of 80 people is this.  Identify a list of “stupid”.  Prioritize it.  And fix the stupidest thing first.  (Well, as I said, in ROI order mostly.)

Are there risks in putting it the way I just did?  Yes!  One big risk risk is that smart people may feel you called them stupid and it will turn them off.  So, obviously, do not use the words that way.

So, why do I put it that way?  Because I think K.I.S.S is so important, even with smart people.  We must keep it simple to get effective action.  And we must be willing to admit we were styupid, or so it appears 20-20 hindsight.  And that is true for all of us.  We might say: there are now no sacred cows.  Or “we question everything”.  So, the word stupid is not used in a mean way about people, but, yes, in a mean way about “the biggest problem”.  We are not putting up with it, and it must be fixed quickly.

Let’s now turn to two possible solutions, as examples to help us see a broader idea.

One is “implement agile teams across the 80 people”.  Or something similar, and it is often expressed roughly that way, even though really it is notably more complex.  In the typical case, I think this is a good idea.  It is hard to do well, but it could help, and it has helped. I think it has never hurt.

Another solution is “change the incentives for the middle managers”.  That could be many different things, such as how they earn higher pay, which metrics you use for them, how people are organized, how some basic processes work, etc.  [So, I do not mean mainly “change the Incentive Program” (if your company had one).]

[Note: There could be a wide range of alternate “courses of action”. I picked these two as examples.]

{Note: These two solutions are not mutually exclusive. The only question now might be “which to do first.”]

And I could imagine, from my experience, that this one could be very useful too.

Those 6-10 middle managers (or whatever they are called) have a lot of knowledge and influence.  This kind of change could have a big impact quickly.  It might be easier to implement.  And it might have nothing to do with implementing agile or increasing agile or making “agile” better. [One could imagine that when you arrived, they were already doing some “agile”, typically not very well.  So, the course of action here is that we do not try first to improve or expand agile, but simply to change the middle managers. Or things around middle management.]

Between these two ((a) more or better agile and (b) fix middle managers) which is the better one to do first?

As I said, I do not know. And I think we do not know.  And the answer could likely vary by situation.

There is much more to say, but let’s save most for another post(s).

But let’s take one more step. Imagine you decide “fix middle managers” is the best first step.  AND, some of your teams also want to change, improve or expand “agile” at the same time.  Should you resist or tamp down that activity?  My suggestion is that you let it happen and lightly (low cost) support it.  Remain focused on your main initiative; get it done.  And explain that you will support agile more later. (Or, that’s my basic bias from my many experiences.)

 

« « More on the Dedicated Agile Champion role || The ScrumButt Test – Update » »