Hold Your Horses, Young Guns

Last week, I had an opportunity to attend a short talk by Jeff McKenna.  Jeff was involved in the first Scrum project (you know, Easel Corporation, Smalltalk…).  It was very interesting hearing his perspective on Scrum's early days.  One thing in particular that I found intriguing was that he said all they were trying to do on that first project was to figure out something that would work.  That confirmed a hunch of mine that Scrum's practicalities were realized before people started thinking about how Scrum relates to complexity theory, etc.  That isn't the story you might infer from reading the literature.

I was also impressed with the respect he mentioned for Don Reitersten's work, and his recognition of the growing awareness of Lean throughout the Agile community.  He made it a point of emphasis that Lean preceded Scrum by decades.  I think I chuckled out loud when he said that, because that's a thought that has always crossed my mind whenever I've heard someone touting Lean as something newer and better than Agile.

Of course, Jeff said a lot of other things that resonated with me.  But more so than any one thing that he said, it occurred to me that with so many people in the Agile and Lean communities competing to be the next generation of "thought leaders", we have a wealth of knowledge and experience in Jeff and his cohorts that we'd be ill advised to ignore.  To hear some tell it, that group is just a bunch of curmudgeons who are no longer in touch.  Having had the pleasure of spending a few minutes with Jeff, I have to say that I strongly disagree. 

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.