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.
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 and 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.
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:
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.
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 runs 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.Read Part 2 of "So What is Scrum All About?"