Scrum is everywhere in software development, so much so that many consider it the default way teams work. My experience has borne this out. In all my many years of software development, all but two of my roles used Scrum. What’s more, often the teams never even used the term “Scrum”, they just assumed people knew what it was. That’s how much it dominates.
However, I also noticed that every team did Scrum a bit differently. This got me interested in the ideal version of Scrum. So I decided to learn more by enrolling in Scrum.org's Professional Scrum Master Certification (PSM I) course. This wasn’t just about curiosity; by learning more, I could become more effective and help guide teams to use Scrum more effectively.
This was a two-day course, and it was eye-opening. Our instructor was great; he had a knack for striking the perfect balance between engaging presentations and interactive learning. Through a blend of group activities and case studies, he kept us immersed in the material and let us practice what we learned. I really liked how he balanced all this with a rigorous presentation that showed Scrum as the logical outcome of key observations about software development. All this gave us a deeper appreciation for its principles, and helped us understand what the elements of Scrum -- which many of us took for granted -- were meant to achieve.
If I were to cite a favorite takeaway, it would be the concept of an Increment. Here is how the Scrum Guide defines an Increment:
"An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. To provide value, the Increment must be usable."
Our instructor brought this definition to life by emphasizing that Increments have to deliver value to end users. In short, if users don’t notice a product change at the end of a sprint, then the team didn’t deliver an increment.
For example, imagine a team wants to add a new feature to their application. This feature needs a user interface and an API. While the API is essential for the feature, it’s invisible to users. Now, let’s say this feature will take 2 sprints to complete and the API and user interface will take equal amounts of time. If the team works on the API in the first sprint and the user interface in the second, then they are not working in Increments. Why? Because by the end of the first sprint, they have not delivered anything the users can use. Rather, to work in Increments, the team should divide the work so they can deliver a useful end-to-end portion of the feature (user interface and API) in the first sprint, then the remaining end-to-end portion of the feature in the second.
This gives users something valuable they can use at each sprint. It also means the team could get feedback on the feature by the end of the first sprint, rather than having to wait for the end of the second one. This in turn means teams could pivot sooner if they need to. Scrum thrives on feedback, so the ability to pivot quickly is essential. Shorten the feedback cycle and you increase your team’s effectiveness and the value you deliver to users.
Jumping ahead, I had the chance to put this into practice shortly after the course. I was given a work item and the autonomy to decide how to approach it. The work item was too large to be done in a single sprint. So I divided this into Increments, each of which had value to the user. I then worked on and delivered an Increment. At the end of the Sprint, we had noticeably different software that offered a tangible benefit to end users. But there was also another unexpected benefit.
I was told that I would be moving to another client. Now, in other teams in which members shifted while there was work in progress, this meant having Knowledge Transfer meetings to ensure people understood what the partly-completed work did and the full context of what it was meant to achieve. However, because I was working in Increments, the portion of work delivered was complete in itself, and the remaining work was easily understood without the need for context. The hand-off was painless.
Back to the course. The training course included 2 chances to take the certification exam. Passing this exam would make me a certified Scrum Master. While the exam was open-book, it was long enough that I had to be able to answer many questions based on my knowledge. Fortunately, our instructor taught us well, and I passed the exam on my first try. Shortly after, I received my certification. I was now a certified Scrum Master.
I’m very happy I took the course. I have a deeper understanding (and appreciation) of Scrum, and I have a certification that lets others know I can help on their Scrum journey. I know the challenges Scrum is meant to solve, and the conditions under which it thrives. For those considering taking the course, I say do it. Not only will it make you a more effective team member, the certification will also enhance your marketability. Not bad for a two-day course and a one-hour exam.
