I think Agile has a problem – it needs to grow up a little bit.

I’m not talking about “growing up” in terms of being more adopted.  I think Agile (and it’s various incarnations/methodologies) has far reached the point where it is considered mainstream.  At least to the point where it can be considered a viable option for teams/companies along with RUP and the likes.

What I mean by “growing up” is a change from rather informal, lax naming conventions that are, well, kinda puerile (“ScrumMaster?”) and tend to raise eyebrows a bit to folks in the corporate hierarchy, which tends to make them take Agile less serious because it seems like the Agile terminology was thought-up by a bunch of 16-year-old S&M RPG gamers.

I work for a well-known, established gargantuan of a company.  The senior managers tend to be a bit more conservative than, say, the folks (wonderful as they are) at Twitter, Inc., Facebook, Inc., or <enter startup created by 25 year old geniuses here>, Inc.  When I bring up Agile techniques to my senior managers, or do some coaching for teams new to implementing Agile, I always find a few people don’t take what I am trying to coach seriously at first, which makes my job just a tad bit harder.  And that’s just the “do-ers” on the teams – for senior managers, I can see their little snarky grins when I talk about the role of “Scrum Masters” or techniques such as Kanban.  Which actually makes it a LOT harder to push Agile as a strategy, especially when those same senior managers are the ones who have to sign off on said strategy.

The best (worst?) meeting ever came after a coaching session with a technical team, and I brought up the XP technique of “promiscuous pairing.”  The dev manager pulled me aside and asked me (paraphrase) if some of these Agile “things” came out of swinger communities.  (note:  link not safe for work – see what I mean?)

I have found that once I changed the terminology of certain Agile techniques or roles folks took the philosophy quite a bit more seriously.  Examples of terminology adaptations include:

  • ScrumMaster -> Facilitator or Iteration Manager
  • Sprint -> Iteration
  • Backlog -> Prioritized Requirements
  • Kanban -> Taskboard
  • “Planning Game” -> Sizing/Estimation Workshop
  • “Promiscuous Pairing” -> On-demand peer review

The list goes on…  The problem with the adaptations is that they are not official Agile terms, and so folks doing research on their own tend to not find the right kind of information because the Agile community uses the more informal terms.

I do get it – I understand why we use the more informal terms.  Agile is a new way of thinking for a lot of development teams (though, I argue that it is a cleaner, more refined regurgitation of the old RAD style, but I digress), and with the new way of thinking we should use new terminology so that folks think about how they approach activities differently (i.e. if you call it a “requirement” they will do the old-style deep up-front analysis whereas “User Story” won’t invoke such a trained reaction).  But as Agile adoption becomes more mature and enters the more mainstream “boring” old companies, I think we as a community need to take stock and consider formalizing the techniques and giving them names my senior managers won’t giggle at.

To be fair, some of the Agile terms aren’t that bad;  things such as “Sprint” can be easily translated to “Iteration” without much problem and doesn’t raise many eyebrows.  But, “ScrumMaster?”  Are you kidding me?  Oh, and “Backlog.”  Now, this is something I didn’t realize until I started at my current employer, but “Backlog” has a bit of a negative connotation with many old-school senior managers, as it used to mean a list of things that are behind or late and needed to be done.  In Agile, it means a prioritized list of things that need to be done as well, but “backlog” also implies those items are late and it’s bad.  I’m not saying that’s right, it just is what it is.  In fact, in sales organizations a backlog generally infers a list of customer orders/requests not yet fulfilled, but is also generally described in monetary units and not as individual items.  Another confusion.

The “planning game” is simply silly.  Many folks involved in software development do not consider planning, sizing, and estimating a game at all.  It’s “serious business” and many careers are staked in proper planning.

Again, I do realize many of these terms are meant to be taken lightly – and part of doing Agile is inserting “fun” back into software development.  But we also have to remember that not everyone thinks of software development as “fun” and that your manager may be more of an MBA-type rather than a Computer Science-type.

So I ask – is it time for us to consider making some of our techniques and methodologies a little more formal and a little less….  childish?

Just a thought.