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.

There has been a lot of chatter recently about the value of [enter Agile methodology here] certification. I think a lot of the chatter is due to the controversy surrounding the Scrum Alliance’s letters to various user groups, asking them to “license” the Scrum name. And I believe the other reason is the huge number of trainers out there making quite a living doing the Scrum certification thing.

Part of that last sentence isn’t fair. People need to make livings. And, there is immense – if not, with the right people, priceless – value in those who have led teams down the Agile path teaching and coaching others to do the same. But as with anything that looks really cool and works, you have folks who go through the certification motions just for the sole purpose of being able to make good money. It’s those who don’t see their career as a craft or who have real passion in what they do – they just want more money. Not that capitalism and the desire to be wealthy is bad, no judgments there. But I get the feeling that many of the “Agile trainers” out there just aren’t of the quality that many teams need. To extend the idea in my last entry (“architects who don’t code are like fashion designers who don’t sew”), there are a lot of people out in the field training novices how to design clothes without ever having picked up a sewing needle. Certified trainers, no less. I know, I’ve run into a few.

I really like Elisabeth Hendrickson’s take on certification, and the alternatives to official certification: WeVouchFor.

And, like Elisabeth, I must confess – I got started in Agile by going to Ken Schwaber’s CSM class in 2004. At the time I did not think much of the whole issue with certification. But now? Well, I’ve simply met too many Agilists who still just don’t get it.

And I’m not going to sit here writing in my holier-than-thou blog trying to convince myself that I know everything and I totally get everything. At least, I hope that’s not what I’m trying to do. I hope the day where I stop learning never comes. But, I can say that I have some good experience, both on a small-company level and at a large-company level, in rolling out and/or practicing Agile techniques. And by experience, I mean, I have been blessed with the ability to totally and royally fuck up beyond belief, get my ass burned by my various managers/clients, and learn from it and move forward.

My point? How can we “certify” experience? In Agile (and I would assume in RUP, Waterfall, etc other process), experience counts for so much more than simply education. Agile techniques at their basic level are taught, but they are further refined at the company, team, and individual level through tweaks after doing. A.K.A. screwing up, learning-through-retrospective, moving on. How in the world do we certify that? The closest thing I can think of is something along the lines of WeVouchFor. I like that I am  able to describe my own skills (i.e., “Coached teams”) and have people specifically vouch for that piece (“Michael coached me”) and provide evidence/testimony to it (“result was a team practicing Agile and still is!”).

Of course, I see a small danger here too.  I see a danger of “you scratch my back, I’ll scratch yours.”  Again, it’s not a bad thing if the scratching really happened.  But “official certification” does offer potential employers and clients some sense of understanding that the certified person did, in fact, attend a class and did, in fact, pass it.  Vouching does not.

I don’t have an answer.  I have some ideas.  I need to think about them some more.  I like the idea of possibly letting certain “vouches” carry more weight than others, and that reciprocal vouches are worth the least.  Again, the logic still has problems. How would you quantify the value?  Points?

This particular topic was the one thing I wanted to bring up during the AgilePalooza Open Space, until I was rudely interrupted by my employer and had to leave.  Perhaps next time.

Believe it or not, I ask this question all the time.

I come from the belief that if you’re in a team, and you’re getting products out the door, and your product owners/managers are happy, and your developers are happy, and (most importantly) your customers are happy, then why adopt Agile?

As I am an Agile enthusiast, you’re probably shocked to read the above paragraph.  But, why?  See – I like asking this question because it lets me really understand why a team wants Agile coaching.  Sometimes I get a team that wants to  implement Agile, but not because they want to improve themselves but rather because their manager told them to do it.  I’ve learned through the years that those teams who are forced to do Agile without having internal reasons for doing so, tend to fail at implementing Agile.  Or they end up worse off than they were before.

In order to implement Agile the team has to commit to some minimum disciplines in order to be successful.  Scrum is a great overall process but for software engineering jobs it must also be supplemented with development practices (unit testing, automated acceptance testing, modular codebase, etc).  The testing team also has to be on board with a dramatic change.  These things cannot just be “adopted” willy-nilly – it takes commitment.  And teams without that level of commitment – to themselves, to quality, to their customers – should just not bother.

Of course, these practices don’t have to be adopted all at once – it is expected to happen piece-by-piece as well.  But the commitment must be there to eventually get to that point.

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.