We've covered the Software Development Life Cycle (SDLC) and the Agile development framework. Now it's time to look at different methodologies and approaches to their implementation. There are several, but we'll focus in this article on just two of them, Scrum and Extreme Programming (XP). We'll look at the differences between them and how they can even be used together for even better results.

What is Scrum?

Scrum is a lightweight approach to Agile software development. It helps teams and organizations create value through flexible and cooperative development and problem-solving. It breaks down complex projects into logical and manageable chunks.

Scrum uses a Scrum Master to build and maintain an environment where:

1. The Product Owner orders the work for a complex problem into a Product Backlog;

2. The Scrum Team turns part of that work into an ‘increment of value’ during a Sprint;

3. The Scrum Team and its stakeholders review the results and adjust for the next Sprint;

4. Repeat.

The Scrum 'pillars' are transparency, inspection and adaptation. These pillars are expressed and addressed through all 'events' during any particular 'Sprint'. The 'events' in a Scrum are:

The Sprint

The 'Sprint' contains all of the Scrum events. They are the manageable chunks that make up the entire project. It is during the Sprint that ideas are turned into value. Through a series of 'sprints', the project is finished. A Sprint cycle in Scrum will consist of a month or less of development time.

During the Sprint:

• No changes are made that would undermine the Sprint Goal;

• Quality does not suffer;

• The Product Backlog is adjusted as needed; and,

• The scope of the Sprint may be refined and redefined with the Product Owner as more is learned.

The Sprint is further divided into the following events:

Sprint Planning

Sprint Planning kicks off the Sprint by defining the work to be performed in the Sprint. The resulting plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning asks (and answers!) the questions Why? What? And how? Why are we setting these particular goals for this Sprint? What do we plan to do? How will we achieve the(se) Sprint goal(s). While this happens at the beginning of every Sprint, it is reinforced (and/or modified) at each ‘daily scrum’. This allows for both inspection and adaptation.

Daily Scrum

The Daily Scrum is a 15-minute stand-up meeting of the entire Scrum Team. Its purpose is to inspect (assess) progress toward the Sprint Goal(s). It's also an opportunity to adapt the Sprint Backlog as necessary, adjusting the day’s upcoming (previously-planned) work. This creates focus and improves self-management.

Daily Scrums promote better communication, help to identify stumbling blocks, allow for quick decision-making, and eliminate further and needless meetings.

Sprint Review and Sprint Retrospective

Sprint Review involves the presentation of all of the work accomplished during the Sprint. Sprint Retrospective identifies what went well, what went wrong and how the development process may be improved for the next Sprint. The next Sprint begins the following day and this cycle repeats until the project is finished. Learn more about the topic in Sprint Reviews and Sprint Retrospectives blog post.

What is Extreme Programming (XP) and how is it different from Scrum?

In an XP project, work happens in short(er) iterations that can last from one to three weeks. Before each iteration, the development team and all relevant stakeholders decide how much work can be done during that period. The customer prioritizes the work that needs to be done, and the team members commit to the amount of work they estimate they can deliver during that particular iteration.

As opposed to Scrum, development ‘sprints’ (iterations) are much shorter, so production is quicker and the feedback loop is tighter. While Scrum relies more on self-management, XP is much stricter in its engineering practices. XP engineers must:

• write unit tests before the production code (Test-Driven Development);

• use pair-programming when writing production code;

• pairs must integrate their code often (continuous integration);

• refactor the code as often as possible;

• adopt 'collective ownership' of the code (this allows for better collaboration and integration = fewer bugs and cleaner code).

Related post: Agile vs. Scrum: Which is better for your project?

The Difference is in the details:

Scrum and XP are both approaches to and methodologies of Agile software development, so they have a lot in common. While the differences may be subtle, they're very important:

1. Scrum teams usually develop in iterations (called Sprints) that are from two weeks to one month long. XP teams tend to develop in iterations that are one to two weeks long.

2. Scrum teams do not allow for any major changes in their Sprints. Once the Sprint Planning meeting is completed and a commitment made to delivering a set of Product Backlog items, that set of items is set in stone. XP teams are much more flexible within their iterations and can easily swap out a major requirement, provided work has not yet begun on it.

3. XP teams work in a strict priority order. Features are prioritized by the customer (Scrum’s Product Owner) and the team works on them in that particular order. By contrast, it’s the Scrum Product Owner who prioritizes the Product Backlog. But it's the team that determines the sequence in which they will develop those items.

4. Scrum doesn’t prescribe any engineering practices; XP does - a lot (see above).

Both approaches provide flexibility and adaptability, but at different points and levels of the development cycle. See the table below:

Both frameworks have a lot to offer, so which to choose? Well, that depends on the project and the team, but the good news is you don’t have to choose! You can apply the best practices and approach of both; perfectly-suited to each individual project! Here at Blocshop, we rely mostly on Scrum for our projects, as we feel it provides the greatest flexibility and freedom to our developers while still focusing on outcomes. But we also apply aspects of other methodologies depending on project and customer requirements. We are always open to fashioning an individual, per-project, hybrid methodology to overdeliver, early and under budget, the cleanest code and maximize customer value.