I am a Scrum Master

I took the Professional Scrum Master I exam. Why? Because I want to be more agile. I have a lot of startup experience on almost every front, but as I tell people, I don’t do the programming. So, I decided to check out Scrum and certification.

Ultimately, I chose Scrum.org’s certification. The exam is based on the Scrum Guide, a short 11 page PDF. You might think, the test must be easy then. The problem is, there’s a lot of lateral thinking applying Scrum to various scenarios in the test. Just by reading the guide, you won’t be able to pass the exam without applied experience.

Thankfully, I chose to buy a course on Udemy. Without the course, I would not have passed the exam. The first time you take a practice test, you get a taste of understanding how well you might do on the test. As someone without formal product and technical experience, the Udemy course echoed things that I understood subconsciously, it gave me some of the vocabulary I really needed, and it taught me some basics that I didn’t have.

I’m sure I’m not the first to notice this, but the first rule of Scrum is:

there are no rules

Ultimately, my biggest takeaways for someone who has never been a part of a Scrum team is that I don’t actually agree with Scrum in its purest form. It seems to be an ideal that is very hard to achieve. But by the sounds of things, most teams use a modified Scrum that best fits their team structure.

  1. As the computer science degrees become saturated, you have a wide array of programmers with ability. Scrum is dependent upon excellent developers who can work together and independently. Strategy and execution. Until more recently, developers have been people passionate about CS. With the understanding of being a lucrative job and growing demand, more developers with a wider range of skill emerge. It leaves behind people who have a less lofty aptitude but are great workers.
  2. Strict time-boxed scrums seem untenable. There are too many variables to consistently maintain the precise schedule of these events. From what I’ve been told, most companies may start with this intention, but it doesn’t survive.
  3. Tech debt. The one thing that Scrum says is that tech debt is inevitable, and you must strive to minimize. I believe that tech debt is inevitable. I also believe that if you don’t have responsibilities in place like Architects and teams are just going to “collaborate” and integrate as they go, you have greater tech debt than you would otherwise have.