Does Scrum deliver an Agile website?

My experience working for an enterprise-level website using Scrum methodology for Agile development has been enlightening. Does Scrum work? That depends on many factors!

How Agile are you?

At its core, "Agile" is a development methodology enabling production teams working on complex problems to respond efficiently to new requirements. These requirements may come from anywhere, including the development process itself or external market forces. Agile processes are good at minimising risk, providing predictability and oversight, and providing a high return on investment.

There are many approaches to Agile development. If you and your team adopt a well-defined methodology, you can realize some key benefits. I’ve found that developing with the Scrum method can work.

To be Agile, your team must:

• Break the product into independently manageable chunks
• Accurately gauge what can be accomplished
• Communicate well
• Remain committed to the process

This enables you to consistently deliver what is promised, and to release changes frequently.

Here are some important details of an Agile web development project, in the context of the Scrum methodology.

Compartmentalize your project

Agile projects must be broken down into small parts that can be independently modified. The example project in this post is a large website powered by the eZ Platform content management system (CMS). eZ relies on the use of templates (down to individual templates for small elements such as links) to standardize the way your website displays different kinds of pages and data. This lends itself nicely to breaking a website down to smaller and smaller components. As a team, you still have to take advantage of this flexibility as much as possible. The smaller the components are, the more easily they can be updated without impacting other sections.

Communication is key

A product such as an enterprise-level website is expected to be updated on a regular basis. This doesn’t stop at content, although that’s important. The product owner is constantly considering ways to improve how the content is being presented. What is the feedback from your users? Does the product owner want new features added? In an environment of constant tweaks and updates, you'll need good communication.

I hope you like meetings and people. Do you come from the school of programmers that prefer to jump into a task and forge ahead to a solution, to forget all this chit-chat and get straight to coding? The Agile philosophy is not compatible with such an approach.

Work is organized in sprints -- in this particular case, 2-week sprints. Our Scrum requires a lot of meetings and discussion before the work for a sprint begins. This includes sprint planning, daily standups, topic-focused breakout meetings, sprint reviews, sprint demos, and sprint retrospectives. At first it seems daunting to watch your schedule fill up. When am I going to actually get any work done?

Meeting frequently with the entire team keeps everyone in the loop. Are you having a problem with your task? Someone can help. Is your plate full? Can you take on something else, or help another team member who is stuck? Every day we meet to monitor everyone’s progress. The sooner problems are known about, the sooner they can be solved before they throw the sprint off the rails.

One member of the team is identified as the Scrum Master. The Scrum Master has the responsibility for setting up and running meetings and liaising between the developers, designers, product owners, and stakeholders. All communication should flow through this person.

It’s worth remembering that you aren’t the only one invested in the task you have been assigned. Plus, with the way the meetings have been set up for our project, we discuss an issue 2 or 3 times with the entire team. We follow a basic workflow:

• An issue is identified
• Solutions are discussed
• The issue is sized
• The issue is included in a sprint for implementation

Let's look more closely at sizing an issue.

Sizing an issue

Sizing or estimating an issue comes in 2 steps. First, a general consensus is taken on how big the issue is. For this we use “T-shirt” sizing such as S or XL. We might say "S-M" if we’re not sure which way the issue will be solved, or if perhaps we need more information. This helps to prioritize and generally schedule the work.

The next time we review the issue, we give it a point value. (A point is essentially 1 hour of work for 1 person.) For this, we adopt sort of a silent auction approach. All of the members of the development team give their best guess by way of flash cards as to how much effort will be required to complete the task. It’s important that everyone votes at the same time so as to not be influenced by each other. For several reasons, such as having a common scale and increasing the range between higher estimates, we use the Fibonacci sequence for point or hour estimates. The Scrum Master will review everyone’s “vote” and come up with an average. Usually we have a small spread of points for an issue, such as 3 estimates of 8 points and 1 estimate of 13 points. If the votes are wildly different, then more discussion is held. Perhaps somebody knows something the rest of the team is missing.

Does it work?

I have found that committing completely to a Scrum approach yields predictable work sprints. We have been able to faithfully gauge how much work we can get done, and more often than not we are able to take on extra work that may come up during the sprint, while managing scope creep carefully. The product owners and stakeholders can depend on our ability to fulfill their directives in a timely fashion.

After every sprint, we analyze what we took on for the development cycle. Did we deliver? We tally up the points on all of the issues that were resolved. How did we do? The total number of points is referred to as our velocity. Currently we are working at a velocity of around 140 points every 2 weeks. When we set up the next sprint, we’ll be cognizant of that number. We might have to adjust for situations that may impact our ability to deliver, including statutory holidays or days that a team member may be away.

So yes, Scrum and Agile do deliver! And if a particular sprint doesn't quite deliver, we have an opportunity to discuss and enact improvements quickly.