Blog | Project Management Software | Easy Projects

All About Agile Methodologies: SCRUM

Alexandra Nazaruk

What is Agile?

Agile is the new black. You hear about it everywhere, and it gets worse: you hear Scrum, Kanban, and your head starts spinnin′.

That′s what′s happened to me, so  I decided to figure stuff out.

As you may guess, “agile”  has something to do with being quick, mobile and flexible. Indeed, Agile software development unites several methodologies that function on 12 basic principles that mostly imply “communication” , “adaptability to change”  and “continuous improvement” .

The Agile methodology principles are listed in what′s pompously called “The Agile Manifesto” .

Quoting  Martin Fowler, one of the initial signatories: “In February 2001 a group of seventeen software pundits got together in Snowbird UT to discuss the growing field of what used to be called lightweight methods.”   They did some heavy thinking and held a discussion on the tendencies and best practices of software development.

Dave Thomas, another signatory, gave a very curious interview, where he described the summit: “There were 17 people and everyone had their own ax to grind and their own particular viewpoint on what was best. And within a couple of hours, we′d come up with a way of working that let us discuss the principles behind what we were doing without going into the details.”   Here′s what they came up with:

We value:

That is, while there is value in the items on the right, we value the items on the left more.”  Sounds nice, right? Here′s the original:  http://agilemanifesto.org/  (you can also find the 12 principles there).

It′s important to understand the idea behind the very last phrase in the quotation. There′s a misconception that the Agile Manifesto creators rejected methodologies, planning and documentation, which is not true. On the contrary, they wanted the methodologies to respond to the reality of software development, i.e. to be open to change that is inevitable on all stages of the process, to guarantee effective communication between everyone involved and, ultimately, to deliver the software that really works.
The next step was forming the Agile Alliance, which issued the Guide to Agile Practices in 2011. It′s, essentially, a “comprehensive list of Agile practices” . You can go into further research  here.

Agile Methodologies

Agile methodologies are quite numerous. It′s important to understand that Agile isn′t just a methodology, it′s a group of methods united by some basic principles and common ideas. There′s also a slight difference between a “methodology”  and a “framework” . A methodology is a set of principles, tools, and practices which can be used to guide processes to achieve a particular goal. A framework is a loose but incomplete structure which leaves room for other practices and tools to be included but provides much of the process required. You can read more  here.

For your convenience, here′s a list to give you a basic idea (with links) :

You′ve probably heard about the last four, and you definitely heard about Scrum.

How Scrum Appeared

So, getting closer to the actual topic of the article: Scrum.

Ken Schwaber and Jeff Sutherland, the initial signatories of the Agile Manifesto, formulated Scrum as a way to incarnate the Agile principles in 1995. Both used what would become Scrum in their companies first.

Out of all the Agile methodologies, Scrum is probably the most popular and renowned one. This is why so many people confuse Agile and Scrum and find it difficult to distinguish between the two: Scrum has become the unspoken standard of Agile development.

It′s important to understand that Scrum is not actually a very detailed methodology, it′s mostly a framework that defines the main  roles,  activities  and  artifacts  in the process of software development. Most teams have to incorporate some features from other methodologies

How Scrum Works (on paper)

Basically, it all boils down to  iterations (also called sprints) – short periods of time (1-4 weeks; 2 weeks are probably the most popular/convenient duration), or  time boxes, by the end of which some piece of working software is presented. It′s not the final version of the product (mostly), but it′s something that can be demonstrated to the stakeholder. The whole project is a sequence of such iterations.

There are three main roles in Scrum: Product Owner, Development Team and Scrum Master.

  1. The  Product Owner  is a representative of the customer. He/she articulates what he wants to get from the product/feature and defines the guidelines for the team. For example, as a system user, he/she wants to see a report where all the payments can be found, sorted out by week, where on the left there would be an  “amount”  column, and on the right there will be the payment description; it should be PDF printable, etc. It′s called the  acceptance criteria, i.e. the requirements that have to be met for the project to be considered successfully completed (more  here). These criteria become the  Product Backlog Item  (see Scrum Artefacts). The items are prioritized based on the importance of the feature/ how difficult it is to develop the feature/ how much time it will take (more details  here).
  2. The Product Backlog Item gets into the sprint, and the work of the  Development Team  begins. The work is broken down into tasks, and each team member takes on some task based on their abilities.
  3. The  Scrum Master  is responsible for ensuring effective communication between the team members and between the team and the product owner (stakeholders), so that the team can just focus on getting their job done. He conducts the  daily Scrum meetings (see Scrum Activities). There are multiple ways of how a person becomes a Scrum Master,  here′s a nice post on how a Scrum Master is chosen.

According to the Scrum Alliance, Scrum features three tangible  artefacts:

The team displays its plans and progress so that all team members and stakeholders can always see what the team is accomplishing.

As you see, there are two different types of backlogs. The  Product Backlog Items  make the  Product backlog  and are then broken down into smaller bits, which become tasks that each team member accomplishes (in the  Sprint backlog).

A  Sprint Backlog  is usually just a blackboard that has a set of product backlog items on it. There are several columns: one for the tasks that need to be accomplished, one for the tasks in progress, one for the tasks that are complete (there can also be an additional column for completed tasks that need to be checked again).

Each sprint then can be seen as a certain amount of work: the team takes up as much work as they can possibly complete in, say, 2 weeks (for the teams with two-week sprints). As one feature gets completed, the team shifts to the next one).

Finally, Scrum includes  five  activities  or meetings:

After the planning and refinement is done, the work begins. To ensure that everything runs smooth, there are Daily Scrums – meetings where the whole team discuss their progress under the supervision of the Scrum Master. The objective is to identify problems before they start presenting any danger to the overall success – each member of the team is responsible for the final result, that′s why they try to solve the problems as soon as possible and move on.

When the sprint′s over, a sprint review (team and stakeholders) and a sprint retrospective (team) take place, both taking about an hour for one-week sprints, two hours for two-week sprints, etc.

Everything is described in greater detail  here.

Scrum Best Practices (+ examples)

Now, we live in the real world, don′t we? What looks good on paper doesn′t always work the same way when faced with real-life situations.

I interviewed our team, and here′s what they have to say about using Scrum on a  daily basis:

1. Not all the tasks are created equal

When product backlog items get into the sprint, the team starts breaking it into tasks that each team member is able to accomplish. Then, each member takes up a task (this is how it should be). In reality, not every team member is equally good in terms of performing a certain task (writing code, or doing HTML-markup, etc.), not all the tasks are equal, etc.

2. It′s hard to follow the initial plan/schedule

There is NO  way to say exactly what you will be doing at a particular moment. This happens because:

How it should be: When one feature is finished, the next one starts, each feature finished by the end of the sprint.

Reality: Sometimes one has to work on several features at once. The team can get time estimates wrong. Then “Wow, we didn′t consider some dependencies”  happens. Result: the feature′s not ready by the end of the sprint, APOCALYPSE.

3. It′s time-consuming

Planning takes A LOT of time. Actually, the whole thing does. If the sprint takes two weeks, at least one day is spent on planning, and then there are demos, then meetings” ¦ Let your imagination fill in the rest.

4. Scrum was designed for 7 ±2 teams (5,7,9). Which is not exactly what all the teams look like. This is an issue for several reasons:

However, as I mentioned before, Scrum was developed as a framework that each team develops and tunes according to their own needs. What matters is the continuous communication, teamwork and collective responsibility, adaptability to change and a working product in the end.
Scrum is not an “answer to all the questions” ; even Jeff Sutherland, it′s creator, agrees that  “The best Scrum teams implement XP engineering practices inside the Scrum. The best XP teams wrap Scrum around XP as it allows them to scale and take advantage of the high performance gains possible with Scrum.”   (Quora)

Exit mobile version