Design & UX
Alex Walker, Jul 05

SitePoint/Flippa Hack Day: Hacking our First IoT Project

We'd all played with computers for years but SitePoint's Hack Day gave us a chance to make electronics with our first IoT project.
Elio Qoshi, Jul 04

Why the Internet of Things Still Has a Long Way to Go

Elio Qoshi looks at why he is hesitant to adopt the IoT or recommend it to consumers — security, quality and transparency concerns.
Design & UX
Charles Costa, Jul 04

The 4 Unique Design Challenges of IoT

Designing for IoT – the Internet of Things – offers great opportunities, but also a new range of challenges. Charles Costa walks you though the big 4. 
Craig Buckler, Jul 01

Browser Trends July 2016: Is a Chrome Monoculture Harmless?

The chasm between Chrome and the other browsers is widening. Craig discusses this new monoculture may be less dangerous than the IE6 days but remains cause for concern.
Thomas Punt, Jun 29

Elixir's Ecto Querying DSL: Beyond the Basics

Thomas explores Ecto features, including query composition, joins and associations, SQL fragment injection, explicit casting, and dynamic field access.
Adam Bard, Jun 28

Heroku Alternative: Deploy Apps with Dokku on DigitalOcean

Adam Bard shows how to get small, low-traffic projects up and running with Dokku on DigitalOcean, creating a Heroku-like experience without the cost.
Thomas Punt, Jun 24

Understanding Elixir's Ecto Querying DSL: The Basics

Thomas looks at the basics of querying with Elixir's Ecto library, going through joins, associations, aggregation functions, and so on.
Angela Molina, Jun 20

Spreading the Word on WordPress Security

Did you know that WordPress powers a third of the web, and a popular target for attackers? This week we chat to Chris Burgess on WordPress Security.
Thomas Punt, Jun 15

An Introduction to Elixir's Ecto Library

Thomas introduces Ecto, Elixir's predominant library for working with databases, building a simple database-driven app using Ecto's four main components.
Bruno Skvorc, Jun 15

The PHP Application Environment

This is an excerpt from SitePoint's recent book on PHP Application Environments and get getting started the right way. Enjoy this preview!
Craig Buckler, Jun 14

Blisk: Your Next Web Development Browser?

Most of us use our default browser for development. Is it practical? Are there better options? Craig looks at Blisk — a new development-only browser.
James Hibbard, Jun 13

A Round up of Online Code Playgrounds

James Hibbard looks at some of the more popular online code playgrounds and examines which are good for hosting demos involving a server-side components.
Hugo Giraudel, Jun 10

The Importance of Code Reviews

Hugo discusses the importance of code reviews, and how to get them happening within your development team.
Lukas White, Jun 09

How to Modernize a Booking System with Acuity Scheduling

Lukas White shows you how to bring a driving instructor's booking system into the 21st century using the Acuity Scheduling API.
Shaumik Daityari, Jun 08

Jump Start Git: Branching in Git


The following is a short extract from our book, Jump Start Git, available for free to SitePoint Premium members. Print copies are sold in stores worldwide, or you can order them here. We hope you enjoy this extract and find it useful.

In Chapter 1, I talked about my one-time fear of trying out new things in a project. What if I tried something ambitious and it broke everything that was working earlier? This problem is solved by the use of branches in Git.

What Are Branches?

Creating a new branch in a project essentially means creating a new copy of that project. You can experiment with this copy without affecting the original. So if the experiment fails, you can just abandon it and return to the original—the master branch.

But if the experiment is successful, Git makes it easy to incorporate the experimental elements into the master. And if, at a later stage, you change your mind, you can easily revert back to the state of the project before this merger.

So a branch in Git is an independent path of development. You can create new commits in a branch while not affecting other branches. This ease of working with branches is one of the best features of Git. (Although other version control options like CVS had this branching option, the experience of merging branches on CVS was a very tedious one. If you've had experience with branches in other version control systems, be assured that working with branches in Git is quite different.)

In Git, you find yourself in the master branch by default. The name “master” doesn't imply that it's superior in any way. It's just the convention to call it that.

Note: Branch Conventions

Although you're free to use a different branch as your base branch in Git, people usually expect to find the latest, up-to-date code on a particular project in the master branch.

You might argue that, with the ability to go back to any commit, there's no need for branches. However, imagine a situation where you need to show your work to your superior, while also working on a new, cool feature which is not a part of your completed work. As branching is used to separate different ideas, it makes the code in your repository easy to understand. Further, branching enables you to keep only the important commits in the master branch or the main branch.

Yet another use of branches is that they give you the ability to work on multiple things at the same time, without them interfering with each other. Let's say you submit feature 1 for review, but your supervisor needs some time before reviewing it. Meanwhile, you need to work on feature 2. In this scenario, branches come into play. If you work on your new idea on a separate branch, you can always switch back to your earlier branch to return the repository to its previous state, which does not contain any code related to your idea.

Let's now start working with branches in Git. To see the list of branches and the current branch you're working on, run the following command:

[code language="bash"]git branch [/code]

If you have cloned your repository or set a remote, you can see the remote branches too. Just postfix -a to the command above:

[code language="bash"]git branch -a [/code] [caption id="attachment_131959" align="alignnone" width="264"]Command showing the branches in the local copy as well as the origin branch Command showing the branches in the local copy as well as the origin branch[/caption]

As shown above, the branches that colored red signify that they are on a remote. In our case, we can see the various branches that are present in the origin remote.

Create a Branch

There are various ways of creating a branch in Git. To create a new branch and stay in your current branch, run the following:

[code language="bash"]git branch test_branch [/code]

Here, test_branch is the name of the created branch. However, on running git branch, it seems that the active branch is still the master branch. To change the active branch, we can run the checkout command (shown below):

[code language="bash"]git checkout test_branch [/code] [caption id="attachment_131988" align="alignnone" width="300"]Creating a new branch and making it active Creating a new branch and making it active[/caption]

You can also combine the two commands above and thereby create and checkout to a new branch in a single command by postfixing -b to the checkout command:

[code language="bash"]git checkout -b new_test_branch [/code] Create and checkout to a new branch in a single command

The branches we've just created are based on the latest commit of the current active branch—which in our case is master. If you want to create a branch (say old_commit_branch) based on a certain commit—such as cafb55d—you can run the following command:

[code language="bash"]git checkout -b old_commit_branch cafb55d [/code] [caption id="attachment_131995" align="alignnone" width="575"]Creating a branch based on an old commit Creating a branch based on an old commit[/caption]

To rename the current branch to renamed_branch, run the following command:

[code language="bash"]git branch -m renamed_branch [/code]

Delete a Branch

To delete a branch, run the following command:

[code language="bash"]git branch -D new_test_branch [/code] [caption id="attachment_131996" align="alignnone" width="300"]Deleting a branch in Git Deleting a branch in Git[/caption]

Note: Don't Delete Branches Unless You Have To

As there's not really any downside to keeping branches, as a precaution I'd suggest not deleting them unless the number of branches in the repository becomes too large to be manageable.

The -D option used above deletes a branch even if it hasn't been synchronized with a remote branch. This means that if you have commits in your current branch that have not been pushed yet, -D will still delete your branch without providing any warning. To ensure you don't lose data, you can postfix -d as an alternative to -D. -d only deletes a branch if it has been synchronized with a remote branch. Since our branches haven't been synced yet, let's see what happens if we postfix -d, shown below:

Deleting a branch in Git using the -d option

As you can see, Git gives you a warning and aborts the operation, as the data hasn't been merged with a branch yet.

Branches and HEAD

Now that we've had a chance to experiment with the basics of branching, let's spend a little time discussing how branches work in Git, and also introduce an important concept: HEAD.

As mentioned above, a branch is just a link between different commits, or a pathway through the commits. An important thing to note is that, while working with branches, the HEAD of a branch points to the latest commit in the branch. I'll refer to HEAD a lot in upcoming chapters. In Git, the HEAD points to the latest commit in a branch. In other words, it refers to the tip of a branch.

A branch is essentially a pointer to a commit, which has a parent commit, a grandparent commit, and so on. This chain of commits forms the pathway I mentioned above. How, then, do you link a branch and HEAD? Well, HEAD and the tip of the current branch point to the same commit. Let's look at a diagram to illustrate this idea:

[caption id="attachment_132000" align="alignnone" width="609"]Branches and HEAD Branches and HEAD[/caption]

As shown above, branch_A initially is the active branch and HEAD points to commit C. Commit A is the base commit and doesn't have any parent commit, so the commits in branch_A in reverse chronological order (which also forms the pathway I've talked about) are C → B → A. The commits in branch_B are E → D → B → A. The HEAD points to the latest commit of the active branch_A, which is commit C. When we add a commit, it's added to the active branch. After the commit, branch_A points to F, and the branch follows F → C → B → A, whereas branch_B remains the same. HEAD now points to commit F. Similarly, the changes when we add yet another commit are demonstrated in the figure.

Advanced Branching: Merging Branches

As mentioned earlier, one of Git's biggest advantages is that merging branches is especially easy. Let's now look at how it's done.

We'll create two new branches—new_feature and another_feature—and add a few dummy commits. Checking the history in each branch shows us that the branch another_feature is ahead by one commit, as shown below:

[caption id="attachment_132001" align="alignnone" width="546"]Checking the history in each branch Checking the history in each branch[/caption]

This situation can be visualized as shown below. Each circle represents a commit, and the branch name points to its HEAD (the tip of the branch).

[caption id="attachment_132005" align="alignnone" width="1024"]Visualizing our branches before the merge Visualizing our branches before the merge[/caption]

To merge new_feature with master, run the following (after first making sure the master branch is active):

[code language="bash"]git checkout master git merge new_feature [/code]

The result can be visualized as shown below:

[caption id="attachment_132007" align="alignnone" width="1024"]The status of the repository after merging new_feature into master The status of the repository after merging new_feature into master[/caption]

To merge another_feature with new_feature, just run the following (making sure that the branch new_feature is active):

[code language="bash"]git checkout new_feature git merge another_feature [/code]

The result can be visualized as shown below:

[caption id="attachment_132009" align="alignnone" width="1024"]The status of the repository after merging another_feature into new_feature The status of the repository after merging another_feature into new_feature[/caption]

Important: Watch Out for Loops

The diagram above shows that this merge has created a loop in your project history across the two commits, where the workflows diverged and converged, respectively. While working individually or in small teams, such loops might not be an issue. However, in a larger team—where there might have been a lot of commits since the time you diverged from the main branch—such large loops make it difficult to navigate the history and understand the changes. We'll explore a way of merging branches without creating loops using the rebase command in Chapter 6.

[caption id="attachment_132011" align="alignnone" width="551"]The status of branch new_feature after the merge The status of branch new_feature after the merge[/caption]

This merge happened without any “conflicts”. The simple reason for that is that no new commits had been added to branch new_feature as compared to the branch another_feature. Conflicts in Git happen when the same file has been modified in non-common commits in both branches. Git raises a conflict to make sure you don’t lose any data.

We’ll discuss conflicts in detail in the next chapter. I mentioned earlier that branches can be visualized by just a simple pathway through commits. When we merge branches and there are no conflicts, such as above, only the branch pathway is changed and the HEAD of the branch is updated. This is called the fast forward type of merge.

The alternate way of merging branches is the no fast forward merge, by postfixing --no-ff to the merge command. In this way, a new commit is created on the base branch with the changes from the other branch. You are also asked to specify a commit message:

[code language="bash"]git merge --no-ff new_feature [/code]

In the example above, the former (merging new_feature with master) was a fast forward merge, whereas the latter was a no fast forward merge with a merge commit.

While the fast forward style of merges is default, it’s generally a good idea to go for the no fast forward method for merges into the master branch. In the long run, a new commit that identifies a new feature merge might be beneficial, as it logically separates the part of the code that is responsible for the new feature into a commit.


What Have You Learned?

In this chapter, we discussed what branches are and how to manage them in Git. We looked at creating, modifying, deleting and merging branches.

What’s Next?

I’ve already spoken about how Git is beneficial to developers working in teams. The next chapter will look at this in more detail, as well as specific Git actions and commands that are frequently used while working in a distributed team.

Camilo Reyes, Jun 08

3 Ways to Work More Effectively in a Web Development Team

Camilo Reyes shares some important tips on working effectively in a team, growing as a programmer, and stepping up as a leader.
Craig Buckler, Jun 01

Browser Trends June 2016: Microsoft Misfortune

Mozilla overtook IE/Edge browsers last month and there's more grim news for Microsoft. Craig discusses the company's future.
Jamie Shields, Jun 01

Harnessing the Google Maps JavaScript API the Right Way

Jamie Shields walks through best practices for getting started with the Google Maps JavaScript API.
Craig Buckler, May 31

How to Improve Page Performance and Make the Most of Your Hosting

Craig Buckler looks at the best way to optimize your web hosting server and your website for better performance.
Mike Street, May 27

12 Favorite Atom Tips and Shortcuts to Improve Your Workflow

Mike Street shares his favorite, time-saving tips, packages and shortcuts for GitHub's Atom code editor.
Design & UX
Alex Walker, May 26

Make Your Own Responsive SVG Graphs & Infographics

It doesn't matter how crisp your SVG text is if it's too small to be read. Responsive SVG lets you prioritize the important parts of you graphic.
Chris Ward, May 25

Teaching Programming: What's the Best Language for Beginners?

With programming skills becoming an increasing priority, Chris reflects on approaches to learning code and lessons learned from educating beginners.
Jehan Fillat, May 24

Please: Automated CMS and Framework Installs in Vagrant

Jehan introduces Please, a bash script for automating the installations of many CMSs and Frameworks by configuring them automatically into your Vagrant box.
M. David Green, May 22

Power Up Your Team by Using Scrum Properly


The following is a short extract from our recent book, Scrum: Novice to Ninja, available for free to SitePoint Premium members. Print copies are sold in stores worldwide, or you can order them here. We hope you enjoy this extract and find it useful.

What Is Scrum?

If you picked up this book to learn about applying scrum to your web or mobile development team, you may already be familiar with the terms scrum and agile. Perhaps you received this book from your company, or maybe you've been tasked with implementing an agile process in your own organization. Whatever the reason, it's always useful to start with a clear, shared definition of the relevant terms.

Scrum is one of several techniques for managing product development organizations, lumped under the broad category of agile software development. Agile approaches are designed to support iterative, flexible, and sustainable methods for running a product engineering organization.

Among the various agile techniques, scrum is particularly well suited to the types of organizations that develop products such as websites and mobile software. The focus on developing cohesive, modular, measurable features that can be estimated relatively, tracked easily, and that may need to adapt quickly to changing market conditions makes scrum particularly appropriate for these types of projects.

Scrum encourages teams to work in a focused way for a limited period of time on a clearly defined set of features, understanding that the next set of features they may be asked to work on could be unpredictable because of changes in the marketplace, feedback from customers, or any number of factors. Scrum allows teams to develop an improved ability to estimate how much effort it will take to produce a new feature in a relative way, based on the work involved in features they've developed before. And scrum creates the opportunity for a team to reflect on the process and improve it regularly, bringing everybody's feedback into play.

Warning: Don't Confuse Merely Applying Scrum Terms with Actually Using Scrum

A familiar anti-pattern in non-agile organizations looking to mask their process problems is using the terminology of scrum as a labeling system on top of their waterfall techniques and tools. That can create confusion, and even negative associations among people who have seen these terms used incorrectly, and who mistakenly believe they've seen scrum in action.

As we go through this book, you're going to find out more about how scrum functions. You're going to be introduced to all of the aspects of scrum, including its rituals, its artifacts, and the roles that it creates for the people in an organization. We're going to introduce you to a team of people working in a scrum environment, and show you how they adopted scrum in the first place, and how they adapted to it.

Before we get there, it's worthwhile taking a moment to position scrum in its historical context. After all, scrum isn't the only way to organize product development. Scrum came into existence right around the time that web development emerged on the engineering landscape, and it flourished as mobile technology became part of our daily lives. If you consider how scrum works, where it came from, and how we apply it, I think you'll see that there might be a reason for that.

Note: Scrum's Odd Vocabulary

The vocabulary of scrum is distinctive, and may sound odd. That's intentional. Scrum uses terms such as ritual, artifact, and story to make it clear that these concepts are different from related ideas that may be encountered in other project management approaches.

A Brief History of Scrum

The original concept for scrum came out of Japan, introduced in 1986 as part of The New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. They applied the concept of a scrum, taken from the team game rugby, to describe cross-functional team organization based around moving forward in a layered approach.

Their concepts were codified as the Scrum Methodology at a joint presentation in 1995 by Ken Schwaber and Jeff Sutherland, based on their personal experiences applying the concepts in their own organizations. This work inspired the 2001 book, Agile Software Development with Scrum, written by Schwaber and Mike Beedle.

At the time, the most prevalent approach for software development was called the waterfall model. Under the waterfall model, product development happens in stages, leading sequentially from requirements through design, implementation, and release. Until the 1990s, most software development was targeted at packaged software delivery for desktop computers. Such products had long development and release cycles. While waterfall is well-suited to products that have a long development trajectory, it doesn't adapt well to situations where the product needs to change constantly in response to changing conditions.

In the mid-to-late 1990s, new publishing models emerged involving electronic media and the Internet. To support these, software development organizations had to incorporate more flexibility to adapt to changing browsers, tight media deadlines, and a variety of platforms with different requirements. Soon after that, the development of large monolithic software applications that lived on desktop computers gave way to smaller, more nimble apps that were delivered through mobile devices. A different approach was needed for developing these.

It isn't a coincidence that agile approaches became codified, and quickly became popular, just as the marketplace was shifting from desktop software to web and mobile software.

Comparing Scrum and Waterfall

The slow cycle of waterfall development may still be appropriate in a world of hardware development, or even in gaming. These industries rely on long, stable markets, where many of the decisions are either repetitive, constrained by external resources, or need to be made far in advance because of the massive scale and expense of development.

Web and mobile technology moves too fast for a waterfall approach. By the time you're done developing a solution to one problem and gathering feedback from users, the technology has already moved on, and you may have a very small window of opportunity to capitalize on your solution.


Figure 1.1. Waterfall

In a waterfall approach, the ideas for what needs to be developed may come from customers, from the executives, from market research, or from the imagination of people making the decisions and setting the budgets. Those ideas are passed on to product managers, who create a long product roadmap. They establish and collect requirements, write out classic product requirement documents, and then pass those requirements on to designers to create prototypes as wireframes and mockups. Those prototypes are passed on to an engineering team that implements those ideas, and produces a product that can finally be released to the marketplace. Until that product is released and put in the hands of customers, no feedback into the process is generated.

Agile Organization

Figure 1.2. Agile Organization

In an agile organization, guiding objectives and key performance indicators guide the process, but the team manages itself to meet those objectives. A product owner maintains the overall vision, and works with the scrum master to make sure that everyone on the team is clear about the objectives and how they'll be measured. The input of the designers and the engineers is included at every stage in this process. Features are conceived and formulated into stories when the team is ready to work on them. No idea gets locked into a static product timeline.

The value to a company of hiring its own team of designers and engineers is that these people can bring their design thinking and their current technical knowledge to the table for the benefit of the organization's own objectives. Designers should be evaluating the user experience and figuring out the best solutions to real customers' problems, not decorating bad ideas to make them functional.

Getting engineers involved in ideation allows them to pull in the latest technology as early as possible, since they're in the best position to know what's technically feasible. The sooner the designers and engineers are brought into the planning process, the more agile development will be.

Scrum allows the full resources of the team to be applied when and where they can do the most good, and to work together in a sustainable and productive way. Instead of waiting until the entire cycle has completed before any data can be fed back into the system, ideas are generated at every stage, and encouraged to bubble to the surface at the end of each sprint. Total participation of the team in every stage of the process allows these ideas to feed into the objectives, and support the vision of the organization.

Warning: Mixing Scrum With Waterfall

Waterfall (With Scrum for Engineering)

Figure 1.3. Waterfall (With Scrum for Engineering)

While some organizations may claim to follow scrum, many of them actually follow a modified waterfall approach, using scrum techniques only for development. The rest of the organization structures itself around long-lived product timelines with static objectives. While that may be an improvement over pure waterfall, in that it allows the engineers to iterate and improve their process, it doesn't take full advantage of the potential of scrum. Isolating scrum inside the development loop without inviting the learnings of the team into the planning and market testing process is a waste of resources, and a wasted opportunity.

Mixing a little scrum into an otherwise waterfall organization is usually not a good idea, since it can draw attention to the fundamental conflicts between the different approaches, and foster friction.

Reasons to Choose Scrum for Web and Mobile

We've covered how scrum works, and why it's a productive way to structure web and mobile product development. At this point, it's worth taking a moment to recap some of the highlights of how scrum applies in particular to web and mobile product development.

Fundamentally, scrum offers a team-based approach to project work that allows a product development process to benefit from iterative self-reflection, helps a team learn how to estimate their own ability to address unfamiliar tasks, exposes metrics about team effectiveness, encourages dialogue about feature implementation instead of static specifications, and supports rapid response to changing market conditions in a sustainable manner.

All of those advantages can make a real difference when doing web and mobile development. Most work in web or mobile development tends to be very time sensitive, and needs to respond quickly to changes in the marketplace. Whether that means new browsers, new technologies, or new messaging that needs to be communicated immediately, web and mobile teams have to be able to respond quickly.

Scrum provides a framework that allows developers to work toward a vision, and the opportunity to shift direction as the environment changes without feeling torn away from their focus.

When following best development practices, the type of work that's involved in building and enhancing a web or mobile project tends to break down into discrete pieces that can be worked on independently, with a core of infrastructure stories that support a broad range of independent feature stories. This makes it easier for one part of a web or mobile project to be developed in isolation, and leverage the shared resources of other parts of the same project.

Scrum encourages teams to spell out the work on a new feature so that it can be developed in parallel, without relying on other undeveloped features. By using stories, and making sure each story is properly formatted and estimated, the team sets itself up for a consistent and productive development experience.

Note: Some Scrum Terms Defined

When scrum uses a word, it means just what scrum chooses for it to mean. But unlike Humpty Dumpty in Through the Looking Glass, scrum relies on familiar and easily understood definitions. Learning the language is one of the first steps in acquiring a new skill, and consistent use of language is fundamental to teams trying to work together. The terms below are only some of the ones that will be defined in much more detail later in the book, but a brief glance through these concepts may help as you read on.


a set of software development practices designed to help engineers work together and adapt to changes quickly and easily.


a physical or virtual tool used by a scrum team to facilitate the scrum process


anything keeping an engineer from moving forward on a task in progress


whoever has engaged the team to create a product


a person responsible for creating and maintaining the technology that goes into a product

Engineering Organization

the part of a company where engineers are employed to create and maintain products


what the engineering organization is building or maintaining for a customer

Product backlog

a constantly evolving list of potential features or changes for a product

Product owner

a person who helps define the product for the team, and whose job may be on the line if the customer isn't satisfied


a regular opportunity for the team to reflect on how they are doing, and what they could do better


a group of people coming together as part of the scrum process for a fixed time, with a specified agenda, to achieve a clearly defined outcome

Scrum Master

a person responsible for maintaining the artifacts and overseeing the rituals of scrum


a fixed number of days during which the team can work together to produce an agreed upon set of changes to the product

Sprint backlog

a finite and well-defined set of stories the team has agreed they can reasonably complete in the current sprint


a clear and consistent way of chunking, phrasing, and discussing work the team may need to do on the product


a person who will be making use of the product

Scrum is also flexible enough to support working styles for product owners who prefer to break down stories that can be completed in one week, two weeks, three weeks, four weeks or longer. While most web and mobile development teams tend to split the work into one- or two-week segments—known in scrum terminology as sprints—whatever the team agrees on should work. As long as the team is keeping track of how they work together, and they're given the opportunity to reflect on a regular basis about their schedules, scrum can adapt to work on projects ranging from the simplest to the most complex.

Time Sensitivity

Scrum provides opportunities in every sprint to integrate the ideas of designers, engineers, executives, customers, product managers, and customers through real customer data. Because of the cyclical nature of scrum, and the iterative approach that encourages learning as you go, scrum allows mobile and web projects to adapt to changing technologies and changing market expectations quickly.

Modular Development

Scrum supports the ability to develop a project in modules. Because scrum is based on thinking in terms of slices of functionality, it's perfectly suited for making independent, interoperable features that can be developed atomically and work together harmoniously.

For example, a new section for a website may inherit styling from a shared style guide and CSS structure, and may inherit its functionality from a shared template. The work to build out that section relies on those other components remaining static long enough to complete the work. Scrum provides the stability to support that, without limiting the development of the rest of the site.

At the same time, updating the infrastructure of a product to support a new feature may happen at any time in the process, so a team has to consider up front how to make those changes safely, without breaking the work being done on other features.

As another example, sometimes an API that every feature of the site relies on needs to be changed. Scrum encourages the team to manage the code in a modular, testable way, so that changes can be inherited by other feature stories that might be in progress without undue breakage.

Flexible Scheduling

Companies serving customers in the web and mobile space need to be able to respond quickly to changes. However, engineers need to be confident that what they're working on isn't going to change before they can get the feature developed. It can be difficult to balance those two objectives.

Scrum provides windows of opportunity that are long enough to allow a web or mobile feature to be fully developed, while still allowing a product to change directions at the end of each sprint, based on data from the marketplace.

Reflection and Improvement

A scrum team isn't only looking to improve the product: they're also looking to improve their own process. Scrum teams get better over time at estimating how much work they can do, and improving their approach to working so that they can be the most productive.

By giving the team the opportunity to look at its own process, and figure out how it works best together, scrum makes maximum use of the limited resources of any organization.


That was a quick overview of scrum, taken from a 30,000-foot perspective. We had a brief introduction to how scrum works, and why it can be effective for certain types of product development. We contrasted scrum with the more traditional waterfall approach for software development, and discussed why it emerged when it did. We also noted how well suited scrum is for web and mobile development projects.

But scrum isn't just an abstract concept and a bunch of unfamiliar buzzwords. Scrum is a practical and flexible approach to product development that relies on the active and engaged participation of real people. So in the next chapter, we're going to meet a few of the typical people who might work in a web or mobile development organization. We'll talk to them about some of their frustrations, find out what they hope to get out of scrum, and ask them about their concerns when they consider scrum.

As we go through this book, keep these people in mind. We'll be meeting them again, and following them through their process as they learn and start to apply scrum to their work.

Enjoyed this chapter? Download the entire book (and our entire book library!) by joining SitePoint Premium

We Teamed Up With SiteGround To bring you tried-and-true hosting, recommended for designers and developers.