Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developer.upsun.com/llms.txt

Use this file to discover all available pages before exploring further.

This post was originally published on the Platform.sh blog and reflects information from the time of publication.
Scrum is easy to do badly, and hard to do well. One of its main challenges is effectively managing changes in a way that doesn’t cause conflicts. What is not regularly understood is that this is often a symptom of the testing and deployment infrastructure and is therefore hard to solve using Scrum techniques alone. Platform.sh’s development model unblocks Scrum projects and allows them to run how Scrum was supposed to.

​
What is Scrum?

Scrum is probably the most popular of the methods we generally call Agile. In Scrum, individual User Stories or Features are prioritized for development and estimated, then organized into a series of Sprints of equal lengths (usually between one week and a month). Sprints are planned just before each Sprint begins, which ensures that only the most important work at that time is scheduled. The team shepherded by a Scrum Master, however it is the team who is responsible for ensuring that the stories are completed. A lot of emphasis in Scrum is placed on the communication between the team through Sprint Planning, daily Stand-up meetings, and Retrospectives. Scrum is relatively easy to get your head around, as it places only a few restrictions on the development team, buyt it can be difficult to get right. Two of the biggest challenges of Scrum that can seriously impact on its efficiency are testing and feature conflicts.

​
Managing conflicts

When using scrum, teams can very easily get caught in a cycle of rework which blocks other activity. Testing and quality assuring Features together is often necessary. The only way to do this, however, is usually in the main integration branch, and this leads to issues with rework, bugs, and (in the worst case scenario) backing out if something has failed testing. This last problem is the most nefarious, as it requires rebuilding the integration environment from a known good point (usually production) and reapplying changes from good features that have not been released, or alternatively continuing with the knowledge that your integration environment is now out of sync with production. Take, for example, a basic Scrum development pattern where multiple feature branches are made off of a production branch (Figure 1). Figure 1 Feature1 gets tested first in the single test environment, and because it’s now ready to go, further changes are simply deployed on top of it (Figure 2). That all works fine until someone decides that feature2 isn’t production ready… Merging and testing So testing features in isolation is desirable, however this is not realistically possible when running a single testing server. Testing multiple, regularly changing feature branches locally adds a considerable resource overhead and testers often do not have the necessary skills to spin up test environments for every change, let alone do it quickly. You might be able to automate this, but that will suck considerable time and resources out of your budget. Essentially, having only a single testing or QA environment can seriously hamstring even the most diligent Scrum team. Scrum allows the team a lot of self-management, but this comes at a price. Inevitably, because we can’t all be good at everything and must divide the work up between people with different skills, Scrum projects often end up with a lot of pieces of work happening simultaneously. This will often lead to a situation where there are features in the project which conflict with each other a a code level. Without an environment for each branch, testing and quality assurance of individual features can only happen when merged into the main development branch. If one of them is rejected or conflicts, you’ve got a major headache. More likely, many will need fixes or changes, which effectively makes your development branch unreleasable. Welcome to hell.

​
Scrum on Platform.sh

So how is Scrum different on Platform.sh? Our unique git-based environment workflow unblocks individual features and allows you not only to work the way Scrum intends, but also helps you when things go wrong. Scrum demands that we isolate features into workable Stories or Features. Platform.sh gives you a complete development environment for every git branch, with real production data, which unblocks testing for these Stories, while simultaneously enabling parallel development. Platform.sh enables better branching Features can now be kept nicely inside individual development branches in your version control system and only merged when ready. Even better, since the aim of scrum is to build in sprint-sized iterations, you can also use Platform.sh’s unique child environment branching to isolate your work further. Merging and testing With this structure, individual features can be properly tested, reviewed in concert with other features, and demonstrated in the sprint review. What’s more, if you happen to overlap your sprints for some horrible (but entirely plausible) reason you can start the next Sprint independently of the current one, without risk of collision. Something like a broken feature, that would risk a Sprint completion under normal circumstances, can simply be omitted in a new integration branch in a matter of minutes (Figure 5). Better merging

​
What’s next?

Doing Scrum right is just one of the many ways you can use Platform.sh. If you’d like to learn more about how to use Platform.sh your way, get in touch.
Last modified on April 30, 2026