In the article below, our authors Jon & Steve will give a general overview of the Scrum methodology and all the essentials you need to know about it. 

Introduction

First, this is a big topic so we will break this topic into a few articles. We start with a brief overview, comparison, and a few artifacts.

There are many approaches we can take to a project. Some are scripted, and some are less so. The best practice is one commensurate with the project and circumstances. Being dogmatic, especially with a lack of understanding of the reasons behind the dogma, is not a productive approach.

Projects are seldom one size fits all solutions. Projects are unique; that is one of the attributes of a project. Not only are project objectives unique, but the operating environment, constraints, risks, and resource needs can also widely vary.

To say there is only one approach given these wide variables and variations would be, as a professor teaching a junior-level physics class once said of the class’s performance on a proof, sophomoric. Sadly, I was in that class but was in good company.

Familiar

If you have worked in projects for any time, you have probably seen or used a Gantt chart. This chart is the script or approach to the project tasks and deliverables. This chart will illustrate the expected path the work to take. It is the sequence of events, start dates, durations, and interconnectedness of the individual elements. The result is a road map that can readily be updated and provide a small measure of prediction of the completion date.

The Gantt chart sets the expectations of what is to be accomplished in executing the project and when. The project manager ideally monitors the progress against this plan demonstrated in the Gantt. Since the tasks are interconnected, if a task is late, we readily see the impact on the concluding date of the project. A task that is on the critical path will affect the final date.

Dependency Traps

From experience, we know that work product dependencies and workload, in general, are significant sources of project failure. Efforts to reduce the dependencies or exert more control over these dependencies will reduce risks to the effort.

The Scrum approach to managing the work limit the dependencies and control the work performed. Ideally, our team is co-located, reducing dependency risk due to communication and logistics. A co-located team can readily and transparently discuss the state of the work and effective action.

Scrum also limits the WIP or work in progress. This runs contrary to the script of the work in a Gantt chart or a directed approach, compelling team members to start the next set of events before concluding the present.

We track the progress on the Gantt chart, or at least we can and should. Doing so requires some connection to the actual progress and time allocated to work. How do we know when a task is at the 50% mark? v when we are at the 2-week mark of a 4-week task? That is not how it works, at least if you look at the schedule's accuracy and predictability. The project manager with the team will determine a metric that will be used to track the progress.

In some cases, the Gantt chart tasks will be sufficiently small to make this an easy task. However, from experience, these tasks generally cover many days or weeks and represent considerable effort. This leads us to note that one of the benefits of Scrum is that the work packages are small.

Whether Gantt or Kanban approach is taken, right-sizing the individual work packages for tracking is fundamental for effective project management.

The Players

There are three key players in our Scrum drama:

Product Manager

The product manager is the liaison between the final customer and the organization. They are responsible for defining the product’s content via the backlog. The product manager will spend time with the end customer to ensure the items on the product backlog provide value to the customer as well as to the developing organization.

Scrum Master

The Scrum Master is the analog of the project manager. While not always true, the Scrum Master often operates as a servant leader; they are generally not leaders in the sense of conventional project managers. The Scrum Master ensures a thriving work environment, manages the processes used, and works to resolve external difficulties. This includes ensuring the work coming into the team is understood.

The Team

The work is accomplished by this group of various talents required to produce the product under development. The team will set the approach to the work and how much of the product backlog can be undertaken during the sprint.

The Work

In Scrum, there are terms associated with the work. The product backlog is the list, in entirety, of the things to be delivered or accomplished during the entire effort. The sprint backlog is the amount of work undertaken for a short period that is referred to as the sprint.

Sprints are where the work is accomplished, and we want the sprint duration to be as short as possible. This duration is often set between two to four weeks. The items that are moved from the product backlog to the sprint backlog are understood at the customer, business, and marketing levels.

Work items are not just moved from the product backlog to the scrum backlog. What is to be accomplished must be well known for the work item to carry. This is referred to as grooming the backlog.

Scrum Board

We borrow from Kanban (meaning signboard) to keep track of the scrum effort. This approach to managing the work originates from lean manufacturing (JIT) just in time. Like the directed graph approach- the Gantt chart, we have a visual representation of the work performed in Scrum. It is there that the similarities end.

Although the entire team designated to accomplish the work is often co-located, this is not a fixed rule, and there are web-based tools. For co-located teams the board is out in the open for all team members and others that happen into the work area. This includes executives. The Scrum approach is a pull system for the work. A pull system is one in which

the work to be performed is pulled as available talent and time permits. There is no associated date with the expected start time for that specific effort. Below, we outline an example of the stages of the work on the board. This amounts to the progress of the action.

Sprint backlog

The Sprint backlog is the total work this sprint is expected to accomplish. The content of this backlog is the result of the prioritization based on the business objectives and input from the team regarding the volume of work that can be accomplished.

Work in Progress

Cards of defined work are pulled from the sprint backlog and moved to the work in progress by the team member who will do the work. This work in progress is

In Test

In this example, once the work is completed, it will be moved to the in-test phase of the work. The person testing will evaluate the work product. The testing will compare the work product to the definition of done established at the outset of the effort with the customer.

Done

Work that is completed and passed testing is moved to this phase of the work effort. The task is considered done when it meets that work item’s definition. This definition of done is the result of end customer and product owner.

Blocked

Tasks that can neither be completed or that have failed testing will be moved to the blocked category of effort. We will need to take particular action for these items.

Progress

We track the progress of the work through what is referred to as the burndown chart.

Daily Sprint Meeting

Every day of the Scrum there is a Sprint meeting. This meeting is short, round Robin discussion with each team member contributing. In general, the Scrum Master asks 3 questions of each team member.

  1. What did you accomplish yesterday?
  2. What are you accomplishing today?
  3. What is impeding of slowing your progress?

Project and Organization Uniqueness

Projects, by definition, are not operations; these are unique. Organizations are similarly unique. They have individual objectives and strengths, for example. Organizations in the same industry have different approaches, internal cultures, norms, and strengths. For instance, we have worked at automotive OEMs structured to run projects conventionally, using Gantt charts and formal project processes.

We have used agile approaches for specific projects in a company that used solely stage-gate or conventionally executed projects. Quick communication and hyperfocus on the most important objectives at the time are good strategies when short-handed.

There are many ways to reach the objective of the corporation. We should be wary of dogmatic approaches as these are often prescriptive and do not account for various circumstances in which a project may be required to operate. With multiple methods in their metaphorical backpack, the project manager is well suited to this dynamic environment.

When all you have is a hammer, everything looks like a nail ~ Abraham Maslow

Next Time

In our next article, we will explore the burndown chart and progress tracking.