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.