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 methodologies in our projects and see some best practices that help us deliver high-quality work to our clients.
What is Agile methodology software development
Just a quick recap: here's a short agile methodology overview. 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 methods and frameworks have such as Scrum, Kanban, Lean, or Extreme Programming (XP).
Most development teams work in Scrum or XP for iterative development. 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 an agile development 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.
What are the agile practices our development team uses?
Agile development practices are the foundation of our success. Our teams follow the Scrum framework that generally encourages teams to self-organize while completing tasks, reflect on their workflows and processes, and continuously improve the way they work and collaborate.
Here's a closer look at our framework that enables the efficient implementation of agile principles and values.
This meeting happens at the very beginning of a sprint and includes the team, scrum master, and product owner. The idea behind the sprint planning meeting is setting the team for success during the following sprint. During the meeting, the product owner presents a prioritized product backlog and discusses every single item with the team. Together, they estimate the effort involved in the sprint and make sure that the team has the capacity to deliver everything as promised. Our development teams are skilled at making sprint forecasts that outline how much work they can complete from the product backlog.
We use the sprint planning meeting to talk about the details of the work to be done. It's important to reach consensus about the next sprint's plan at this point. Over the years, we've learned that effective planning increases the team's chances of meeting the sprint commitments successfully.
Daily standup meetings
The team, product owner, and scrum master come together during these short daily meetings to let everyone know about what the team is going through as team members work on sprint tasks. Note that this is not a detailed status update meeting. It's short, light, but also informative for everyone involved. The idea here is having each team member tell everyone what they did yesterday, what they'll be working on today, and whether there's anything preventing them from completing tasks.
Daily standup meetings help us build transparency and accountability throughout the entire agile development team, making everyone feel happy to report their progress.
One of the most important agile practices is sprint retrospective a meeting that centers on the progress of the team, rather than the project. We always organize a retrospective at the end of an iteration or individual sprint.
During one hour, the team, product owner, and scrum master talk about the achievements of the most recent iteration or sprint to understand what went well and what didn't. The objective of this meeting is identifying weaker areas and offering the team support in focusing on them in prospective iterations. Short iteration is an agile method that powers this type of continuous growth. We believe it to be the most groundbreaking characteristic of agile - and the reason why so many teams out there practice it.
Continuous improvement is the force that sustains and drives developing in teams. It's the most popular agile feature, and retrospectives play a key role there.
Here's something we learned about retrospectives:
Even if things are going well, we never stop doing retrospectives and analyzing our team's performance. They're the most valuable source of guidance for the team, allowing developers to celebrate wins during development cycles.
Why we implement Agile
Here are a few things that make Agile indispensable to our 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.
At Sunscrapers we follow such a process when dealing with software development.
This is what our agile-driven development 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 agile 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 everyone who is relevant to the project. 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 everyone relevant 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, also outside of agile development. 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. We believe that this type of investment offers excellent ROI is high enthusiasm and motivation of individual team members who make up our amazing teams.
4. Set communication standards (especially for remote teams)
Communication is challenging; there’s no doubt about that. And remote communication is even harder during agile development, even if teams meet every day for daily standup meetings. 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:
- 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.
Keeping a close eye on burndown charts helps to avoid that problem as well. A burndown chart displays the amount of work completed by the team in a sprint and the total work remaining. You can use such charts to predict your team's likelihood of completing work on time. We also use them to make the team aware of any scope creep that may occur during the project.
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 all relevant people 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.
Agile software development best practices - checklist
- Fine-tune the product backlog with stakeholders
- Speaking of stakeholders – invite them to Scrum meetings
- Invest time in team building; it’s worth it
- Set communication standards (especially for remote teams)
- Prioritize tasks in the product backlog, here’s how
- Plan new sprints when there are enough items in the product backlog
- Capture bottlenecks by visualizing dependencies
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 that help our clients succeed.