The Scrum Certification Debate Continues
Over at infoq.com, Vikas Hazrati talks about the never ending debate of Scrum certification – to certify or not to certify.
Being one of those that attained the Certified ScrumMaster (CSM) title by sitting a two day class, it did seem a little bit crazy to become ‘certified’ without getting assessed.
On the other hand it was OK that I now had a title that differentiated myself from others that had not learned what I had i.e. I learned about the framework.
Many job advertisements still ask for ‘qualifications’ such as the CSM so having those three letters on a resume I assume is an advantage over its absence.
Still at the end of the day it doesn’t really equate to much in the real world, and experience and application of the likes of Scrum is the real measure.
I also think that the recent introduction of the CSM online exam is step in the right direction, but probably needs a new name such as “Person that Understands the Scrum Framework (PUSF)”. Yes its a bit wordy, but maybe its a more accurate description of someone who has passed the CSM online exam.
Here’s hoping that the Scrum Alliance can get it sorted out soon and make a decision on its direction.
The original article at infoq.com can be found here: Is Scrum Certification Having Another Makeover?
Rekindling the Agile fire
I read a little while ago a good article about doing Agile vs being Agile. It got me thinking about why I keep coming across people that think they are being Agile but really they are doing Agile. Follow the process and call me Agile!…so to speak. It pains me when people DO Agile and forget about the other components of Agile – I’m thinking specifically continuous improvement here.
I have worked in the IT industry for 16 years, and half of that time as an IT Project Manager. I used to follow the wisdom of Prince2 and believed (albeit with unease) it was the best way to manage a project. Years ago now, I started on my Agile journey and I always look back (as opposed to never looking back).
I look back and see software development projects in analysis paralysis, getting screenshots pixel perfect before starting a line of code. I look back and see dissatisfied team members ready to lynch someone because all they want to do is build some software but can’t because a committee needs to sign off on a document the size of War and Peace. It used to be a trying and tiring way to deliver software. It’s not like that these days.
I love what Agile has done for the teams I work with. I also love talking to new people to talk about their Agile experiences, learning from them and imparting some of my knowledge too where I can.
While I believe the Agile is by far the better way to develop software, it is definately not about getting to a happy point by ticking a few boxes, reading a book or two on Scrum or Lean, sticking up a task wall and littering it with cards and then calling for pizza because your work is done.
There is alway room for improvement. The very first sentence of the Agile Manifesto is “We are uncovering better ways of developing software by doing it and helping others do it.” I’m pretty sure there is very very few people (if any) out there that can boast “You know what? We uncovered the best way to develop software and we don’t need to improve any more.”
Continuous improvement which is generally covered under the Lean software development banner actually means improve continuously. Curious… so why is it that many get to a point of Agile saturation and then stall?
I said earlier, I look back often. One of the main differences I can see between starting an Agile adoption journey and being a few years in is that there may be a missing impetus of what Agile really means. It certainly would be useful exercise to have another look at the Agile Manifesto and its values and make a comparison on how aligned Agile development teams are to it. Personally I’d review the Lean software development principles too while I’m at it.
This is something I’ll be revisiting soon with the teams I work with… just to give things a nudge in the right direction.
I’d be interested in anyone else that has suggestions for rekindling the Agile fire.
leave a comment