Agile Scrum methodology is widely used in the software development industry and illustrates very cool features which have had many companies organize their projects better. Scrum is not difficult to master however the change in working culture is always very challenging. One of the key ladders to master scrum is by practicing Scrum every day just as how the proverb ‘Practice makes man perfect’.
Scrum is a framework (Scrum Guide, 2009, Ken Schwaber and Jeff Sutherland). It is widely used in many Software DevOps companies. The fact that these companies use Scrum, one may perhaps conclude these Scrum teams are focused to operate in an agile method. Hence, it is important we first define what exactly you mean by being agile before we discuss SCRUM. It is almost impossible to define Scrum without first defining Agile, since Scrum is one of the Agile methods, and the most popular one.
Agility can be defined as the ability of a company to swiftly adapt to a continually changing environment and to grow with it. Adaptability of any systems that involve more than one individual is always a challenge especially in a professional environment. However, over the years many organizations have realized its value and have forced implementation of Agility to enjoy its benefits and efficiency it generates. It is a very common approach in software development and has gained popularity in modern times. Agile principles are built from the Agile Manifesto. See below the text from the Agile Manifesto (Agile Alliance, _Web Content_, 2001).
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
The authors have documented twelve principles of Agile together with the Agile Manifesto. These principles support things like trust, self-organization of teams (A Scrum book, 2019, Scrum Pattern Group), collaboration between teams, appropriate working schedules and continuous delivery. Agile inspires people to adjust their working model in line with the agile principles as listed in the Agile Manifesto.
SCRUM, as previously mentioned is an agile framework (Scrum Guide, 2009, Ken Schwaber and Jeff Sutherland). There are various Agile methods available and SCRUM is identified as one of the most widely used framework. SCRUM allows practitioners to inspect actual working software after every sprint and decide whether to release as is or continue with another enhancement, which is yet again another sprint.
1. Scrum is formed based on easy practices however encourages small changes in how you organise your project activities. However, many non-software development professionals claim that Srum is designed only for a software development area of work. This typically leads to adapting to methods whose goal is hypothesis falsification.
2. The constructive (or interpretive) worldview considers implementing a custom Scrum framework to be a corporate affair and can be implemented only with specialized tools.
3. The participatory (or transformative) view holds that research is meant for bringing out transformation in the mindset and uses the best resources you have and has an action agenda to stimulate change through intervention.
4. The practical view accentuates the reality as “what is practically useful and whatever works” The emphasis among logicians is on the problem, and therefore they use all available methods to understand and board the problem.
The lexicon and procedures of SCRUM are easily understood if referred to the SCRUM Guide. However, since we are talking about implementing SCRUM in personal projects, we shall cover some features of it along with how to implement the same. We shall not cover all the aspects as it can be easily understood if you read the SCRUM guide and this paper is intended not to translate the scrum guide but to build one.
One of the essential elements of Scrum is a sprint. A sprint is time boxed. A pre-decided time frame in which you are committed to complete a certain amount of work. Working in a two-week sprint is most commonly practiced in organizations. However, as we would like to tweak the process to our personal projects, we may consider working in a three- or four-week sprint. Although a two-week sprint is ideal, even in terms of measuring what you have achieve the author here is relating a busy schedule just how he indicated in the first section of the paper. The Scrum Guide promotes a time period between one week and one month. However, for a personal projects or routine, a sprint could be a day, a weekend or two, or even a four-weekend sprint depending on the nature of your project.
A backlog is basically a ranked to-do list. Every project has various tasks needed to be completed to achieve the scope of the project. Ideally it is ranked based on priority however the norms can be decided by the team. The Scrum guide focusses on priority however for personal projects one could also have its own norm.
A primary element of SCRUM is Sprint Planning exercise. Sprint planning is at the beginning of every sprint. During a Sprint Planning session, the team analyses the highest priority backlog tasks and details out estimates to complete the task. Estimate in terms of time to complete the work. For personal projects one should also detail out estimates along with the exact time when a should be completed. Although the Scrum guide specifies a task needs to be picked up only upon completion of one, here we are tweaking the process to fit our needs. The planning exercise should not be too long or too little, however needs to be appropriate enough to do justice to scope and complexity of work to be achieved.
As per the Scrum guide at the end of the sprint, the team assesses and validates the work completed in an event called the Sprint Retrospective. As per the guide a team member answers the following questions in this event.
What went well?
What went wrong?
How can we improve in the future?
The focus here is to achieve an actionable list of lessons learned objects that need to be actioned to bring improvements as you proceed. Although this is a very important event, a general tendency is to ignore this event. The author strongly emphasizes that this event should take place. Instead of having this session after every Sprint one may have this after two or three sprints. But not having one is a problem. The author believes there is always a scope for improvement, and one should spend time to recognize these actionable improvements in your personal projects.
Let’s say I would like to write a seminar paper as a part of my PhD and document my research which I’ve worked hard last couple of months. I need to put together all topics to be covered in my paper, agree on the approach how to write the paper and fit it into the format provided by my University. I want to finish it before end of summer because I will have more papers and publications to write as I proceed with my PhD studies. I don’t want to be overwhelmed with too much left over as I enter winter semester.
The first step I need to do is produce a backlog for the project: a list of everything I need to do. Theoretically, my backlog looks like this:
Upon having my backlog items outlined, I need to select a timeframe for my sprints. The only time I can devote to this project is 10 hours a week since I have my other personal projects which will also be a part of the sprint. However, for simplicity sake the author chose to pen down only the tasks belonging to his seminar paper for ease.
The first thing I do on a Friday evening is Sprint Planning. I look at the highest priority tasks in my backlog and estimate how much time they will take. “Put together my research data into a common format” is about 10 hours activity alone. I must determine what items will be a part of the paper and start documenting it. I will break this down into smaller tasks and align a time frame against each of these tasks to eventually achieve my main goal. By the end of the sprint I will have the exact date I need to document in my research paper and in the agreed format.
Since my sprint is completed, lets retrospect it.
What went well?
1. I have my research data in the format I need to present in my seminar paper.
What went wrong?
1. I need not prepare the format from scratch however use the template provided by my university.
2. The research data gathering could have been gathered is the correct format right from the start so that I need not spend additional time to put the date together.
3. I had to make an unplanned meeting with my student advisor to understand a basic expectation of the university.
How can I improve in the future?
1. For all future seminar papers, data gathering should be done in a correct format.
2. Use an analysis tool to gather the data so that I don’t have to spend time to deduce understandable interpretations from the data, rather than the tool doing it itself.
I start with Sprint Planning again and now I consider the next priority task from my backlog and follow the same procedure as that of Sprint 1.
Prepare a scrum board to document progress of every sprint. Although it may sound unnecessary however even on your personal projects this board will help you track your progress and measure your success. Below is a picture of how a personal scrum board may look like. You need not make use of a tool like Jira, Azure DevOps and may use the back of a door or simply and empty wall in your dining room to build a Scrum board.
Although Scrum is a professional framework widely used in software development, it can be easily transitioned. It lists down some key best practices that help you organize your project better. It supports not over planning of your projects and provides a platform plan as you proceed. It supports you to bring changes in your scope or rearrange your project milestones at any time during the life cycle of the project. It is an easily adaptable concept and needs a basic change in mindset to implement this framework in any environment. Although Scrum suggest some key tools to organize your scrum framework once could also leverage home resources to practice Scrum artifacts.
Author: Mohammad Azhar Khwaja, under the supervision of Dr. Grigory Sergeenko.