There are some widely varying opinions on the validity of Scrum certification but I think, much like any education, it’s not the sole means of determining qualification for a position.

The naysayers will argue that a 2-day (which is now 3-day by the way…) CSM class only serves to dilute the quality of Scrum Masters in the industry and is somehow de-valuing and undermining the Agile world.  Their argument is that “Agile” is being mis-represented by giving folks a designation that is being misconstrued by companies that are hiring these folks.  These companies get a false impression of Agile because they ‘hired a CSM’ without experience and ultimately Scrum or Agile fail which leads them to believe that the Agile myths are valid.

When I first drafted this post, the tone was more about companies getting what they deserve if they hire someone with no experience, regardless of what job they are filling.  After re-reading it a couple of times, I decided to ‘be more agile’ and put my energy into suggestions that could help improve the value of the certification.

What Companies can try:

1. Get educated on what Agile is and understand what they are in for.  They need to understand one ‘certified’ person isn’t going to come in and wave the magic wand.  It’s a team effort to make a new agile adoption work or fix a failed one.
2. Understand what CSM means.  Sure it’s just a 2-day course, but it means the person has received a quality education and understands the Scrum process even though they might not have practical experience.  As with any education, it’s only as good as how it’s used after being obtained.
3. Shouldn’t only interview CSM’s, don’t put the sole value on a piece of paper.  IE: put “preference given to someone with CSM designation” instead of “CSM required”
4. Bring in a panel of cross-functional folks to interview the person, make sure they will fit in the environment.
5. Have them participate in a real-world scenario.  A true scrum master would thrive on an opportunity like this to prove themselves.  Any reluctance and you know they aren’t the person you want.

The Noob CSM

1. Be Honest.  Yes I realize you can’t get experience without having some experience, but don’t pretend you are something you are not.  Setting an expectation upfront that your are capable only for the company to find you are not is far worse for you AND them than it would be to maybe look for a more junior role with a smaller team/company.
2. Focus on helping the company understand you have the knowledge and tools to make Scrum/Agile succeed but that it’s a team effort
3. Take the time to understand Agile adoption successes and failures and you will notice there is a common theme to them.
4. Learn, learn and learn.  Join Agile communities, participate in Agile forums, start or join a local Agile user group.  Being a ScrumMaster is not a 9 – 5 job, it’s a learning job that requires dedication.

So am I in favour of certification?  Well, as usual, it depends.  In certain circumstances, I am.  I believe having an education from a qualified trainer/institution gives you a solid foundation to start with.  The reverse is also true, I know some folks plenty smarter than me that have no certifications so I don’t take too much stock in it.  You can read  books/blogs and get the same knowledge but be wary of “scrum-but” or “agile-but”. Those are much worse and do far more damage to the industry than someone without practical knowledge and experience does.

I would defintely prefer to see some type of scenario based exam so students can prove they can apply the knowledge gained in the course instead of a multiple choice exam.   It’s pretty simple to memorize a few facts and pass and exam however that is better than being given a certification based on the instructors assertion you deserve it.  Having said that, I’ve worked with some MCSE’s who passed the Microsoft exams but didn’t understand basic file sharing principles in Windows NT4.

This is a step in the right direction in making the certification more meaningful and difficult to obtain and it’ll be interesting to see what type of exam the Scrum Alliance can come up with.

To continue the theme, I’ll recap and update as per the format from yesterday’s post.   In the interest of saving time, if I don’t list it here, read yesterday’s post as my opinion didn’t change.

The Team should be accountable

Actually, this really isn’t applicable in the sense of what “accountability” means in the business world.  IE: mess up and get reprimanded or fired.   The TEAM is responsible for what they commit to.  If the sprint fails, the sprint fails.  Scrum is designed to help teams learn through failure and get better as a team.  The sprint does not fail because 1 person on the team wrote bad code or 1 person on the team forgot this or that.  No sole person is responsible for that failure.  It is important to learn from it and move on.  Now if you fail multiple sprints (like all of them in a project) something is clearly wrong.  Scrum has no methods for handling this, it’s designed to not fail if applied properly.  Take that last statement with a grain of salt, Scrum isn’t the magic bullet and it’s not the only solution but if used right you decrease your chances of failure.  If the sprint is interrupted and work is added/removed (the “it’s gotta get done” factor), the Team is no longer responsible for those commitments.  Teams is a big discussion, I can’t possibly capture it all here, but they need the authority to succeed as well.

My Biggest issues:

User Stories: Damn, the vote on this optional module was too low so we didn’t talk about it too much but we did talk about product backlog management and I managed to get a couple key questions answered in sidebars.  User stories are an approach to phrasing stuff on the product backlog.   A backlog item (phrased in a user story or not) is simple the vehicle to a discussion.

The product backlog is only for requirements and features/improvements.  Scrum used to teach that everything goes on the product backlog, however that has changed.   It’s important that the Team understand that a story isn’t going to tell them the full requirements.  The point is for the team to understand the business reason WHY the story is there and how to complete it.  That involves talking to the product owner to make sure they’ve got a good idea of what the point is.  It’s then up to the team to create the sprint backlog from that story.  That includes everything required to mark the story done (remember the team defines what ‘done’ means.

We covered Product Backlog Management via voting on the optional modules.  I’m glad we picked that one.  It really helped with a couple of things.  The biggest being what belongs on a product backlog.  Stuff like “deploying the sprint work” doesn’t belong on the backlog. It’s implied that is going to happen because you will be providing a demo at the end of the sprint.  Stuff like that can also sit as a sprint backlog item.  IE: the product backlog item is “upgrade client 1 to version 2.0″ (again, remember you don’t need to use user stories…)  Your sprint backlog items could be stuff like upgrade the client project files, change the config, write a batch file to deploy the stuff….etc.

Another key with product backlog is that the Product Owner has the sole discretion to add/remove stuff from the backlog.  The Product Owner talks about value, the Team talks about cost.  The Team is not able to tell the Product Owner that the can’t do item 1 because of a dependency.  It’s up to the team to figure out how to break that dependency, and of course, that only applies to software.  Mishkin drew a great diagram that explains this.

And finally, albeit out of order in this post, we talked about the Scrum Master role.  It basically summed up the stuff we learned all week, but more specific to the Scrum Master only.  The Scrum Master’s purpose is to satisfy the stakeholders and provide visibility into the work being done so there are no surprises.  The Team doesn’t report TO the SM, the Team reports to each other and the SM facilitates the learning of Scrum and removing obstacles for the team.   We did some great exercises around SM scenarios as well.  This module was pretty simple and the class all did well since by this time we all learned quite a bit.

To wrap it up, I managed to squeeze out a couple more questions particular to my situation and am proud to say I’m now a Certified Scrum Master.  Now I support I can be one of those wankers that puts a big pile of acronyms after my sig since I’m an MCP and now an CSM!

Seriously tho, this was a great boot camp, tons to learn and I’m really quite exhausted.  I have absolutely no problem plugging Mishkin Berteig of Berteig Consulting for a simply fantastic course.  If you are new to Scrum, having problems implementing Scrum or need some validation or coaching, I would highly recommend them.  The level of knowledge and experience was amazing.    The message was clear, Scrum has rules.  Follow them and you’ll have a great chance for success.  Scrum doesn’t solve all problems and it’s not applicable for all situations or companies, use common sense in your approach to implementing Scrum but above all else, the rules are there for a reason.   You should resist temptation to break them because you think it’s the right thing to do.

I’m excited and exhausted all at the same time, can’t wait to get to work on applying this in my company.  Keep tuning in, these first few posts were chaotic so I could dump all my thoughts, but there is some great stuff coming.