Scrum and Agile

What is Scrum and Agile?

The terms “Scrum “and “Agile” can often be used interchangeably when you first enter the world of Software development and project management but there is an important difference.

Agile refers to a set of “methods and practices based on the values and principles expressed in the Agile Manifesto,” which includes things like collaboration, self-organisation, and cross functionality of teams.

Scrum is a framework that is used to implement Agile development. So, Scrum is Agile but Agile is not Scrum.

A good analogy would be the difference between a recipe and a diet. A vegetarian diet is a set of methods and practices based on principles and values. A recipe for tomato soup would be a framework you can use to implement your vegetarian diet. So this is similar to the relationship between Agile (the diet) and Scrum (the recipe you follow).

Agile was born out of the techniques utilised by innovative Japanese companies in the 70’s and 80’s (companies like Toyota, Fuji, and Honda). They started working via the kanban method to improve the speed and flow of work.

In the mid-90’s, a man by the name of Jeff Sutherland found himself frustrated by companies who were continually plagued by projects that were behind schedule and over budget. He sought to find a better way. His research brought him to these Japanese companies and their Agile methods. Basing his work on this, Sutherland created the Scrum framework. After a series of successes using his new methods, Scrum began to quickly spread throughout the product development world.

What is Scum Used for?

Scum is a very lightweight approach to developing software in which teams can work collaboratively to design, build and test the product. It was devised specifically for software development but can be easily adapted for all sorts of projects.

Scrum has been used by everyone from large security firms, to marketing agencies, to technology giants. Any time you’re producing some sort of product, be it software or communications campaign, Scrum can assist and organise your team and get more work done in less time.

The Scrum Parts

To understand Scrum, you’ve got to know the people and parts of the framework. The good news is, you don’t need any special experience or certifications to start.

You don’t need much to get started with Scrum such a bit of organisation and a whiteboard or some type of collaborative software tool. You need different roles, like the Product Owner and the Scrum Master. The actual tools you need are not as big as the roles involved

Scrum starts with a Product Owner. This is the person who represents the final user’s best interests and has the authority to say what goes into the final product.

That Product Owner is in charge of making the list of requirements or Backlog A Backlog is a list of tasks and requirements the final product needs. It is vital that the Backlog be prioritised. That’s the job of the Product Owner.

If I were using Scrum to design a car, the Backlog items might include:

  • Must have an engine
  • Must have seats
  • Must be blue in colour

The colour is of less important than the engine because no matter what the colour the car needs an engine to run.

You will also need a Scrum Master. This is the Scrum expert who advises and assists the team implement Scrum. A Scrum Master is not a Project manager. This person will sit in on Scrum meetings and other events to make sure they are being enacted as per the Scrum guide.

Next up is the Sprint. A Sprint is a predetermined time frame within which the team completes sets of tasks from the Backlog. The length of time depends on the needs of the team, but two weeks is pretty typical.

Teams meet every day to give progress updates in the Daily Scrum. This is a quick 15-minute stand-up.

Each Sprint ends with a review, or Retrospective, where the team reviews their work and discusses ways to improve the next Sprint.

As you can see, there are very few processes or procedures in Scrum. It is easy to learn Scrum but it can be difficult to master.

Before you get Started with Scrum

It’s important to note that Scrum is not a project methodology it is a lightweight framework to help teams deliver software in a collaborative manner which allows the team to excel and be self-determining. So if starting off on your scrum journey it is important to realise this.

Things to note about Scrum:

  • It is not a project methodology
  • There is no project manager in a scrum team
  • Scrum teams are not managed, led or directed
  • Scrum can be used to deliver elements of a project
  • Scrum does not focus on documented plans
  • All work is visible to all the Scrum team members

Steps for getting started

A very good resource is scrum.org. Download and print the PDF version of the official Scrum Guide: Read it on your commute or during your lunch break with a highlighter in hand. Highlight the phrases and roles that are new to you and start working on memorising what each one means.

Pick your roles: You need a Product Owner (speaks for the user, final say in what the project needs), a Scrum Master (helps the team move along based on the principles of Scrum), and team members. Remember, there’s no room for egos in Scrum. Scrum runs on a servant leader model.

Create your product Backlog: The Backlog is where you list out everything the project needs, ordered by importance. Keep in mind that the Backlog is never complete. As the project takes shape and new needs emerge, you will add to this. The Product Owner takes primarily responsible for this.

Plan your Sprint: Next, it’s time to pick tasks from the backlog to be completed in your first Sprint. Sprint’s are time-limited. You can decide a time length that works for you, but they are always less than one month. During the Sprint Planning, the team decides what tasks to include in this Sprint and who will be responsible for them.

Team members work on their tasks, and everybody checks in on their progress at the Daily Scrum Meeting. This meeting lasts no more than 15-minutes and answers three questions: What did you work on yesterday? What will you work on today? Is there anything blocking your work today that you need help with?

Review your work: At the end of the Sprint, the team reviews the work accomplished and presents their completed tasks.

Review your process: During the Retrospective meeting, you’ll review how the actual work process went and plan ways you can improve your work and be more efficient next time.

With your first Sprint complete, it’s time to start over again. Pick more tasks from the Backlog and repeat the process.

Make it Visual

I mentioned above all work in a Sprint is visible to all team members. The use of Kanban boards is recommended by most in Scrum. A Kanban Board is a whiteboard on a wall with the tasks for each sprint listed on them. It will list the Backlog items on left with those – in progress – to do – done, listed to the right. The use of sticky notes for the tasks and items is common. I advise you add the resources on the sticky notes also so everything is transparent.