Build better software learning from customers and iterating as you go.
Need some scrum motivation? Download our scrum posters to hang on your wall or use as a digital background.
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
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.
Get these principles as posters. Download the free graphics.
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.
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.
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.
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.
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.
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.
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.
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.
Peterson Genetics and Far Reach used agile/scrum to build a custom ERP—and even integrated scrum processes into system workflows.
Mortgage MarketSmart is an ever-evolving product. Far Reach and iEmergent use agile/scrum to prioritize work and continue to build out the enterprise product.
Far Reach helped Iowa Heartland Habitat for Humanity integrate agile/scrum into their processes as they implemented a project management system.
Want to dive deeper into agile/scrum? Read some of our blog posts on the topic.
Type the code from the image