Do Agile Methods Work for Smaller Projects?


Not for Profits
Small Businesses
Scrum turns traditional project management on its head

After I had been building websites for a few years, I came up with a piece of advice for clients.

Whatever budget they had, I recommended that they plan to build and launch a smaller site first, using say, just 60% of the budget. Then use the site for six months, and take what they learn from that experience to expand the website with the remaining 40%. That would result in a better website, and a better overall return on what they had invested in the website.

I didn’t consider at the time that I was recommending that they be Agile with their website project.

What is Agile?

Agile Software Development is a set of values and principles that turns the project management process on its head. It has a greater success rate at delivering software projects on time and within budget, compared to traditional project management methods - most commonly referred to as ‘waterfall’.

Scrum is a popular method of Agile Development, a “management and control process that cuts through complexity to focus on building products that meet business needs”.

Scrum in a Nutshell

The entire concept of Agile and Scrum when it comes to websites can be described as “launch early, and release often.”

Rather than try to build the website with every conceivable feature imaginable built and in place before launch, the site is built and launched in smaller increments - starting with an MVP (Minimum Viable Product). Features deemed to provide the site owner with the most return on investment would be built and launched first. After they are launched, feedback is solicited from users, the market and other website stakeholders. That feedback is used to improve the existing features and add new features deemed desirable.

The incorporation of this feedback into the software development process is known as the empirical process.

How Scrum Works

Scrum creates a period of time (Time Box) called a Sprint, with members of the Scrum Team working diligently during the Sprint to build a selection of features that they feel they can complete within the Sprint.

The length of the Sprint shouldn’t be longer than 30 days, but it can be shorter. Many organizations use a two week Sprint, for example - this "cadence" is the industry "sweet spot" as of this writing.

The Scrum Guide prescribes a minimum of three and a maximum of nine developers as part of the Scrum Team. That suggests that Scrum is for products that require more time to build.

What Does Scrum Address?

Scrum was primarily designed to address a certain type of project, be it big or small: One where there is a good deal of uncertainty as to what the final product should be.

Most software projects can’t possibly know all the requirements for a software program from the very beginning. So they run through a number of Sprints using Scrum, developing smaller increments of working software at a time, accepting feedback from users and stakeholders, and putting that feedback back into the development process.

So What About the Small Software Project?

Smaller projects experience the same uncertainty as larger projects. That uncertainty leads to budget overruns, and / or scope creep, creating tensions between a developer and a site owner. If anything, the levels of failure and frustration rates can be higher with the small project than the larger one.

So is there any way a small project, like a small or medium sized company website, could benefit from Scrum, and reduce uncertainty (and therefore risk)? What if there is just a sole web developer, interacting with the owner of a medium sized business, and at most, that business’s marketing executive?

How Scrum Concepts Can Help Small Projects

In these sorts of situations, many of the artifacts and events of Scrum can help the small project.

The Product Backlog. Probably the most important tool that a small project can use from Scrum is the Product Backlog. Creating the Product Backlog is an important process that allows someone called the Product Owner in Scrum (in this case that could be the site owner, coached by the site developer), and the site developer, to break down the various features desired and determine which features are the most important in terms of return on investment to the site owner.

The product backlog process permits the site owner and developer to determine what features will be the most important, before a nickel is spent on development work.

It permits the site owner to define those features for which the value, in terms of return on investment, are clear and high, and put them first.

The Sprint. A Sprint is defined as a work period defined by a specific time (in Scrum lingo a “time box”). For example, in the case of a small project, a sole developer might define a sprint for a small project as twelve hours to be performed in the course of a week, and assign a fixed price to it, say $2,000.

The client / website owner would then look at the Product Backlog together with the web developer and decide together which Product Backlog Items should be added to what’s called the Sprint Backlog (those features which would be built and completed in the Sprint). The Developer would have some greater sway in deciding what goes into that Sprint, with the idea being that it would be better to add fewer features, but have them done and ready to launch by the end of the Sprint.

The goal when adding Product Backlog items to the Sprint Backlog is that at the end of the Sprint, there should be specific increments of usable, working website features that are potentially ready to launch and subject to inspection by the site owner.

The Difference and the Benefits

You can see immediately how this differs from a traditional ‘waterfall’ website project pricing and planning. In a traditional scenario, you would define the scope of the project with the client / owner. You would also try to include every conceivable website feature as part of the original scope. The developer would then provide an estimate or maybe even a fixed price to that scope.

With Scrum, the time to be spent and its price are set, and what goes in the Sprint is negotiated.

Feel uncomfortable with this approach? That would be understandable. We have all grown up with the “predictive” approach. We all want to know how much we will pay for a set group of features at the beginning of the project, and we want to get as much done as possible.

But paradoxical as it might seem, flipping the project pricing on its head like, and buying one “Sprint” from the developer and then negotiating with him or her what will be done within that Sprint, reduces overall risk associated with a project like this and maximizes the value of the amount invested.

You might do fewer items from the Product Backlog in the Sprint but have greater certainty that the Product Backlog items which have been completed are done and ready for delivery at the end of the Sprint, and are of high value.

So what happens now if suddenly, a new idea comes up?

Using this Agile methodology, a new idea simply goes onto the Product Backlog where it gets refined and further defined, so that some initial decisions can be made as to its value in terms of return on investment.


What do you think of this approach? Have you had bad experiences working with a web professional using a predictive project management approach? Do you think this approach would save you time and money? Leave a comment or shoot me an email.

Thanks to Daniel DelPercio and Kasia Bartos DelPercio, Scrum Masters extraordinaire, for their invaluable input into this article.

Image © 2017 Daniel Delpercio. All Rights Reserved.


Twitter icon
Facebook icon
Google icon
StumbleUpon icon icon
Digg icon
LinkedIn icon
MySpace icon
Newsvine icon
Pinterest icon
Reddit icon
Technorati icon
Yahoo! icon
e-mail icon