As a pMD software developer, I take great pride in building best-in-class medical software that our customers love. Our development team accomplishes this not only by shipping a high quality product, but also by making sure that the features we are working on address the most important needs of our users. However, as you might imagine, this list of customer priorities isn’t static. In fact, it changes almost constantly. To help keep our development team in-sync with this ever-moving target, we use an agile software development methodology called Scrum.

Traditional software development

In the traditional world of software development, something called the Waterfall method is frequently employed. This long-running process of building a software product is broken into several phases: requirements gathering, design, code, test, and release. Each of these steps might last as long as several months. At the end, you (hopefully) have a piece of software ready to ship. However, there is one problem: the thing you have produced is based on a set of customer requirements that is now a year or more out of date!

Even if those customers had come to you several months into the process with an updated set of priorities, there would have been very little you could have done to change what was being worked on, especially if you had already moved past the requirements gathering stage. You’re stuck building software that isn’t going to address the current needs of your customers. That’s where Scrum comes in.

Scrum to the rescue

Scrum is a popular agile software development method that takes the Waterfall process and compresses it into a much shorter development cycle called a sprint. A sprint typically lasts from two to four weeks (we do two week sprints at pMD) and still includes all five phases of development from the Waterfall method, just in a much more abbreviated form.

The key player on a Scrum team is the Product Owner. It’s this person’s job to make sure that the backlog of features waiting to be worked on by the development team stays prioritized according to the current needs of the customers. When a feature request or bug report comes in, it’s up to the Product Owner to prioritize it and add it to the backlog in the appropriate place.

With this backlog in hand, the software development team sits down at the beginning of each sprint for a Sprint Planning meeting. This meeting has two parts: first, using a system of points, the team establishes what their development capacity will be for the upcoming sprint, i.e. how much bandwidth they’ll have to work on the software (things like travel to customer sites, jury duty, and vacation affect capacity). Then, they start at the top of the backlog and begin estimating the work involved in each feature by assigning it a point value. When the total of number of points estimated reaches capacity, they stop.

These features then get assigned to the upcoming sprint. For the next two to four weeks, the team works on them, going through the design, code, and test process for each one. At pMD, we frequently release features as they are completed. Other groups may choose to wait until the end of the sprint and do one, larger release. Even in this case though, releasing every few weeks is still far better than shipping software once a year!

It’s all about the customer

We love building software that delights our customers. Scrum helps us achieve this by providing us with a great framework for keeping our work in-sync with our users’ changing needs and priorities. In future posts, I’ll dive deeper into the details of how we’ve implemented the Scrum process at pMD and some of the tools we use to collaborate and track our progress.

‍