As the end of yet another year draws upon us (the less said about 2020, the better), I find myself locked indoors writing my second blog post of the month.

As the title suggests, it is to do with becoming a certified Scrum Master. I recently became one (after months of deferring it... because 2020).

I get it. You might not like Scrum, you might prefer Kanban, you might prefer Extreme Programming, or a leaner approach, or Scrum-ban, or your own alternate bespoke way of doing things. But the point really is that at the end of the day, we're all just trying to adhere to the values & principles set within the Agile Manifesto which aims to improve the Software Development Lifecycle.

I personally love XP practices, however it chimes in with something I once heard someone say which went a bit like... "If you can't do Scrum properly, then there's absolutely no way you're going to do Kanban or XP right". Which, makes sense. If you suggest XP at most places, they'll think you're on about an outtdated Windows operating system!

Scrum was developed by Jeff Sutherland & Ken Schwaber in the early 90s as a framework that allows people (or companies) to address complex problems, whilst delivering valuable products. Since then, it has been used extensively both within & outside of the Software Development world.

The reason why Scrum works great as a first step towards trying to adopt Agile methodologies right (particularly for companies who have only ever known a waterfall/long-term project plan way of working), is because it is quite prescriptive & rigid (in comparison to Kanban or XP), whilst still adhering to the Agile Manifesto. This is both in terms of how development teams are constructed, as well as the events that must occur in order to fulfill two of the three pillars of SCRUM - Inspection & Adaptation.

It's rigidness makes it harder to ultimately get wrong but also simultaneously enforces that the manifesto for Agile Software Development is fulfilled. It is through enforcement of the Scrum framework, that leads to more frequent opportunities to inspect & adapt the (software - in this case) being built, which creates more frequent feedback loops... & this resonates with so much of the Agile Manifesto in its own right. Once this has been achieved, there is no longer a long-term plan in place that negates what people most often associate as the main attribute of a waterfall approach.

Playing devil's advocate... can you imagine trying to transition a company (tens/hundreds of staff) that has only ever known or worked with a waterfall approach, to an Extreme Programming approach? I can already hear the managers/stakeholders complaining about pair programming & developers spending time on tech debt/refactoring being a waste of time, in my head already.

So, what's the point that I'm trying to make? Well, it's that man, myth, legend again. Melvin Conway.

Conway's Law states that "An organization that designs a system will produce a design whose structure is a copy of the organization's communication structure" - which is by all means correct. It is often used when referring to software architecture.

But, I think we sometimes forget that the design of the system is not only referring to how we architect a solution technically, but also how the development team works. Software Development is not just about technical solutions & writing code. We exist to solve problems, real life problems. Sometimes those problems can be solved with only a technical solution. However most of the time, people are part of the problem both within & outside of the development team. It is difficult for businesses to change how they work, to move out of their comfort zones, or to work in a different way to what they deem has succeeded (sometimes) for them in the last forty years.

For example, a development team with more efficient processes (to keep this short, as this list could go on forever), can be argued to correlate with a better design of a system. How you might wonder? Well, give a team more autonomy over technical decisions & find out for yourself (it's what you pay them for after all, right?). Give a team autonomy to actually address technical debt, monitor your uptime metrics, bug metrics & find out. Accelerate is a great book that shows how these types of practices benefits not just development teams but businesses too. So to conclude, sometimes, poor software development delivery can be a symptom of poor or unoptimised ways of working, enforced within a business.

Change - or Digital Transformation - takes time. As with a lot of change in life, you have to take things step by step & slowly. Most people don't quit smoking overnight. You don't lose weight or gain muscle overnight. This is why I believe it can be argued that being Scrum certified, can put you in a stronger position as a Software Developer to truly help drive change within businesses. It may even start with you making small tweaks to how your Development Team do things. Scrum provides a stepping stone to allow companies to walk with an Agile approach, before they can run.

So, if this interests you... get studying for your PSM1! The only downsides are that the certification costs $150 per exam sitting (your employer might cover this), the pass rate is 85% (but it's multiple choice) & you only have 1 hour to complete 80 questions (you need the time, trust me... mock exams will fool you).

Here are my tips on how you can pass it first time:

Print the Scrum guide & highlight the key points.
Read the Scrum guide again & narrow down the key points. As this is your second read through, you might be able to make your selections from the guide, more concise.
Create your own document, possibly using Notion so that you can also create a hyperlinked table of contents & categorise the important points you highlighted (it is an open book exam, so whilst time is very sparse, it may come in useful & every question counts).
Do the Scrum Open Assessment. Anything new that you feel your notes do not cover, add to your notes. Keep doing it until you are scoring 85%+ regularly, even if you are having to refer back to your notes.
Do MLapshin's Preparation Quiz in Real Mode, this is more of a representation of the real exam. Once again, add any new information to your notes that you may have missed out from the SCRUM guide (Hint: You get examined on things that are not within the SCRUM guide such as burndown charts, etc).
Once you are consistently scoring 90%+ on both the SCRUM Open Assessment & MLapshin's 80 question quiz in Real Mode, consider purchasing a subscription to a real exam simulator or a Udemy course with lots of mock questions. You can find the available options via Google. This might seem like a pain, however given that the exam costs $150, you'd rather spend $10 on top than another $150 if you fail first time round.
Do your new mock exam numerous times, repeating the same pattern of updating your notes, until you are comfortably getting 90%+ on all of the mock exams without needing your notes too much.

As with all multiple choice exams, you eventually start noticing patterns. However despite this, I did find the real exam questions significantly more difficult than any of the available online mock exams. The main reason for this was because questions were longer & unlike when you're sitting a pen & paper exam, you can't underline the important bits, so you waste time trying to read & understand the questions properly!

If you have 80 questions to complete in 60 minutes, that means you have an average of 45 seconds for each question. If the long questions require you to re-read them at least twice, then you aren't left with much time to ponder on the correct answer. This may be even more difficult if English is not your first language. But remember, practice makes perfect! (But nobody's perfect so why practice?!)

If you do decide to sit the PSM1 exam & my tips help you pass, please let me know in the comments!

Good luck, thanks for reading & bring on 2021 (I mean... it can't be any worse than 2020... can it?)!

# PSM1

Passing your PSM1 & becoming a certified Scrum Master.