My journey to becoming a Certified ScrumMaster

Before I joined Manifesto as a digital producer, I was new to the world of digital. I had some project management experience but I knew that I would need to invest a lot of time and learning into understanding how to run big projects if I was going to become a successful project manager.


In at the deep end with Scrum

What drew me to Manifesto in the first place was their keen interest in their employees. I knew that they were just as interested in my career progression as I was. On my very first day, I was thrown into a new way of working: Scrum. I quickly picked up the basics (daily stand-ups, demos, retrospectives and planning meetings) working on projects for The Children’s Society, Cabinet Office and Cancer Research UK among others.

Why Agile?

Historically, the most common methodology for managing projects has been Waterfall and many larger organisations still favour this approach. There is a lot of risk involved with waterfall projects but Agile, a competing project management style, is on the increase and with good reason. Agile allows for quicker releases because it focuses on delivering small pieces of value that can be used right away. This also allows the requirements to change throughout a project based on what you learn.

Scrum provides a framework for working in an Agile way. The process is very transparent with daily stand-ups, sprint retrospectives and product demonstrations.

Going pro on the CSM course

Working within the Scrum methodology can be tricky to grasp at times. I knew at some point I would need to gain more insight into the whole process and become a Certified ScrumMaster, something which Manifesto were only too happy to put me forward for in February this year.

For 2 days, 16 of us sat in a room together and we learned all aspects of the Scrum process. With our trainers Matt Roadnight and Manifesto’s very own Jim Bowes, we discussed everything from who is part of the development team to understanding how to scale Scrum for larger projects.

Matt and Jim explained everything to us very clearly and concisely and, most importantly, in a fun and practical way. We spent most of the 2 days standing and working in teams as we went through various different scenarios trying to understand how to break the Agile/Scrum processes down.

Practical Agile

You’re probably thinking ‘that’s great but how do you apply this to your projects?’

Before a project starts, there will be a visioning session with some members of the team. This is a chance to gather all the information about what the product needs to do for the client/business. It’s also a chance for the team to feedback on any technical limitations that might arise during development.

During the CSM course, we partook in a mock visioning session to learn how to ask the right questions of the client to get their exact needs from them. The Product Owner leads on defining the product and what the next most important feature is and the ScrumMaster supports them in this by facilitating the Scrum process.

Another key thing I picked up was in relation to understanding where the impediments are within a project. It could be that you have lots of testing but only 1 tester. A good ScrumMaster will see where there is a skill gap and make a plan for filling it – whether that is cross-skilling the team or finding budget to hire a new resource.

Something I use on a day-to-day basis in running projects is the understanding of how to slice stories into smaller pieces of work. In order to have a potentially shippable product at the end of each sprint, the ScrumMaster and Product Owner work together to break a stories down into smaller pieces which still deliver value to the customer, the team usually takes on of the order of half a dozen per sprint.

Key learnings from the CSM course

Some of the key points I learned during the 2 days were:

  • The agile way of doing things is an incremental and iterative process where you deliver a potentially shippable product in each sprint for the client and iterate over it to make it better in the next sprint. This is favoured over the approach of waterfall where something cannot move on until the previous phase has been completed and nothing can go live until each element has been done in turn.
  • With waterfall the longer the project the higher the risk. With Agile methods there is continuous inspection which allows you to adapt to changing requirements.
  • Scrum is product based, not project based – meaning that the product itself is the star of the show and not the managers, developers or stakeholders. At the end of each sprint, there is a potentially shippable product that can be released if the Product Owner so wishes. This does mean some things handled in other project management methodologies (such as budgets) happen outside of Scrum.
  • With Scrum you can release value much more quickly – whether it is value to the business or to the end user.
  • Scrum promotes self-organisation meaning that the team itself takes responsibility to deliver a certain amount within a given sprint. The Product Owner and the ScrumMaster do not decide for the team how much work will be done. The development team alone decide this. However they work from the priority set by the Product Owner.

Exam stress

A few days after the course finished, I sat down in a quiet room and took the test in order to become certified. I finished the test and, rather apprehensively, clicked on submit. Waiting for the results page to come through was sheer agony. However, it was all in my head and I was delighted when I saw that I had passed with flying colours, making me a Certified ScrumMaster (CSM)!

Iterating for success

Since the CSM course I’ve been referring back to my notes regularly to make sure I am following the main principles of Scrum. Agile is not always easy to get right but, with practice, I’m hoping to get better and better at it with each exciting project.

Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. Enjoyed your blog. Always good to hear agile training in action.

Sign up for the Manifesto newsletter and exclusive event invites