T-shaped Agile

Quite frequently, I hear folks in the Agile community splitting hairs over their favorite approaches to delivering products and services. There are those who will argue over whether or not one should be allowed to mention "Scrum" and "Lean" in the same paragraph, on the basis that Scrum's focus is too narrow. And then there are those who proclaim kanban to be a higher-evolved technique than Scrum, while others argue, with just as much conviction, that kanban is for teams that can't self-organize very well. I've even heard some people question if XP is, technically-speaking, "Agile" since, by prescribing specific practices, it may be at odds with the spirit of the Agile Manifesto (true story). Yes, it seems that in the midst of all our excitement at actually being able to produce working, valuable products, we've come to have a whole new generation of process bigots.

The blindly zealous promotion of one tool or framework, or methodology, or whatever, over all the others is short-sighted, and it can make our community look foolish at times. From my perspective, the lines between different agile approaches have become very blurred. They all promote letting people work together to produce products that work and are valuable with as little non-value-added stuff as possible, they all include mechanisms for continuous improvement, and they all include practices that can be traced to Lean thinking.

Many of us refer to "T-shaped people" as a way to describe team members who are very deep in some particular area of expertise, but who are also competent in complimentary skills. This concept can also apply, in my opinion, when it comes to our agile approach to providing value to our customers. Thinking in terms of a "T-shaped approach" makes sense to me. I can't remember the last time I saw a team that is successful at Scrum that didn't take advantage of user stories and at least some engineering practices from XP. And the widespread practice of Scrumban is surely an indicator that those two approaches aren't mutually exclusive, although some implementations of that are more heavy on the "Scrum" than the "ban", and others just the opposite.

Does this mean that we should no longer formally teach the rudiments of Scrum or XP, or that we shouldn't seek an understanding of Lean? Not at all, because without that, we'd have no basis for the "deep" part of the T-shape, and just end up with collections of cherry-picked practices of convenience (such collections are notorious for their failure rates). But neither should we stop innovating. Possibly, the two most important words in the Agile Manifesto are "are uncovering".

Anymore, I get the ball rolling with a team by asking, simply, "What is it that, project in and project out, obstructs your ability to rapidly and frequently produce something that is valuable and acceptable to your customer that actually works?" It's usually the same core list of problems, regardless of organization size or the type of business they're in. Based on how things work in their world, though, the appropriate approach for them will be solidly rooted in one proven agile approach, with additional complimentary practices from other proven approaches. Remembering that all of these approaches are more alike than they are different should allow us to concentrate on building good stuff that our customers love, and have a good time doing it. That's a lot more fun than arguing.