Ron Jeffries has posted a nice article on CSM Certification Thoughts containing several excellent diagrams describing some of the forces that are in play when it comes to Scrum certifications (or any other Agile certification for that matter).
There are both positive and negative opinions of CSM Certification in the industry. In my view, a ‘certification’ for completing a course is questionable and misleading. If anything, its a ‘Certificate of Course Completion’ . Importantly, CSM Certification does not demonstrate an individual’s experience and skill with Agile and definitely is not reflective of an individual’s mindset for Agile.
But let’s face it, as individuals we love our certifications as it provides some sort of achievement and recognition. But attending a 2 day training course does not turn you into an expert.
The Agile Alliance position on certification is clear
[…] employers should have confidence only in certifications that are skill-based and difficult to achieve. […] Certifications such as Certified Scrum Master and DSDM Foundation are knowledge-based and easy to achieve. […] The position of Agile Alliance remains firmly that employers should not require certification of employees and that skill needs to be acquired by practice on agile projects not by training alone.
Ron’s article highlights that the core benefit of CSM certification is that you will have ‘CSM-Trained People’, however, this does not guarantee success as illustrated by his diagrams.
I think CSM Certifcation courses are one means to achieve the goal of training individuals and providing minimum competence. I have attended both a CSM and CSPO class and believe the courses are well put together and are educational. However, translating this knowledge into practice is a much more daunting task. I think one of the main challenges with Scrum is that there is no standard or ‘best-practice’. There are many different ways Scrum and Agile methods can be applied. After all Scrum is just a framework within which things happen, and its up to the innovation and intelligence of the team to fill in the gaps.
Speaking from experience, I agree with Ron’s comment that
Troubled projects do generate some demand for coaching
As an Agile Coach I have been called on many times to help troubled projects. Most of these projects didn’t have the right fundamental training and/or coaching required. Ongoing training and engaging an experienced Agile coach is necessary to ensure effective adoption of Agile. I have been down some dark holes in my IT career, but I have learned a lot over the years which has enabled me to be a better Agile consultant and coach so I can help teams and organizations with their Agile journey. Even with 6 years of Agile experience, I am still continuously learning.
For Scrum success, what is more important than ‘certifications’ is that organisations are committed to Agile, provides the environment, training and the culture for Agile to flourish.
Last week I attended the Agile Australia Conference. I will post a conference report soon, but thought I would share the 2 main takeaways I had from the conference. One is the DevOps movement and the second is Continuous Delivery.
DevOps is a new movement seeking to achieve the business need for rapid delivery of software products while maintaining the stability of live environments. It uses two approaches: first, promoting closer collaboration between development and operations; second, applying practices shared with agile (collaboration, automation, simplicity, etc) to operations processes such as provisioning, change management, and production monitoring. It encompasses culture, processes, and tools – all supporting better communication, faster feedback and delivery, and more predictable outcomes.
With continuous development of working software, we need to get the changes into Production as quick as possible through Continuous Delivery so we can shorten the feedback cycle and so the business can maximize the ROI.
If you have been following my blog, you will notice that Dilbert comics seem to jolt me into writing a new entry. In this comic, the pointy-haired boss actually makes a wise comment when he says “Just break into whatever size groups you think make sense”. For Agile teams, what make sense is small teams. I like how Amazon.com refers to their teams as “two-pizza teams” meaning that the team can be fed by 2 large pizzas. If they can eat more than 2 pizzas, then the team is too large.
Scrum guidance states that team sizes should be between 5 and 9 people and this is no co-incidence to the paper The Magical Number Seven, Plus or Minus Two. Smaller teams are more effective because people can’t remember more than 7 things at a time – team members need to know what each other is doing. There are many benefits of smaller teams so if you need to scale up a project, add more teams than making existing teams larger. Remember to keep it to two-pizzas
What is agile? How would you define it? Is it a set of practices? Is it a way of management? We often say agile is a culture and a mindset.
To me Agile is not something you do, but something you are. If you don’t subscribe to the Agile values and principles and only follow the Agile practices, then you are certainly going to miss the point of Agile and the benefits it can bring to software development. Agile is not a destination, but a journey. Teams can always get better at what they are doing to deliver overwhelming business value to clients. Mike Cohn has some nice quotes:
- Agile is not something you become, it’s something you become more of
- Agile is not an end-state
- Paraphrasing: ‘Success’ with agile should mean that we are better off than we would have been without it [continuing waterfall ways]
Jim Highsmith has a great post on this topic.