Michael Dowling's Whispers

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.

From InfoQ:  Scrum Alliance Asks User Group to Sign Licensing Agreement

Yikes.  Upon first reading the headline of this article all I could think was “oh crap, this marks the beginning of the end for Scrum.“  At this point, the Lean zealots are throwing their hands in the air exclaiming “I told you so!“  Ha, perhaps.

What I like about Scrum is the overall process components it gives us.  It tells us to use a backlog, but it doesn’t tell us what those backlog items must be.  It is common to use User Stories as backlog items, but I’ve worked with teams who use bug reports as backlog items.  Scrum gives us the concept of the “Planning Meeting” where we estimate the backlog items and commit to work during the Sprint, but there is no defined agenda for the meeting.  It is common to use XP’s model for planning (“The Planning Game“), among others.  Same with the demo, the retrospective, and the sprint itself.  Heck, even the sprint length is negotiable!

The point is, we get carried away with the notion of “pure Scrum.”  I find the whole certification practice around Scrum to be completely ridiculous, as groups rarely implement “pure Scrum” because it doesn’t exist.  The components within Scrum tend to be customized by the team, especially during the retrospective.  And it is even more common to use Lean techniques for doing so (which is why I find the fight between Alan Shalloway and his group of Lean folks and Ken Schwaber and his Scrum folks to be equally stupid as Agile certification programs), making Lean and Scrum obvious cooperative processes.

Also, need I remind the Scrum folks that the word originates from a Rugby move?

I will still practice Scrum for the foreseeable future, as I’ve seen so many amazing improvements to teams that I have implemented Agile with.  In each of these teams I hold the expectation that the basic process of Scrum will be modified to fit the needs of the team, which is exactly what I tell them. Besides, some of the most common question I get when I coach teams in Agile is “what about testing?”  “What about development?”  Again, other Agile practices being brought into the Scrum team negate the whole idea of “pure Scrum” and therefore no one organization can own the process.

I’d like to see them try.