At Sunscrapers, we believe that Agile is more than a collection of software development techniques or ceremonies. For us, Agile is a group of methodologies teams can mix as they like – as long as they stay committed to short feedback cycles and continuous improvement of their process.

Frequent iteration, high quality, continuous learning, adaptation, open communication, and trust between team members – these are the core values of Agile.

Fortunately, they happen to be closely aligned to the core values shared by our team.

Read on to find out how we apply the Agile methodology in our projects and see some best practices that help us deliver high-quality work to our clients.

How we define the Agile methodology

Agile was born as a methodology in 2001 with the publication of the Agile Manifesto. Since then, we’ve witnessed the emergence of many different agile frameworks have such as Scrum, Kanban, Lean, or Extreme Programming (XP).

Most development teams work in Scrum or XP. Service-oriented teams like IT, HR, and other business teams tend to use Kanban.

Note that the Agile Manifesto didn’t prescribe things like daily stand-up meetings or two-week iterations. It offered a set of core values that put some things over others.

The realization of these values is entirely up to a team and can take on many different shapes. It’s good to remember that. Agile teams often combine practices from a few different frameworks, putting that mix together with methods that are unique to the team. To us, that’s a practical approach – it’s not about “Scrum,” but about agility itself.

Why we implement Agile

Here are a few things that make Agile indispensable to our software development teams:

  • Quick response to changes – whether it’s changes in the marketplace or new feedback from end users, Agile enables us to quickly change the direction of development without going against plans formulated over months. Shipping in small increments allows our teams to gather feedback and integrate it at minimal cost.  
  • Human interactions over rigid processes – Agile helps us to collaborate with clients efficiently, without forcing everyone to stick to predefined arrangements. It also helps us focus on delivering value as quickly as possible because that’s just more important than creating extremely detailed documentation.
  • Shared vision and ownership – our teams share core Agile values and are empowered to set their own standards for quality and completeness. Their definition of done orchestrates their work and defines how quickly they churn it out.


Putting my trust in teams is a little scary, but over time I’ve learned that this is how teams get to feel a greater sense of ownership and work hard to meet my expectations.

This is what our Scrum process looks like. Of course, we often adjust these elements to the unique requirements of the project and the client’s operations to deliver the best results.

Now that we know what agility is all about and why it works so well for development teams, it’s time for some practice.

Here are 7 best practices that help our teams deliver excellent results to our clients.

Agile best practices at Sunscrapers

1. Fine-tune the product backlog with stakeholders

The product backlog is one of the essential artifacts in Scrum. It documents the product vision shared by project stakeholders. We always start our work on the project by filling in the product backlog together with all stakeholders. We do that once we’ve gathered project requirements and defined the essential business needs of our client.

Involving stakeholders in this process is important. It’s during product backlog negotiations that team gets to learn more about the stakeholder. That knowledge allows team members to reach a mutual understanding of the results and share a vision.  

2. Speaking of stakeholders – invite them to Scrum meetings

There’s no reason to involve stakeholders in all Scrum meetings. But it’s an excellent idea to invite them to some of those meetings. We do that to allow stakeholders to see how the meetings are held and understand the internal team dynamics.

By knowing what sprint planning looks like or how the results of a sprint are discussed, the stakeholder gains a better understanding of how the team works. As a result, they can deliver more specific and valuable feedback to the team – and that helps all the parties involved!

3. Invest time in team building; it’s worth it

We all know that team-building activities are important. But they become crucial when you need to assemble a team for a new project from scratch. To make sure that our dedicated teams are ready to take on the challenge of working together, we involve them in informal team building meetings like dinners or company trips.

But we also promote teamwork through professional activities like collaborating on our open-source projects, giving weekly internal presentations, and reviewing conference talks of team members.

4. Set communication standards (especially for remote teams)

Communication is challenging; there’s no doubt about that. And remote communication is even harder. It’s easy to miss out on critical details on Slack or during a Skype conference call.

Define communication guidelines and write them down in a document that will be distributed among all team members. For example, we made it obligatory for team members to notify everyone when they identify a new blocker and it brought us great benefits.  

5. Prioritize tasks in the product backlog, here’s how

We’ve used various backlog prioritization techniques to find what works for us.

Some teams are successful with HiPPO (Highest-paid person’s opinion). We don’t use this method because it doesn’t provide transparency for team members and may prevent us from making smart data-driven decisions.

Here are some common prioritization techniques:

MoSCoW – that acronym stands for Must haves, Should haves, Could haves, Won’t haves. These are the four primary categories teams use to break down stories by priority. It’s the most popular and most straightforward approach to prioritization. Be careful though – it doesn’t consider the specifics of the product.

Kano model – based on customer preferences and perfect for highly-competitive markets, this model operates on five categories from the most to the least prioritized ones:

  • must-be,
  • one-dimensional quality (users are satisfied if a feature is present and are dissatisfied if not),
  • attractive quality (users are happy if the feature is present but won’t be disappointed if not),
  • indifferent quality (users don’t consider a feature good or bad),
  • reverse quality (users are outright dissatisfied with a feature).

Business value – when following this approach, teams give power to a stakeholder or a product owner in estimating which user stories will bring the most financial value. This approach works for teams working on a validated business idea. This method is line with our goal of creating software that delivers a tangible and measurable business value.

Validated learning – features characterized by the highest market risk are released first to get the user feedback as early as possible. A good approach for market disruptors.

Walking skeleton – priority features are enough for the product to be launched. The most common use case for this approach is the Minimum Viable Product (MVP).

6. Plan new sprints when there are enough items in the product backlog

It only makes sense to plan a new spring when your product backlog has enough tasks to fill out at least two sprints. Otherwise, you risk that your project suffers from scope creep. This is what happens when the scope of your project grows without control because you failed to fully define the scope of the upcoming sprints in the backlog.

7. Capture bottlenecks by visualizing dependencies

This technique always helps us to manage bottlenecks and reduce their impact on our work. We start by dividing all dependencies into two groups: functional and technical dependencies. We ask stakeholders and product owners to define functional dependencies, and engineers to identify the technical ones.

Here’s an example of a functional dependency:

We can’t design a landing page before completing the shipping set-up workflow.

A technical dependency could look like that:

We can’t develop a shipping set-up workflow before integrating a payment gateway beforehand.

Once you map all dependencies, you’ll be able to identify bottlenecks. Then you can reconsider their structure or de-prioritize some of them.

The takeaway

At Sunscrapers, we’ve always believed in the power of teams. While project leads or product owners take it upon themselves to prioritize work, it’s teams that decide how to do it and self-organize around granular tasks.

For a custom software development company like ours, Agile is critical because it helps us to empower teams and maintain control over project deliverables to help our clients succeed.

Are you looking for a team of agile software developers? Get in touch with us for a free project estimation or tailored dedicated team offer.

Kamil Sabatowski
Kamil
COO at Sunscrapers

Kamil specialises in both strategic and operations management. He graduated from University of Warsaw and Warsaw School of Economics. He shares his thoughts about new technologies, corporate & competition strategy, agile project management through entire life cycle and scaling tech teams.

LOAD COMMENTS

arrow

Join our newsletter.

Scroll to bottom

Hi there, we use cookies to provide you with an amazing experience on our site. If you continue without changing the settings, we'll assume that you're happy to receive all cookies on the Sunscrapers website. You can change your cookie settings at any time.

Learn more