SaaS Development Basics: Agile and Scrum

Creating a quality product that meets customer needs and is actually relevant by the time development is complete used to be a challenge for software businesses. Too often companies would create a product their customers didn’t want to use, or build something that was outdated by the time it could be released.

As a cloud-based SaaS, you have the opportunity to consciously deploy product increments, so you should be taking advantage of an incremental product development model like Agile.

What Is Agile?

Agile is a product development model that helps teams work flexibly through iterative product development with empirical feedback. It’s the opposite of sequential development models (like the traditional waterfall method).

In 1970, Dr. Winston Royce criticized sequential software development. He said that software should not be created in ordered phases like an assembly line because it just isn’t possible to understand a product’s requirements before you begin building. Through an Agile model, the end product could still be relevant, even if the project requirements or business purposes changed during the process.

In 2001, a group of software developers got together to discuss why the traditional approach to software management wasn’t working. They devised the Agile Manifesto that’s based on four key values.

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

These values allow stakeholders to assess and adjust the product’s direction throughout the process between increments.

There are many methodologies that abide by the Agile values. Here are the most popular.

  1. DSDM – This is the most original methodology. Technically it was around before Agile, but it follows Agile values well.
  2. Scrum – This methodology focuses on the details of managing tasks within a team. It is the most widely used methodology (more on this in a minute).
  3. XP (Extreme Programming) – This is the most radical of the Agile methodologies. It strongly focuses on customer satisfaction and the product you need right now.
Download this free resource to learn more about the roles of people on the Scrum team.

SaaS businesses overwhelmingly prefer the Agile model because it syncs well with the cloud-based continuous delivery model. When your product is always available, customers expect frequent updates, fixes and improvements.

What Is Scrum?

The Agile development model doesn’t provide concrete steps, only a set of values to adhere to. Your organization needs a specific process to iterate on your product. A moment ago I mentioned the three key Agile methodologies, but I recommend the most popular framework: Scrum.

Scrum is a project management Agile methodology that’s popular because of its flexibility and simplicity. It gives teams a structure for meetings, rules, and artifacts.

Scrum emphasizes customer feedback, self-management, and fast product increments. Many teams claim to be doing Scrum, but truthfully aren’t because they don’t focus on building a customer-centric product (not releasing the increments to users) and don’t allow teams to self-manage themselves (too many managers butting their noses in).

Scrum uses iteration cycles of no more than 30 days called “sprints.” Some sprints are as short as two weeks. The goal is to develop and test a product increment every sprint. At the end of each sprint, the team is responsible for producing a potentially shippable version of the product.

Scrum players are divided into three roles has only three roles. If any person doesn’t fit into these groups, they have no place working in the Scrum process.

  • Scrum Master – The person who facilitates sprints, meetings, and improves the engineering environment.
  • Product Owner – The person in charge of the product’s ROI. He makes final prioritization decisions and long term plans.
  • Development Team – A self-organizing group of people with varied skills who build, design, analyze and measure the product.

Other than the sprints where the work happens, Scrum requires four meetings (five for large organizations with multiple Scrum teams).

1. Sprint planning meeting

Every iteration begins with sprint planning. At this meeting, the product owner and team figure out what will be built in the upcoming sprint. This should be a conversation, not a lecture, but ultimately the product owner will prioritize features based on the largest business value.

The product owner will move the chosen feature into the sprint backlog, a physical representation of the plan (usually a board with movable post-it notes or index cards). Anyone can add tasks to the backlog (collaboration is essential for this process), but only the product owner should prioritize tasks. In some cases, the product owner will allow the team to break down each feature into individual tasks (sometimes called sprint planning 2).

Image: Drew Stephens / Flickr

At this meeting, the sprint duration is also decided. It should be just as long as it needs to achieve the sprint’s goals. Sprints should be no longer than a month, otherwise you’re packing too much into each increment.

In larger organizations, there might be multiple development teams pulling from a giant backlog, even if there’s only one product. Multiple backlogs or product owners for the same product damage agility.

2. Daily standup meeting

Every day, Scrum teams should have a meeting near their task board to discuss goals and progress. This is also a good time to make any obstacles known so the product owner can work them out.

The task board should have five columns: Product Backlog, Tasks to Do, Work in Progress, Ready to be Verified, and Done. The Product Backlog column should be items that came from the product owner’s overall prioritized backlog that are included in the current sprint (not every feature increment). As items move through the process, they should be adjusted accordingly on the task board.

It’s critical that daily standup meetings are kept to 15 minutes or less so more time can be devoted to development. They’re called “standup” because they should be quick enough that no one feels the need to get comfortable. Use a stopwatch if necessary.

3. Sprint review meeting

At the end of the sprint, teams should meet to present a shippable product increment to the product owner. This demonstration replaces usual reports and status meetings, which are nontransparent because they don’t display the actual product. The product owner will decide if the work is actually done or if it needs more development time.

4. Sprint retrospective meeting

The retrospective meeting should take place after the review meeting. Here, the Scrum master and team will evaluate the process and performance of the sprint and if anything should be done differently for the next increment.

Team members should be able to speak openly about the sprint’s effectiveness without fearing retribution (hopefully you’ve created an organizational environment that supports constructive criticism).

5. Overall retrospective meeting

This meeting is only necessary in large organizations with multiple teams sprinting at a time. The goal is for teams and Scrum masters to evaluate the interactions between teams and provide any improvements.

Your Scrum team should have only three very specific roles. Learn more in this guide. 

Empowering your team

You’ll notice that the Scrum methodology doesn’t go into detail about what happens during sprints. That’s intentional. The point of Scrum is for teams to be Agile. They need to manage their own work and iterate on the product according to their own work styles and preferences.

Be mindful about timeframes, too. Only increase the scope of an iteration if you decrease it some other way. If the team won’t finish on time, reduce the scope so the final product is shippable. 95% complete isn’t good enough. Everything that comes out of a sprint should be ready for deployment.

If you’re the product owner or Scrum master, you should do everything you can to empower your team. Solve their problems, remove their impediments, and provide them with the tools they need to get the job done. You can coach them, but don’t give instructions. In many cases, that means running interference and keeping the rest of the organization off their backs.

Leave a Reply

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