ITMPI FLAT 004
Main Menu
Home / Project Management / Agile / A Certification doth not an Agilist Make

A Certification doth not an Agilist Make

This one is for Elaine of the golden hair.  Angels above blush at thy beauty.

“Socrates gave no diplomas or degrees, and would have subjected any disciple who demanded one to a disconcerting catechism on the nature of true knowledge.” – G. M. Trevelyan

The other evening, I had the chance to chat with an acquaintance who is a certified scrum master (CSM).  We started a rather deplorable, desultory conversation, until the subject turned to certifications.  He said another acquaintance of ours had emailed him and asked if he should get a CSM.  My friend, who is certified, swears by them, so he said yes.  I asked him, how he was expecting the certification to help our mutual acquaintance.  I know for a fact the seeker in question has never worked on an agile project (oh a few might have been labeled as agile, but weren’t in any real sense agile).  Worse still, I have spoken with him often enough to know he was a somewhat rigid thinker and very process oriented.  True agile thinking would be at odds with his philosophical makeup.  Of course, when I challenged the scrum master, he temporized, saying that it couldn’t hurt and wasn’t expensive1.  Both statements are more or less true depending on your perspective.

Since the subject had been broached, I decided to probe further and risk annoying him (after all he was smoking a cigar2 and I knew he wouldn’t get up and walk away until he had finished).  I asked him, how a scrum master certification makes you an agile thinker.  He immediately launched into the description of the nomenclature and process of scrum3 with user stories, planning sessions, daily scrums, sprints, spikes, retrospectives, etc. while I sat patiently and quietly sipping my scotch4 (my British readers would have been proud I was drinking it neat).  After he finished his dogmatic recital, I asked him the question again and added are you a better agile “thinker” today than when you started with agile projects years ago.  He paused to reflect (no doubt expecting I was laying a devious logic trap for him) and said, yes.  I then asked him if the process that he learned in his early CSM training had changed any. He admitted that it had not.  So I asked him a third time, how his CSM training had made him an agile thinker.  Unfortunately, he chose that moment to snub out his cigar and excuse himself5.

Don’t get me wrong, I am not adverse to certifications.  However, despite their hype, certifications have a less than stellar significance today6.  They never seem to quite live up to their advertising.  Generally, they show you have some knowledge about something, but not necessarily the understanding or the wisdom that’s needed to employ it successfully.  They often place a strong emphasis on terms or a particular process or method (let’s not get into the process versus method argument), but they don’t necessarily change the way you think.  Changing a person’s thought pattern or behavior takes time.  It is one of the reasons successful programs, like some that Dale Carnegie7 offers, can take weeks.

Learning to “think agile” in an agile software development cycle is a lot harder than learning the terms and running 2 week iterations.  Those who come from a more process oriented mentality or are waterfall thinkers, often feel that agile is the same concept only in smaller and more frequent increments.  Others, who are opposed to change, usually deride agile as being totally out of control.  Neither view is valid.  Agile is about focusing on the essentials, working smarter and learning as you go.  It’s about real team empowerment, not a new way to manage people.  That’s one of the reasons hardcore project managers tend to not be good scrum masters8.  Their basic inclination is at odds with the nature of their new function.

Speaking of function, for those who are in information technology (IT), remember the time before object-oriented programming became popular.  Do you remember how long it took you to actually develop good classes?  Classes that were functionally highly cohesive and loosely coupled didn’t happen overnight, did they?  Oh you probably learned the diagrammatic syntax in an hour or a day and the structure of a class, but how long before you were actually designing9 a solid class?  Depending upon your philosophical bias, it could have taken you a year or more to gain an object-oriented proficiency.  Well “agile thinking” can have a similar gestation period.

As I have shown in my series Interviews with a Natural Agilist, some people are agile thinkers by nature, rather than nurture.  This leads me to believe that thinking agile or being adaptive is in fact more natural10 than the heavily process oriented thinking in which we were indoctrinated during our business careers.  Even as children, we ate did our homework and then watched TV.  We followed the same class schedule, day after day, memorizing lessons by rote.  Later, we hung out at the pizza shop or the mall.  Somewhere along the line, the idea that regimented thinking was a good thing, was foisted upon us.  Yet we reward and admire those who think outside the box in inventive companies11 like Google, Samsung, Intel, 3M, Microsoft and Bristol-Myers Squibb to name a few.  Wouldn’t it be better if we encouraged children to develop their own ideas and to actually think12?

The hardest part of agile13 is coming up with the correctly sized, highly encapsulated and highest value user stories in a sufficient product backlog for a development team.  Users are in the hot seat for creating the initial user stories and generating a product backlog.  Many studies have shown that an agile development team’s velocity has a direct relationship to the amount and quality of the product backlog.  This sounds easy because users always want something.  In reality, it is actually quite difficult for users to create high quality user stories and generate a healthy backlog, particularly if they are new to agile.  One of the forces that drove software development into a highly regimented and documented process was the fact that users had a great deal of difficulty identifying their needs in a detailed, specific fashion.  Development teams ended up building software that the user might have asked for, but really wasn’t what they needed.  So to end the blame game, software development organizations created processes with sign-offs and decision gates.  All this did however, was to shift the blame “officially” back on the user.  It did not create better software.  Software development organizations and companies that follow this philosophy can’t hope to survive the next decade.  There is no room for playing the blame game in a dynamic agile marketplace.

My point is that if you want good velocity (assuming you have a good development team), you need good user stories in abundance.  In order to get good user stories, you need to have users that not only have business expertise, but can practice focused, critical thinking.  It is an interesting correlation that what makes a good object in object-oriented thinking is similar to what makes a good user story.  I have found that some of the oldest thinking is timeless14 in this regard.  It takes time to develop this expertise.  It is important because it is the very beginning of the agile development process.  As the old saying goes – “garbage in, garbage out”.  I have seen agile teams with great velocity, turning out junk, because the user stories were ill conceived.

That’s why I like the term “Master Agilist”.  A Master Agilist (MAg) is someone who is so adept at thinking in an agile fashion, they can adapt to any situation.  From a software development perspective, they don’t have to be technology, business or process experts.  They can be either users or another member of the development team.  What makes them Masters is that they instantly know whether a user story is well conceived and crafted or not.  They also know, if it is critical or superfluous.  You can see the common characteristics of MAgs in my interviews with a natural agilist series.

In brief they:

  • Are instinctive analysts, always breaking down a problem and looking at it from many angles.
  • Have a strong ability to think abstractly and conceptually.
  • Are proactive thinkers and executors that abhor procrastination.
  • Understand the Pareto Principle and all its implications, recognizing core from trivia.
  • Are highly adverse to rote behavior, they need to know why something is done.
  • Are constantly learning and never are satisfied with what they know.
  • Plan in terms of simple experiments and gaining empirical knowledge.
  • Live for their dreams rather than be ruled by their fears.
  • Think about everything in terms of an agile philosophy whether its business or personal life.

So should we create a Master Agilist certification that supersedes any specific technique like scrum?  Or should we just acknowledge the limitations of certifications; have realistic expectations for them and recognize the need for a higher level of agile thinking.  What do you think?  Remember till next time, keep agile!


2 A Padron Padrón 1964 Anniversary Series Exclusivo Maduro #5.

4 MacCallan’s 25 year old

5 Where are the William Jennings Bryan’s of the world willing to argue the wrong side brilliantly as in the infamous Scopes Trial in 1925. See http://en.wikipedia.org/wiki/William_Jennings_Bryan  C’est la vie!

6 Microsoft despite efforts to import their programs are questionable see http://insidetech.monster.com/benefits/articles/1571-top-10-problems-with-it-certification

8 Or any other title that you want to give an agile facilitator.

9 I am going to focus on the design aspect of agile for now and not the development aspect of agile.  The former is far harder than the latter and is where most agile projects go awry.

10 See Is agile a return to common sense? for a historical perspective.

12 My golden rule when working with a new or inexperienced person whether or not in business is to gage their ability to think and reason and then actually get them to practice it. The old parable that if you give a person a fish you feed them for a day, however if you teach them how to fish they can feed themselves for a lifetime applies.

14 Niklaus Emil Wirth, the father of Stepwise Refinement see http://en.wikipedia.org/wiki/Niklaus_Wirth.  David Parnas, the father of information hiding see http://en.wikipedia.org/wiki/David_Parnas.  Edsger Wybe Dijkstra, the father of the principles of abstraction see http://en.wikipedia.org/wiki/Edsger_W._Dijkstra.

About Brian Lucas

Consultant, lecturer, project manager, business manager, and software architect who has been with Computer Aid, Inc. since its inception over 25 years ago.

Check Also

Shin Godzilla: An Unexpectedly Agile Monster Movie

Last weekend, I had the good fortune to catch a limited screening of Shin Godzilla …

Leave a Reply

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