I know Agile came about as a group of 'adaptive software development' methods, where Scrum is one of them.

Some background: We are an innovative web agency, which implies design and development. We have multiple projects running and we use JIRA to log hours and create issues. JIRA also have a Agile method where you can have your scrumboard online instead of offline.

We want to start using Scrum for our project management or at least, use elements of Scrum. I'm aware of the difficulties and the principles Scrum has in order to make a Scrum project a success. Yet, I think it's possible to run multiple projects at the same time, using some elements of Scrum with minimal resources.
We have a very small team, 3 developers (1 front-end/2 backend) and 1 Interaction Designer.

Our problem basically is that we have to manage multiple projects but we have a small team, so little capacity (velocity).
So my one million dollar question is:
How can we manage multiple projects, as we design, develop AND test our products as one single Scrum team?

As for one project it is already difficult enough. Can you design, develop and test everything in 1 or 2 week sprint? And how do you prevent the fact that other projects/clients won't be waiting for a month...

4 Answers
4

First, don't think of agile as a magic way to do more work faster. If you currently can't keep up with your customers, this probably isn't going to solve your problem overnight. If you can, then good - things will remain about the same for awhile anyway.

The only bad thing about a small team and scrum is the predictability of the sprints. One dev takes a vacation, and your velocity drops by 1/3.

The other issue you will have is that your team isn't cross functional, so potentially could be bottlenecks at the FE Dev & Designer.

It really depends on how you currently do things as to how you'd want to setup your scrum. Many companies keep design isolated from development. The designer has their queue of work, and when something is "fully designed" then it is ready to be worked on by developers.

Another key thing will be to break your work into multiple bite sized chunks of work - preferably in the form of user stories. For my small team (2 devs only), we keep things at a 13 estimate or smaller (approximately 3-5 days).

You'll want to setup swim lanes (err columns, whatever) for different phases of a story/jira ticket. One possible set would be
New - In Design - Coding - Test - Review - Done Done

For the FE engineer, if not every ticket requires FE work, you might want to tag those tickets that do require that. Or vice versa if not needing FE work is the exception to the rule.

More advice - do not create separate product backlogs. If you're not currently single threading your projects, don't start now. Put everything in one backlog and prioritize appropriately. If 10 tickets from different 3 projects need to be completed this sprint....put them all in the sprint. Keep your sprints short ....at least to start. 2 weeks. This gives you more chances to improve the process. If you do change your sprint length, don't do it often, and make sure it's for a good reason.

I don't think Scrum is the answer for you because of the team size, lack of skills, your wish to "use elements of Scrum" rather than adopt Scrum and the multiple projects.

Consider instead a more agile way of working, where cherry picking approaches may give you benefits, and perhaps look at Kanban as a way to handle your work.

Let me close by referring to your multiple projects. Context switching is harmful to teams and makes them less efficient. With just two projects on the go, teams achieve only 40% efficiency on each project, losing 20% to context switching. The loss of efficiency gets worse the more concurrent projects you undertake.

You may wish to examine the benefits of serialising your projects. Overall, you'll deliver faster.

Scrum will definitely take you nowhere with multiple parallel projects. It is best suited for teams in big companies that develop software.

I would say that Kanban with elements of Scrum might be a good choice. Use the daily standup meetings to improve team collaboration and do some sort of general planning so that everyone on the team is well aligned.

A concept in Kanban is to use horizontal columns (lanes) to represent projects. This is an easy and a very visual way to manage work items. If you are new to the concept, check this image.

This is an article I've written to help Scrum people adopt Kanban, you may find it interesting:

Deliver projects in serial, prioritize projects by profitability for the company. If you have a backlog that is too long for customers to wait, this is a good problem to have: consider putting up your prices or hiring another team.