Agile/Scrum

Atlassian defines agile as:

"An iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments.”

Agile is an overarching project management philosophy—an umbrella term for a wide range of methodologies used to get work done. The agile umbrella can be filed under an even larger umbrella: continuous improvement.

Scrum is an agile methodology—that’s why we refer to agile/scrum—and it’s the one we use at Far Reach. It’s one of the most widely adopted software development methodologies in use today. 

The Agile Alliance defines scrum as: 

“A process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments.”

Agile/scrum is the framework we use to move work throughout the development process. It’s also how we work on how we work, continuously improving our workflows in small iterations. 

Agile Manifesto

In 2001, a group of representatives from the various agile frameworks got together to nerd out on software development. From that weekend at a ski resort in Utah emerged the Agile Manifesto, which documents the values and principles of agile software development.

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

As you can see, there’s nothing prescriptive or definitive in how work gets done. Agile focuses on driving value and adapting to get a little better each time.

When most of us Far Reachers got started in software development, the primary method of building software was still waterfall: put together all the requirements, build the system to those requirements, and launch 18 months later only to realize the system wasn’t ideal.

Thankfully, those days are behind us. Now, the foremost software development philosophy is agile, which focuses on getting the software in front of the user fast and learning and iterating over time. 

Within agile there are many frameworks. Scrum is the one we use, which is why we refer to “agile/scrum.” If you want an overview of what agile/scrum is, you can jump down to that section.

What using agile/scrum allows us to do is help clients build the right software faster and adapt to changes as they happen. By working in priority order and in iterations, we get a system into the real world quickly; continually improve it based on feedback; and adjust as needed for shifts in technology, business strategy, or external factors. 

To make working in iterations a little bit more tangible, let’s think about transportation. If you needed to get from point A to point B, using a car might be the ultimate goal, but we’d start simpler.

The Agile/Scrum methodology is a common approach to software development for good reason—it offers flexibility, collaboration, and iterative progress. Here are some of the key benefits we’ve found of using Agile/Scrum for custom software development:

Flexibility and Adaptability:

Agile/Scrum allows for flexibility and adaptability to changing requirements. The development process is iterative, and adjustments can be made at the end of each sprint based on feedback and evolving business needs.

Faster Time-to-Market:

By working in sprints—small, manageable increments—we can deliver changes at the end of each iteration, which results in faster time-to-market for crucial features. We have also integrated DevOps best practices into our Agile/Scrum processes to further this benefit. 

Improved Quality:

Regular testing and continuous integration during sprints contribute to the overall quality of the custom software we develop. Defects can be identified and addressed early in the development process.

Enhanced Communication and Collaboration:

Agile/Scrum promotes regular communication and collaboration among team members and with client stakeholders. Daily stand-up meetings, sprint planning, and retros foster a transparent and open working environment.

Empowered Teams:

Agile/Scrum empowers development teams by giving them the autonomy to make decisions about how to approach their work. This sense of ownership can contribute to higher motivation and creativity among team members.

The Agile/Scrum methodology brings many benefits to custom software development, making it a widely adopted approach in the industry. The ability to respond to changing requirements, deliver incremental value, and engage stakeholders throughout the development process contributes to faster time-to-market and higher-quality software. While Agile/Scrum is not a one-size-fits-all solution, its principles provide a solid foundation for organizations seeking an effective and efficient approach to navigate the complexities of custom software development.

In scrum, the entire team is responsible for working together to create a great software system. There are only two named responsibilities, and everyone on the team works together on development, testing, and accomplishing the work in the backlog. 

Product Owner - The product owner (PO) defines the what—as in what the product will look like and what features it should include. As a development partner, we split this responsibility into two: the Far Reach PO and the client PO. 

Scrum Master - The scrum master helps the team perform at its highest level and helps remove both internal and external barriers. They also hold the team accountable to its working agreements, scrum values, and to the scrum framework itself.

At Far Reach, we have team members whose main responsibility is product owner or scrum master, but the responsibilities can be taken on by anyone on the team.

Other than those two named responsibilities, a scrum team is self-managed and empowered to organize and manage their own work. A team can be any size, but the general standard is 3-9 people. At Far Reach we work as one big team as well as in smaller project-based teams.

See the people behind the projects at Far Reach. Scroll over (or tap on mobile) each team member’s photo for a little surprise.

In the spirit of agile, we’re always learning and improving. We read “Scrum: The Art of Doing Twice the Work in Half the Time” in 2015 and have been adapting every sprint since. 

Agile is a philosophy and scrum is a framework. Neither one has detailed, defined rules. They offer guidelines, values, and best practices from those who have found success, but there aren’t hard-and-fast rules or policies. 

If you talk to 10 different software development teams using agile/scrum, you’re going to see 10 completely different ways of working—but they can all be considered agile/scrum.

There are a lot of scrummy terms, so if you need a refresher, check out Demystifying Nerd-Speak in 10 Easy Terms.

Here’s a look into our agile/scrum system. At a high level, it represents the values and principles of agile and scrum, but the detailed processes and workflows are uniquely Far Reach.

The Backlog

Work to be done lives in a backlog. Ideally, the backlog is prioritized, but we’ve found that there’s usually a prioritized backlog for upcoming work and then a less-defined backlog with ideas, long-term work, and more. 

The prioritized backlog includes user stories, each of which has requirements gathered by the PO. Each story is a piece of work to be done within a larger feature, project, or system. 

Every story has an estimate, and the agile/scrum framework uses points to estimate. Points are relative and indicate the risk, effort, and complexity of a story compared to similar work. For example, a quick, very isolated task that can be developed, tested, and deployed in an hour or two might be one point, whereas a multi-day story that touches multiple areas of the system and relates to a mission critical process might be 13 points. 

For pointing, we use the Fibonacci sequence: 1, 2, 3, 5, 8, 13. The sequence continues, but we try to break down stories to 13 or smaller. Points are determined by the team, often through scrum poker. 

So every story is prioritized, has requirements, and is pointed in the backlog. 

The Work

Our work is split up into sprints, which are repeatable, fixed time-boxes. We most often work in 2-week sprints. Each sprint, or iteration, has an overarching goal. It could be getting a specific feature pushed out, improving velocity, or any other goal that might be possible in two weeks.

There’s no set structure for how stories are completed in scrum. At Far Reach, each story, no matter who’s working on it, goes through the same process, from development to code review to testing to deployment. We’ve worked together, over many years, to lay out processes and procedures that allow our work to be completed with consistency and by almost anyone on the team (or project). We refine these processes continually (see the next section for more on that) as we learn.

The point of agile/scrum is to deliver software quickly and to adapt as you learn. This is why custom software systems start with an MVP, a minimum viable product. Instead of building an entire system end-to-end, which typically takes months or years, you build an MVP and then you iterate, iterate, iterate.

 

In the spirit of continuous improvement, we’re always working to improve our processes and how we use agile/scrum. At the end of each sprint, we take time to reflect on how the last iteration went, celebrate wins, and brainstorm ways to make ourselves and our processes even better. This happens at the retrospective, aka retro. 

Retros can take on nearly any format—as with most things in scrum, there’s no defined structure. We try to mix it up so we’re not doing the same thing every two weeks. But our goal is still the same: to identify any areas for improvement and figure out how we’re going to get better. 

We spend a lot of time and effort on how we can get better at delivering custom software for clients. Sprint by sprint, we make small but consistent improvements. No single change stands out, but together, our work style looks remarkably different—and in our opinion, better—than when we started implementing agile/scrum in 2015.

Agile methodologies are the leading philosophy behind custom software development. The frameworks you might hear about—like devops, kanban, extreme programming, feature driven development, and more—are standard today because agile principles work. 

As a client, you benefit when we improve...which we’re always doing. Your custom software is built in priority order, you get to a working MVP fairly quickly, and you can continually enhance and improve your system using the feedback the software’s users have given you. 

You’re not waiting 18 months for a working product, just to find out it’s already obsolete (RIP waterfall methodology) or that what you built isn’t what your users actually needed. You can adapt to changes as they happen and stay, well, agile. You can build software systems with less risk, more control over budget, and complete transparency. 

We’re highly invested in agile/scrum because we’ve seen the benefits, for both our team and our clients.

Implementing agile—using scrum or whatever framework makes the most sense for your organization—is truly a transformation. You have to have strong leadership, team buy-in, and commitment to being the best, most effective team you can be. 

We started our agile journey by reading a scrum book together in our Far Reads Book Club. We had team members willing to lead the transition, and the whole team was (and still is) bought in to making Far Reach an agile/scrum team.

Just like agile looks different at every company, department, or team, the implementation process is different for everyone. Learning how to work together, and how to work on how you work, is part of the journey.

Here’s how we’ve helped clients by using agile/scrum.

Want to dive deeper into agile/scrum? Read some of our blog posts on the topic.

• 

  READ

  What is an MVP in Software Development?

• 

  READ

  Scrum Core Values

• 

  READ

  Small Steps: Continuously Improving

If you want your custom software to be built by a team that’s always getting better, reach out. We use agile/scrum to build custom software for clients because it's proven to work.