In case you’re affiliated or acquainted with people from an IT firm, you’ve probably heard the term ‘Agile Software Development’ or ‘Agile Development Methodology’. ‘Agile’ itself is a compound word, which refers to a group of strategies applied to speed up and optimize the creation of quality products. Scrum can be defined as one of these strategies and we can also call it the winner, because majority of Agile development teams prefer it over others.
Isn’t Scrum something of Rugby?
Yes, indeed it is. Although the Scrum of software development does not literally involve running forward and passing the ball back & forth among teammates, the overall process can relate. You can assume the players as a team of developers and the ball is actually the project under development. The idea revolves around teamwork, i.e all members of a team have to provide an input in order to reach the goal. Failure or success, the whole team is mutually responsible.
Scrum is a technique that is rather spontaneous in nature. It does not involve a predesigned step-by-step plan of action to reach completion. It promotes flexibility, innovation, constant change and generally being open to unconventional solutions. Technically speaking, it is not as random as it sounds as it does actually provide a framework for organizing and scheduling work. However, it is a malleable framework that is adaptable to varying needs of the client and progressive ideas of the developers.
The Principles of Scrum:
Following the rules of Agile development model, Scrum approaches projects in an iterative and incremental fashion. The project is divided into a number of ‘mini projects’; these mini projects are in fact the ‘Sprints’ of Scrum. Each Sprint is a complete life cycle on its own, having a planning, implementation, deployment and review phase. The length of each Sprint has to be identical. Information discovered or lessons learned at the end of each Sprint are to be utilized for improvement in the next sprint, unless and until an optimized final product is achieved.
Precisely, Sprints are all about exploring a variety of options, trying new things and then moving forward with what’s practical. There are no restrictions or the need to follow strict guidelines. This implies that we do not decide/assume an outcome at the beginning, and just let it take a natural course instead. The mean length of a sprint is 2 weeks on average; it should be at least 1 week and not more than 4 weeks. Projects that hardly last 2-3 months are eligible for 1 week sprints. Medium sized projects ranging from 6-12 months are best suited for 2-week sprints. Finally, gigantic projects that go beyond a year can go for 3-week or 4-week Sprints.
Each project has 3 categories of stakeholders: the Product Owner, the Scrum Master, and the Development Team. The Product Owner is always a single person who is in charge of all the work carried out by the developing team. All the members of the development team have the same level of authority and therefore each of them is subject to tasks of a project manager. Whilst the product owner and developing team handle all the technical details of a project, the role of the Scrum Master is another story.
The Scrum Master is not equivalent to a boss, leader or manager in any way. Honestly speaking the person who takes this position can be perceived as a regular annoyance. He/she is accountable to make sure that you are keeping up with the Scrum/Sprint schedule. In spite of the nagging, everything they do is in the interests of the team and their client. They make sure that the team isn’t procrastinating or lagging behind, and being productive at all times.
The Scrum Master must keep track of time + resources used, see if everyone is justifying their role in the process, identify obstacles, motivate the team, and maintain an energetic environment. The ‘Daily Scrum’ is a short meeting held everyday where the developers coordinate on different aspects of the ongoing work. This is where he/she is supposed to discuss impediments or any issues with the workflow. A competent Scrum Master is highly observant, a confident orator and immune to hate.
The Product Owner has to set the standards of developing a product and describe the overall objective. Everything from there has to be configured and controlled by the Development Team. The Scrum Master tries to speed up the developing process to avoid missing deadlines, accumulating technical debt and wasting valuable resources.
Fundamental Components of Scrum:
PRODUCT BACKLOG – The complete list of product requirements and the single point of reference for any changes made.
SPRINT BACKLOG – A list of selected/prioritized items taken from the product backlog to work on during a sprint.
PRODUCT INCREMENT – The collective output at the end of one or more sprints.
SPRINT PLANNING – A meeting where the work plan of a sprint is mapped out and roles are assigned within the team.
DAILY SCRUM – Usually a 15-minute meeting at the start of the day where everyone gets on the same page and sets out tasks for the next 24 hours
SPRINT REVIEW – A meeting at the end of a sprint where the product owner analyzes and communicates the progress and upcoming targets.