Can doing something anti-Agile be more effective?

Let’s consider two “dimensions” of a project, the extent to which it adheres to “Agile” values, and the extent to which it is an effective or successful project.

We all know that there have been successful projects that didn’t seem very “Agile”. And there certainly have been projects that we might have called “Agile” but that were not very successful. Now, my experience suggests to me that agility and effectiveness are correlated: use of Agile techniques tends to improve effectiveness. Maybe the “spectrum” of Agility and Effectiveness looks something like this, with good things tending toward the upper right, and not so good toward the lower left.

Considering just the “Agility” axis, let’s look at the placement of some practices, focusing on the Agile Manifesto notion of “Individuals and Interactions over Processes and Tools”.

Similarly, we can look at design. If a team builds a great design and understands it well, that’s better than if they have a design that they understand only fairly well. We believe that if they create the design they will probably understand it. Even then, that design may not be understood across all teams, and of course, not all teams produce “great” designs.

In any case, a well-understood good design could be better than a great design understood by only a few.

So on our Agility/Effectiveness chart, we can think about an “Agile Direction”, where moving right is better, and an “Effectiveness Direction”, where moving up is better. Agilists believe that moving more toward Agility is likely to move you more toward Effectiveness.

Are there exceptions? Perhaps! It depends where you start, and what you change.

Sure, a highly skilled team can produce a design that is hard to beat, shown at top right in the picture below. But a team with low skills cannot produce a good design, no matter how self-organized they are, as shown by the blob in the lower left.

So what if we gave that low-skill team a good design to work with, made it easy to apply, and helped them understand it? The team might well be more effective, moving upward, while being less “Agile”, and moving toward the left!

I find this notion at least credible, and certainly we can imagine a situation where we do not have the time or ability to upgrade the team by hiring or training, and we must do something. And maybe the team do learn something from being given this design.

Every Agile team uses some provided tools, and reuses design ideas, most of which are “owned” by the team members. This is only a bit different, in that the team members probably didn’t own this design until someone gave it to them.

So what conclusion should we draw? One possibility is that there are projects, or teams, or situations, where Agile will not work. I wouldn’t go that far: what we have here is a case where we chose not to follow the Agile path.

From the Agile viewpoint, what we have here is a fundamental violation of the Scrum principle that the software must be done by a cross-functional team: a team that has all the skills needed to do the project. This team doesn’t have the design skills to do the project … and therefore they are not an Agile team at all!

That doesn’t mean they are evil, or that they can’t succeed. If you don’t have an Agile team, and can’t get one, well, try things that make sense. Investing in the Agile direction is likely to pay off more, but it may be difficult to impossible to invest, and it could take time. In the meantime, do what you will … and please don’t call it “Agile”. It just isn’t.

7 Responses to “Can doing something anti-Agile be more effective?”

Gishu Pillai

June 30, 2010

2:07 am


Amen. I continue to be amazed with your ability to articulate your opinions/viewpoint.


June 30, 2010

12:12 pm


Dear Ron,
Great article…as usual. “Spectrum” is a nice presentation idea. However, I cannot help myself to make some observations. Bad design is about lack of professional experience. A bad design will affect the effectiveness indeed, but definitely not because of poor agility (i.e. no matter how agile you are, the team will not produce a better design as consequence). Therefore I think that at least one axes need to be added, which is the professional experience level. In addition, I will assume that by project’s effectiveness you consider at least the time, costs, and quality. If I will produce a good design for an unskilled team this will not affect the costs and time (i.e. effectiveness) for the project? So, “use of agile techniques tends to improve effectiveness” of the team and not necessarily of the project.

Ron Jeffries

July 1, 2010

8:50 am


Thanks, Gishu. As a rule, no need to gush. :) I welcome substantive comments.

Hi Ioan. Thanks for the note. There are of course many axes to consider, and the quality of the people is one of the most important. Our topic here is just whether there exist points in the “space” where doing something that “Agile” wouldn’t recommend could be a good idea. I think there are such points. Personally, I’d try to move away from those points. As an alternative, or in the meantime, one might do something that “Agile” would consider second or Nth best.

Steven Gordon

July 1, 2010

10:15 am


Something similar to Ioan’s point that I hear often is that handing down the design only requires a small number of architects with the requisite skills and experience, whereas agile depends on the skill and experience of the entire team.

I have been on both sides of that wall (the architect and the programmer) and I was never happy with the results:

As a programmer being given a design to follow, I always ran into gotchas that the design did not account for. The design, being owned by the architects who were often too busy to collaborate, was golden which made adapting it to such issues a slow frustrating process, so we usually just faked it in order to get the work done.

As an architect, I found that a bunch of different programmers worked around the architecture in different ways to handle a bunch of different gotchas (many of which could have been handled within the architecture if the programmer had only asked) lead to a disorganized implementation that bore little resemblance to the initial design.

The problem is that a documented final design up front does not work well for the implementation of non-trivial software, no matter how much skill and experience went into the up front design, unless those architects are dynamically involved in collaborating with the programmers and adapting the architecture during the life of the project.

J. B. Rainsberger

July 1, 2010

4:15 pm


Focusing only on design, I have believed in the Surgical Team model in the past, I have believed in the Specializing Generalists model, and now I have settled on a simple maxim that respects basic concepts from the Theory of Constraints: as long as there are enough skilled designers, the design will thrive. This doesn’t mean that everyone must design beautifully, although that would help. This does mean, however, that given that companies have the goal to grow, and that that usually means that software development organizations will grow, and that that usually means that we will have more programmers over time, then we cannot rely on a fixed number of skills designers. Eventually we will need more skilled designers to keep the growing number of programmers from killing the design. I don’t know how to build a sufficiency model for this problem, so I recommend that teams work on helping as many programmers as possible become more-skilled designers. Absent knowing how many is enough, we should always try to develop more.

Karl Scotland

July 3, 2010

1:01 pm


Hi Ron,
Thanks for this article. I like your approach and logic. There’s been something bugging me about it though. If we can become more effective, and move up the vertical axis, why do we care about how Agile we are? Isn’t Agility a means, and Effectiveness the end?

Ron Jeffries

July 3, 2010

3:49 pm


Hi Karl,

We shouldn’t care how Agile we are. I’ve been saying that for ages. We should care how good we are.

That’s why all the selling and counter-selling of Scrum versus Lean versus Kanban ticks me off so much. It’s all good. Yet some marketers insist on attacking good ideas and their bearers, instead of going after businesses who are not performing well.

It’s sad, really.

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

XProgNew – Pivot?

Experience with Sinatra, and some thinking, cause us to look at a shift in approach. Martin Fowler was probably right.