T-shaped Agile

Quite frequently, I hear folks in the agile development 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.

This entry was posted in Agile Adoption, Agile Development, Agile Management, Agile Methodologies, Agile Teams, Enterprise Agile, Extreme Programming, Kanban, Lean Software Development, Scrum Development. Bookmark the permalink.

One Response to T-shaped Agile

  1. Lee Cunningham says:

    Thanks, Anantha. To answer your question, my first thought is that we are human beings, and we can become zealots about anything if we allow ourselves. Using an agile mindset and applying proven agile techniques is an excellent way to manage change, as it allows us to commit to small steps that can be adjusted or even completely reversed, if necessary, as reality emerges, without a “social penalty.” I think what happens sometimes is that organizations rush to implement the what elements without first understanding the why part. Looking at agile as first a philosophy, as opposed to a set of cookbook practices, can help avoid zealously pushing change down the throat of an organization. Hope this helps!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>