So What is Scrum All About?

Visit Website View Our Posts

If you work with software development or project management, you may have heard about Scrum, but do you know exactly what it's all about? If not, this article is just for you.

Features used after delivery of a Software Project

Going through a major software project can be quite grueling, but once it's completed you would hope that your company gets the value of all the features and functions that were implemented during the project. The problem is that in most cases a lot of the functionality that was delivered as part of the project is never or rarely used afterwards.

A Study by the Standish Group showed that 64% of application features and functions delivered in an average software project were never or rarely used. So you just spent a lot of time and money on a lot of features and almost two thirds are hardly ever used!

The problem lies in the way the project is being planned delivered. As you will see below, a traditional project model requires a lot of upfront analysis and design. Users from different departments are asked to do the requirements they would like to have as a part of the project and typically they will ask for the maximum they can think of because they only get to state their needs once in the beginning of the project. Most of the time a lot of these requirements are not really needed and end up as rarely or never used in the final product.

In the following I will go over the issues related to the traditional project model and how an agile approach will deliver a leaner, less costly and overall better product for the end user.

Project Management according to PMI, The Waterfall Model

Let’s first discuss how a project traditionally has been (and in many instances still is being) approached. The Project Management Institute (PMI) has published the Project Management Book of Knowledge (PMBOK) that in minute details explains how a project is planned, executed, controlled, and delivered.

According to PMI, a project is a series of process groups that ultimately ends up with a finished deliverable (product). Without going into too many details, the model, PMI is using to deliver a project, is called the waterfall model. The waterfall model basically says that we will have to follow certain steps in a specific order. The steps are usually:

Result: Deliverable or Product

In the waterfall model we spend a lot of time upfront on analysis and design. In an average project that could take several months to finish the design and write up the functional requirements in a so-called design document. The design document is a detailed description of the entire scope of the project and is usually very hard to read and understand, thus very few stakeholders in the project actually end up reading and fully understanding it.

The waterfall model is not allowing a whole lot of flexibility changing directions and going back to rework things; hence the term waterfall indicating that once one step is done it can never be revised. It's not completely fair to say the PMBOK is not allowing revisiting previous steps, but it's usually not advisable to do it too much. If change happens in the waterfall model, it usually also means that the design document needs to be amended and approved, which is a time consuming and cumbersome process.

There are three main issues with the waterfall model:

  1. The customer is not getting the value of the project until the very end. There is not any real value of the project until the very end. There is not any real value delivered to the customer until the project ends. There are usually ways for the customer to see bits and pieces of the deliverable during the project, but the real value is not delivered until the end of the project.
  2. The model is based on a lot of planning and expects predictability. PMBOK largest process group is the planning group. PMI wants you to plan, plan, and plan. There is nothing wrong with planning, but if we are lacking experience in certain areas, it makes no sense to plan. The model really likes us to be able to predict everything in advance so we know how we will act in each instance. We also plan all the features that end up never or rarely being used.
  3. The model is really not geared for change. Even though PMBOK explains how to handle change, it's really implicitly preferred not to have too many changes during a waterfall project. It also contradicts the conecpt of predictability: We don't know what kind of changes we will encounter and consequently can't plan how to react to them.

Project Management According to Scrum

Scrum is an agile framework that allows the delivery teams and client to collaborate to build a quality product that ships early and often, while everyone is learning and relearning as they go. Sounds too good to be true, right?

Essentially, the agile approach is slicing the traditional model up into iterations. For each iteration we do  analysis, design, development, testing, training, and deployment, but in a much smaller scale than in the traditional project approach. You can say that the agile model slices the traditional phases into smaller pieces and executes them in much more manageable iterations called Sprints:

As you can see from the above graphic, we are cutting the project up horizontally. We can potentially do a little bit of every phase in each Sprint that typically run for a few weeks.

Scrum is using so-called User Stories from the Product Backlog to determine what is executed in each Sprint.

The user stories are simple overall business stories without all the details that we typically specify when we do a traditional design. A story could say: “As a warehouse worker I want to be able to pick my inventory using a scanner so that I can expedite the picking process and make less errors”. So the story is written in the problem domain and not in the solution domain, making it much easier to understand and write than a traditional design write up. For each sprint the customer and project manger pick the 5-7 most important stories and they are the only ones that are executed for the Sprint. In the next Sprint the next 5-7 most important stories are picked and executed etc. Scrum resolves the three main issues with the waterfall model:

  1. Product is shipped early and often.

The scrum framework will deliver value often by shipping a product increment on a regular basis after each Sprint (typically). The product will include the deliverables the development team has finished, and the customer can subsequently review and test the deliverable.

  1. Much less planning and much more doing and collaboration.

Since we are postponing the decision, which stories are executed until the very last moment we only analyze, design, and develop the stories that bring the most value to the product and the client. Scrum values the individuals and their interactions and has ways for the team and the client to collaborate and align on a regular basis to increase the transparency of the project.

  1. Change is expected and embraced.

According to Scrum, responding to change is more important than following the plan. Clients always change their mind during the duration of a project and scrum embraces this change. All we need to do is write the change as a User Story and place it in the product backlog. If it has high enough priority it will get executed sooner than later. If not, it wasn’t important enough to make it into the project in the first place.

The following is from the Scrum Alliance website (http://scrumalliance.org)

Scrum is an innovative Approach to Getting Work Done

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum Framework is deceptively simple.

The Scrum Framework in 30 Seconds

  • -A product owner creates a prioritized wish list called a product backlog.
  • -During spring planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
  • -The team has a certain amount of time, a sprint, to complete its work-usually two to four weeks-but meets each day to assess its progress (daily scrum).
  • -Along the way, the ScrumMaster keeps the team focused on its goal.
  • -At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
  • -The sprint ends with a sprint review and retrospective.
  • -As the next sprint begins, the team chooses another chunk of the product backlog and begins working again

The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of the milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.

Why is it called Scrum?

When Jeff Sutherland created the scrum process in 1993, he borrowed the term “Scrum” from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formations used by Rugby Teams.

Scrum is the leading agile development methodology, used by Fortune 500 companies around the world. The Scrum Alliance exists to transform the way we tackle complex projects, bringing the Scrum framework and agile principles beyond software development to the broader world of work.

Source: Scrum Alliance

 

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons