How to avoid the local optimization problem when coaching at the team level

A recent Twitter discussion inspired me to re-think a few things about how to effect meaningful change at the organizational level and the team level. (Funny how Twitter seems to serve that sort of purpose, which may be above and beyond the usage pattern its creators envisioned initially. But I digress.)

During the first few years I worked in the general area of process improvement, I functioned mainly as an “agile” coach at the team level. Through those experiences I tried to understand how each method or practice worked mechanically as well as applying the “agile” values and principles on the cultural dimension, and started to learn how psychology and organizational sociology play into software development practices and delivery methods.

It didn’t take long for me to realize that the way an individual development team goes about its work actually has relatively little impact on the effectiveness of the end-to-end delivery process. I continued to look for the key leverage points in organizations that might yield the greatest positive effect for process improvement. I often found myself venturing far afield from the teams I had been engaged to coach, because time and time again I discovered that the real problems with delivery lay well outside the team’s jurisdiction.

Usually, the core problems were upstream from the development area. Poor outcomes had already been guaranteed before the development teams ever heard of any given project. Problems typically stem from the connecting tissue (or lack thereof) between strategic planning and IT portfolio management. Other high-impact issues include the administrative structure of the organization, its standard procedures, budgeting process, employee recognition and rewards program, management style, and formal job descriptions. No technical practices a software development team might employ will affect any of that. Only holistic organizational change can address issues at that level.

Strengthen the weakest link, sure; but what’s the chain?

I came to see that technical coaching at the team level was just one piece of the puzzle. It’s no less important than any other piece, but it is by no means the entire puzzle. I sometimes use the metaphor of the chain to describe this. We can’t strengthen a chain by strengthening its second-weakest link. We can only strengthen a chain by strengthening its weakest link. In software delivery processes, the development team is very rarely the weakest link in the chain. Therefore, if we want to effect change at organization-wide scope, software development teams are not the logical starting point.

What surprised me in the recent Twitter discussion was that agilists tend not to see a development team as a single link in a chain. Instead, they see specific technical practices as links (actually, they don’t like the “chain” thing at all; I’m just mapping the concept to the metaphor for discussion purposes). So, when I was looking at a chain of activities leading to delivery of a solution, agilists were looking at a set of practices leading to development of a chunk of software. We thought we were arguing, but in fact we were simply talking about two different things.

The notion of strengthening the weakest link in a chain is consistent with the Theory of Constraints. The PDCA-like process improvement cycle ToC defines, the Five Focusing Steps, begins by identifying the constraint, which is the weakest link. When I look at delivery processes in companies, I try to identify the constraint, too. I haven’t yet seen a case when it was the software development area.

Local and global optimization

The dynamics of local vs. global optimization is a related aspect of the lean school of thought that has influenced my approach to organizational improvement and team coaching. It seems that to optimize the whole we have to relax some of the parts. Any system can only operate at the capacity of its constraint. When the development team is not the constraint, it makes no sense to increase the team’s delivery capacity in isolation. Instead, it makes sense to throttle the team’s rate of delivery to match the capacity of the system’s constraint, whatever that may be. A key observation (one that I think many agilists either overlook or just haven’t grasped yet) is that when we optimize locally, we simultaneously sub-optimize globally. There is an inverse relationship between local and global optimization.

I often get the impression from agilists that they believe any localized improvement will serve as a positive example to others in the organization, inspiring them to pursue improvements as well. They hope a better organization will emerge as the net result of all these small improvement efforts. They use the metaphor of viral infections to describe this pattern of organizational improvement. The problem is that all such one-off improvements will create local optima. End-to-end delivery effectiveness will inevitably suffer.

I had been getting into some heated discussions with agilists about the wisdom of ramping up individual teams to a level of performance their organizations could not match. As far as I could see, that would only generate more and more inventory that could not be consumed. Was this not obvious? Why was this not obvious? Agilists would repeat that any improvement that was possible ought to be undertaken. Surely, any improvement whatsoever must be better than the status quo. What were they overlooking? What was I overlooking?

Scope of improvement efforts

In discussions, agilists would agree in principle that we ought to strengthen the weakest link in the chain. Therefore, they reasoned, if the team were doing a poor job of test-driven development, then test-driven development was the weakest link. If they were doing a poor job of continuous integration, then continuous integration was the weakest link. That’s perfectly sensible if the universe consists of the activities carried out by a team.

I was looking at a different level of detail. I was thinking of all the activities at the team level collectively as a single piece of the puzzle. Since that has far less impact on delivery effectiveness than issues like strategic planning, budgeting, organizational structure, and portfolio management, it just didn’t make sense to begin there. Reminds me a bit of fractals; same pattern occurring at multiple levels of detail. I was looking at a different level of detail than they, and neither of us realized it because we were observing the same pattern.

Epiphany

In hindsight what woke me up were some of the tweets from Ron Jeffries, one of the founders of the “agile” movement.

• Read the manifesto. THOSE are the things in Agile purview. random inefficiency? not so much.
• stakeholder issue not in Agile purview IMO
• we wrote [the Agile Manifesto] about software. it clearly applies beyond software. it is not all solutions to all problems

I had been getting the wrong message from the “agile” community’s frequent use of the term, “agile organization.” It’s my fault; I misunderstood what they were getting at. I took the word “organization” too literally. They were talking about applying the values and principles expressed in the Agile Manifesto more broadly than just to software development. But when push comes to shove, most aren’t interested in addressing larger organizational issues in their own consulting, training, and coaching work. They choose to focus at the team level.

That’s neither good nor bad; it’s a choice of professional focus. When they say “agile” values and principles can be applied more broadly, they aren’t volunteering to take on organizational change issues outside the scope of software development. They’re only suggesting that other people are free to apply the same values and principles, if they wish. That point really clarifies for me the reason they prefer to wait for “emergence” than to “drive change.” Issues beyond the scope of software development as such are, in a word, random, where “random” means “not within our purview” or “not interesting to us.”

There is another axis on which agilists and I have been making different assumptions. I learned “agile” methods in a fairly large corporate environment. We discovered the Manifesto when we were looking for possible ways to solve delivery problems we were experiencing. I never approached it evangelistically, but only as a means to solve delivery problems. “Agile” helped quite a lot in that situation. Since then, I’ve seen “agile” help in many other situations, as well. The “agile” community includes many individuals who take the same sort of pragmatic approach, and yet on the whole it is an evangelistic movement; that is, an organized attempt to influence others to adopt a predefined set of ideas. Here’s another of Ron’s comments from the Twitter discussion with a bit of editing to provide context:

• Either [top-down or bottom-up adoption], at each level [of] change the movement encounters a whole new layer of peers who will attempt to stop it.

Not picking on Ron here; I think he expresses a common sentiment in the “agile” community with this choice of words. It’s a movement. People want to stop “agile” adoption, and the movement has to overcome their resistance. The goal is agile adoption. I don’t see it the same way. I see “agile” as a school of thought which, alongside several other useful schools of thought, offers tools and methods that can be helpful in solving delivery problems. The goal is delivery effectiveness.

I think the reason agilists keep encountering resistance at each level in the organization is that they aren’t approaching the change initiative holistically. They are introducing change in small groups, starting with development teams. Others in the organization aren’t included from the beginning. A second cause of resistance may be that people just don’t want evangelists throwing magic hammers at them. They want people to help them identify and solve specific delivery problems.

How locally-optimized development teams harm organizations

I want to share two anecdotes from experience. The first pertains to a team I coached that achieved a very high level of proficiency with development methods commonly associated with the word, “agile.” The situation at the start was that the team was constantly criticized for being slow in delivering on software requests from the five lines of business it supported. They were keen to improve, and very quickly internalized the idea of continuous improvement. They frequently questioned their own methods to ensure they were getting value from them. As they improved, they shed more and more process management overhead until finally they were delivering on a one-week cadence with no formal iterations. Ultimately they were working four days a week, doing some lightweight planning for half a day, and spending half a day on professional development.

One enabler for their improvement was that I (and another coach) moved upstream from the team to tackle problems with the five stakeholder groups. (I didn’t know that was outside the agile purview until the recent Twitter thread. I was just trying to solve problems. My bad.) We learned the stakeholders had no coherent plan. They just made ad-hoc requests. They tended to “prioritize” small requests ahead of large ones so that they could see results quickly, with no thought to relative business value. They never referred to the corporation’s strategic plan. They had accumulated a wish list for the development team that went back three years or more. They believed the longer an item remained on the wish list, the more important it became. (The reality is that if a company can live without something for three years, then it isn’t important at all.) The five of them competed with one another for the team’s capacity, and the squeakiest wheel won. All in all, it was really an example of incompetent management; sorry to be blunt.

When we connected the dots between the strategic plan and the wish list, we were able to come up with a much shorter list of work items that resembled a combined Product Backlog for the five lines of business. Fortunately, the five key stakeholders were both willing and able to collaborate to determine overall business priorities across the five lines of business, using the strategic plan as a guide. We started to tie each request to one or more items in the strategic plan. We used Story Mapping to help decompose larger initiatives so that work could be scheduled properly. They also understood that the team’s delivery rate would get worse before it got better, as they were in the process of learning new development techniques.

After about six months of steady improvement, the team was able to deliver results faster than the stakeholders could request features. Here is where things went awry: The team started complaining that the stakeholders weren’t keeping them busy. After years of complaining about the development team, now the shoe was on the other foot. Why didn’t line-of-business managers understand their own business priorities? Why didn’t they know what their own needs were? The stakeholders did not tolerate being under the spotlight for very long. Within a year, the whole thing had been dismantled and the organization reverted to the status quo ante.

The second story comes from a consulting firm where I used to work. Another coach who worked there helped a team at one of their clients achieve a high level of proficiency with “agile” methods, like the team in the first story. They did so well that the client allowed the consulting firm to use them as a case study to market their services. After about a year, I was having lunch with our CEO one day. That case study came up, and something occurred to me. I asked him why, if that had been such a great success, we had never gotten any repeat business from that client. He explained that the client felt they weren’t able to keep up with the pace of “agile” development, and they decided to revert to the Old Ways. It was another case when the development team kept asking for work, and the stakeholders were not able to supply them with enough work to keep them busy. Stakeholders did not like being in that position.

The problem in these two cases was that the team’s performance was out of sync with that of the rest of the organization, and they made it clear to everyone that was the case. “Everyone” wasn’t pleased. Other development teams felt as if they were being made to look lazy. Management and stakeholders felt as if they were being made to look incompetent. I suspect (but can’t prove) this is at the root of many of the stories we hear with the general plot line, “We tried agile and it didn’t work.” It worked at the team level, in that the teams adopted the practices and learned to do them well, but the improvement was either invisible to people outside the team, or the improvement created unsustainable organizational friction because it was not undertaken holistically.

Given that most agilists prefer to work at the team level, is there a practical way to avoid this outcome? I think there is.

Moving the constraint into the market

An interesting thing about the Five Focusing Steps is that once you learn how to apply it well, you can place the constraint anywhere you want along the value stream. It is a pipe dream to imagine you can craft a process that has no constraint, but it is quite possible to place the constraint in the position where it does the least harm or, in some cases, where it actually helps you.

Consider the difference between Ford and Ferrari. Ford builds millions of vehicles annually, and then tries to sell off the inventory. As new models are scheduled to arrive at dealers, the dealers reduce prices and create incentives for people to buy their inventory to make room for the new units. Ferrari builds a few examples for showrooms, but for the most part they only build a car in response to a customer order. They control production such that demand is always slightly greater than supply. Ford makes money on volume sales; Ferrari makes money on margin.

One way to describe Ferrari’s situation is that they have placed the constraint where they want it. They have pushed the constraint out of their own company altogether and into the market. The “bottleneck” for obtaining a Ferrari is customer demand; it is not anything internal to Ferrari’s operations.

This gives them a couple of distinct advantages. First, they have time to concentrate on crafting high-quality vehicles. Because they aren’t “fully utilized” trying to mass-produce vehicles, they can take the time to consider the smallest details. They even take care to ensure the voice of each engine is unique. Second, they don’t have to worry about divesting excess inventory. There are never as many Ferraris as there are people who want one. Rather than wait two years for delivery, a customer will gladly pick up one from inventory.

How to avoid the local optimization problem when coaching at the team level

The situations in the two anecdotes about development teams have a lot in common with Ferrari’s approach to controlling the location of the constraint in their delivery process. By increasing their delivery capacity to a level greater than their stakeholder’s capacity to generate new work requests, in effect the teams pushed their constraint all the way out of their internal processes and into their market.

But then they blew it. As the saying goes, they screwed the pooch (had a good thing going and then did something stupid to mess it up, as if being nursed by a dog like one of her pups and then startling the dog by having sex with it, such that she stops nursing). They should not have made a Hollywood production out of their new-found delivery capacity.

If agile coaches want to focus on team-level improvement, that’s fine; but let’s be clear about goals. Don’t damage optimization of the whole in pursuit of optimization of a team. Don’t state goals that have the word “organization” in them unless you are ready to step up to organizational issues. If you want to focus on team-level improvement, then set a goal consistent with that focus. I suggest a goal in that case could be something like “Make life easier for team members.”

Say the stakeholders whom a given development team supports have a demand equivalent to 40 story points per week, and the team has a delivery capacity of 30 story points per week. Stakeholders are complaining that the team doesn’t turn around requests quickly enough, and that there are problems with quality. Life on the team is stressful. They are constantly racing to meeet schedules. Quality suffers, and they generate additional workload for fixing defects. Finding time for professional development is completely out of the question.

Now you are engaged to coach that team. If the case is either that you are explicitly told not to expand the scope of your work beyond the team level, or that you personally choose to limit your work to the team level, then your goal is not to “improve the enterprise” or any other such overblown nonsense. Your goal is to make life easier for that team. If you want that to happen, you must avoid creating organizational friction that would ultimately reverse all the improvements you’re able to make. By approaching it that way, you also avoid damaging the overall end-to-end delivery effectiveness of the larger process.

By helping the team learn effective software development methods and practices associated with software craftsmanship, you can increase their delivery capacity beyond the level of 40 story points per week. Now, here is the key point: Don’t advertise it. With a delivery capacity of 50 points and a demand of 40 points, you have a Ferrari (the company, not the car). The team is not under stress to deliver more work than they can accommodate properly. They have time to concentrate on quality and details. They have time for professional development.

Stakeholders only need to know they can depend on the team to deliver 40 points per week. Nothing more. You don’t want stakeholders to feel as if there’s something wrong with them because they can’t keep the team busy all the time. You don’t want other teams in the organization to complain. You’ve done a good thing. Now let it ride. Don’t screw the pooch.

If you don’t intend to address organizational issues, then that is as far as you should take it.

If you, like me, prefer to address organizational improvement holistically, then you might find this advice distasteful. I don’t like it, either. But it’s better than having local optima cropping up all over the place in the wake of team-focused improvement initiatives couched as “organizational” improvements.