Scrum is a framework to generate solutions for complex problems. At Airship, we use the scrum process to go from initial problem statement creation all the way through to launch.

You’ve heard the saying, “How do you eat an elephant?" And the answer, “one bite at a time…”

Simply put, that is scrum. You break down the problem you’re trying to solve into bite-size pieces and each piece gets you one step closer to eating the elephant.

The 5 Steps of Scrum

There are 5 set steps in the Scrum framework that guide a team through the building of software from a problem statement to a solution.

Those 5 steps:

  • Product Backlog Creation
  • Sprint Planning
  • Sprint Work
  • Testing and Demonstration
  • Retrospective and next sprint planning

This process is repeated until the project is completed.

What does this mean to you?

It means a carefully thought out list of core and non-core features, defined success, and a steady approach to development to ensure that the correct solution is defined and created. In the life of the project, changes and challenges are inevitable.…it is important to be nimble enough to learn from problems solved, and incorporate those changes along the way.

Scrum Master and Product Owner

Our project managers, aka Navigators, play the role of both Scrum Master, the person who makes sure the scrum process is followed and product owner, the person who ensures the client vision is realized. We believe this gives our clients the best possible approach.

As a Scrum Master, Navigators are focused on the rules. This means that the Navigator ensures that the entire squad is clear on the definition of done as it pertains to the assigned tasks and that the entire squad is committed to each two-week sprint that will ultimately see the project through to completion.

The other role Navigators play is that of the Product Owner. This role is focused on the content and how it relates to a client's vision. When you first come to Airship, we walk through a series of exercises, we call it mapping (read more about mapping here), that helps you take your idea to solve a certain problem and create the best possible solution utilizing technology.

The Product Owner's role in scrum supports the creation of that vision by asking questions. It is taking time to relate and understand how strongly you feel about specific aspects of a project. Questions allow us to be nimble. For instance, if we have a list of agreed-upon core and non-core features but along the way, your priorities change, we can review and determine if a non-core feature should become a core feature.

Scrum in Action

An example: one of our clients recently came to us in sprint 2 of their project and asked if their application was going to be in Spanish. To which we said, no that had never been mentioned. Our client realized that a high percentage of their end-users were Spanish-speaking. The Navigator on the project had to put on the product owner role, ask questions, and evaluate the already established features, budget remaining, and timeline.

After discussion and review with the team, the Navigator went back to the client to discuss within the parameters set the potential of reprioritization of features, budget, and/or the timeline in order to include a Spanish version. Because when a priority changes, there is a ripple effect across a project. The Navigator is the person responsible for ensuring the team stays on the same page throughout the inevitable tweaks and changes that occur.

Using the Scrum framework, we are able to methodically build your vision and to adapt and transition along the way. You have a vision, and our role as your guide is to make that vision a reality. Navigators, aka Scrum Masters/Product Owners, are the point person. They do the talking, ask a lot of questions, and at times have difficult conversations.

At the end of the day, the framework gives us the parameters through which we achieve collaborative execution which is one of the guidelines from which we work at Airship. Because of scrum and our ability to be nimble, it also gave our client a Spanish version of their application.

History of Scrum (and what's with the name?)

An aside...and a little history...

Scrum can be traced back to a 1986 Harvard Business Review article, The New Product Development Game, written by Hirotaka Takeuchi & Ikujiro Nonaka. The article described how large companies such as Honda and Canon used an empowered team approach in product development. The article began to make the rounds and in 1993, Jeff Sutherland and his team at Easel Corporation defined the “scrum process.”

The team at Easel Corporation used the concepts from the HBR article to create guidelines around software development. The idea is that it is important to make incremental progress, evaluate and be able to make changes easily without having to throw “the baby out with the bathwater.”

And, where the heck did the name “scrum” originate? It is a term used in rugby that denotes how a game is restarted after a foul. It was chosen by the HBR authors because it denotes teamwork.

Ready to discuss your project, let's talk.


Start with: What problem are you trying to solve? 

One of the activities we work through revolves around refining your problem statement. A problem statement is the key business problem that needs to be solved. In software development, it states “what has to be done” for a project to succeed. It does not say, “how it has to be done.”

We use the 5W’s + 1 H format as well as the SMART Framework when establishing a problem statement. In fact, you can draft your own problem statement by using our free download. This download will get you thinking through some of the questions and answers prior to starting your project.

Download: Problem Statement
Ready to get started?