SCRUM framework from my eyes and my experience

Introduction

Hi guys, I am Jasmina Petrovska from Skopje and I work at Keitaro as a project manager. Additionally as part of my duties here I am responsible for the end-user testing of the deliveries and writing the test specifications for each project. I like to read books, ride my red bike and sneakers are my passion. The biggest achievement in my life is my son Maksim and I really enjoy the time spent with him. And while we are talking about achievements, this is my first blog post ever, so I hope that you will like it and find it useful. if not please keep that to yourself hihihi 🙂 Just kidding.

What makes a project successful?

The answer is very simple, the team standing behind the project. If the team acts as a whole, the project will be successful from the beginning to the end. Of course, the agile methodologies are very helpful while executing projects and they are making a clearer understanding of the process. Imagine it like this: you and your friends are playing cards in teams, so the goal of each team is to win the game. In order to win the game, you will have to be well synchronized with your teammate, trust him/her and recognize his/her actions and reactions. 

It is pretty much the same while executing the projects. You are part of a team, the team shares the same goal to make the features into a real product. In order to achieve that goal, the team must understand the requirements and the processes well, and if some of the team members need more details, we cannot go to the next level until everything is clear for everybody.

I joined Keitaro 3 years ago and since I am here (and before that) we have been using the agile methodologies for executing projects, mostly with the Scrum framework. Since we are working on many clients’ projects we make sure to adapt our scrum framework to the clients’ needs, so today I will share my experience of working with an adjusted Scrum framework. 

Project Phases

Initiation Phase 

From the initiation phase until the final phase, the team is involved in the project. We start the initiation phase with a detailed explanation of the project needs. The first step of the process is a technical proposal, which after being reviewed from both sides, serves as a starting point for the creation of a detailed project plan. The team then creates the Technical Solution, a document that presents how the team understood the requirements from the client (the product owner). Once everything is clear for both sides (development team and the client team), we move on to the next stage –  creating the product backlog for the project. 

The most important thing in the initiation phase is clarifying the requirements. The best approach here is for each requirement to be documented in the product backlog with all details needed for the implementation, so each team member is aligned. As I mentioned above, most of the projects we work on are commercial and they are fixed price project types, which means estimations for each requirement are added in the initiation phase according to which the time plan for delivering the project is created.  

Kick-off meeting

The purpose of this meeting is to present the project team and their responsibilities, as well as the project goals and approaches that will be used for achieving the goals. During the meeting we are discussing the work processes that will be used during the implementation, present the priorities and clarify a list of dependencies. All involved parties should be part of the kick-off meeting.

Sprint planning and Sprints  

So, once we have the Technical Solution, the requirements, the estimates, and the timeframe we move on to the next stage of the project planning – Sprint planning. In most of our cases (since we have a predefined project time plan), we split the product backlog into the sprint backlog. The usual timeframe for each of the sprints is 2 (two) weeks, but this can be also adjusted. For example, a few months ago we were engaged on a very interesting project for the City of Toronto, and the team worked in one-week sprints.

The sprint backlog is ready now and  we move on to the execution phase of the project. Sprints make projects easily manageable, allow teams to ship high-quality work faster and more frequently, and give them more flexibility to adapt to change. Each sprint is covered with sprint planning (for example which task should be delivered first, are there any dependencies between the tasks from the sprint, assigning the tasks to the team members), daily scrum (a short daily meeting that literally covers 15 minutes of the development workday, and each team member presents their status related to the tasks from the sprint, the progress, and if there are any blockers), and sprint review (demo-presentation of the current sprint presenting the sprint deliverables). As I mentioned above, most of the time, we are using the adjusted framework according to the clients’ needs and the estimated time, but one thing is always the same, each sprint starts with sprint planning and ends with a demo presentation. Once the product backlog is covered and executed through the sprints we announce the final phase of the project. 

Final Phase 

In this Phase the UAT period starts. UAT presents User Acceptance Testing and it is assigned to the client. In this period the client tests the deliverables, and if there are any issues they are communicated through the Task Management application with the team and through the point of contact – usually the scrum master or the project manager. The team then reviews and fixes the reported issues and the UAT is closed. The UAT timeframe is determined according to the project complexity. Sometimes it takes a week, sometimes two. 

Acceptance Certificate

The project closes with signing the Acceptance Certificate document by the client. This document presents the collaboration between both sides and the acceptance of the deliverables by the client. 

Lessons Learned Session

In this session, the responsible team is gathered and each team member presents what was good, what not that good and what can be changed for other projects.

Beside all these processes and techniques that are well known, the project manager or the scrum master must recognize the team’s needs and their behaviour and to know how to act in certain situations. 

How are we sure that the deliverable fits or is above the expectations of the clients?

While the team is executing the requirements from the sprints, as part of each requirement the team is also working on the code documentation and the unit tests. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits, for example unit testing finds problems early in the development cycle. 

Additionally, we use CI/CD for all environments using Docker and Kubernetes. We build custom Docker images based on the dependencies of the project, and we integrate Github webhooks to subscribe to events when a certain release is made, in order to trigger the build and deploy process.

As part of each delivery, we also prepare a test specification. The Test Specification consists of a test report document that presents the status of each feature created for the product and test case, a document that explains the steps for using and testing the features of the product.

Additionally, we create a user manual, a document prepared for the final users in order to make an easier and better understanding of the product. 

Why did I become a project manager?

To be honest, I never planned to become a project manager, I just wanted to change the previous company and the working environment that we had there. How did  I come to Keitaro? 🙂 3 years ago, there was an open position in Keitaro, if I remember well, they were looking for a person who would stand between Keitaro’s DevOps team and the opened tasks on GitHub, by following the progress of the tasks. I held that working position for less than a week, when a commercial project came and I was assigned as a project manager. 

As I’ve already mentioned, in Keitaro we use agile methodology for project management, so each procedure needed for managing one project was new to me and at first I was totally lost. In the previous company my position was academy manager, so I had the chance to work with a lot of students and teachers and to manage all items needed for the successful development of the courses that the students took.  But here in Keitaro, everything was totally different, starting from the communication with the client, daily meetings, working with deadlines, managing risks, understanding the terminology that my team used and so on. Everything seemed like a scary movie to me. But in each scary movie, there is a hero helping others. In my case, my hero was the team that I worked with on my first project. They were open-minded and I really don’t know how, but they always managed to find time to help me. Believe it or not, sometimes they drеw to me how some open data portal is functioning. If you are asking me how successful my first project was, I will say it was a big damage… and how successful the project really was, ask my managers 🙂 hihihi. As time passed, I started to enjoy working as a project manager and I am still not sure if I like that profession or I just like the team that I am working with. Now I can understand what my colleagues (developers) are talking about, of course not everything but I started to use the same terminology as them. 

So in one sentence, I didn’t plan to become a project manager, but I grew into one.

Thank you for reading this blog and stay posted for my next one. Who knows, maybe I’ll discover I like writing articles as much as I like working with SCRUM.

P.S. Feel free to share some of your SCRUM stories in the comments.