20

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...

Improve this question
3
  • @George P. Well said.. In addition, trying to do things in parallel impacts quality which is usually ignored. Delivering 1 project at a time has more chances of meeting the project objectives of scope, schedule & quality.
    – user25500
    Aug 11, 2016 at 1:07
  • I guess it should be a comment to George's answer. Although this text contain some valuable information, it's not enough for separate answer.
    – Sergey Kudryavtsev
    Aug 12, 2016 at 11:13
  • This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
    – Barnaby Golden
    Aug 12, 2016 at 19:40

7 Answers 7

Reset to default
9

In our company we also face similar problem and I would agree to the post above that kanban is a good choice. Kanban board provides all the necesarry visibility and clarity for team, also we do stan up meetings for quick overview. During planning phase we take parts - if the planning is for first project, we invite only the members that are related. In such manner we save time. Kanban is also great for multitasking restrictions, here come the limits on columns. It is very important to have limits in multi project environment to keep people focused on single tasks until they are done.

Improve this answer
6

I think this is totally possible as you need to agree on one and the most important rule. When you plan sprint backlog, you close it and there is no place for new "unexpected" work items. Because you will be forced to deliver value on each of the ongoing projects, in any other case you will fail not one project but all together. Also, it is important that whole team is related to those projects, because if one person is only working on project A and the other team members are working on project B - you will be wasting time instead of saving.

But all in all, scrum will work if you employ the guidelines, take for example a big system which contains of different modules, but they are one big project, so as you - your projects are like modules but less related :)

One question though, maybe scrumban or even plain kanban approach would be suitable for rapid project delivery? IMHO kanban is more loose and fit for small teams than scrum, as it requires quite few practices.

Improve this answer
1
  • I'd like to second the point that the whole team should work on all projects - no isolated work. This has many advantages: One of the biggest is being able to shift work around and be more "agile" in preparing the next sprint, handling important support cases. As a nice side-effect, the quality rises when more people are involved in one story.
    – Daniel Albuschat
    Oct 19, 2015 at 7:52
5

I hope theres not too much redundancy to other answers, but I wanted to go in to some details about tools you might use in agile team with several projects.

What we do (about 6 developers, on 2 bigger and upto 4 smaller projects at the same time) is as well combining tools from different technologies.

  1. We write specifications based on user stories, which we develop together with our clients, or at least have them proof read in the end.
  2. At the end of iterations (or if working more flexible whenever something is ready) we have the client accept the work done based on these specifications.
  3. Where possible we work in Iterations, it's not a general problem to do so just because there are more projects at the same time.
  4. Retrospective, Sprint Planning etc. can be more or less comprehensive depending on project / iteration size and other circumstances (e.g. how well the client specifies).
  5. We do a daily stand-up meeting with all developers and QA.
  6. For the stand-up meeting we use one kanban-style board, where we have color coded cards across projects. It took a while and some discipline to have everyone understand that it's fine to listen to reports from other projects, but in the end it helped a lot to motivated people to help each other out with experience across projects.
  7. We mostly use story-point style estimations, to be able to get a feeling for the velocity for each project / project team.

As other answers already suggested, I believe a kanban-style board could be the most important tool in your case. You will see if tasks for instance pile up in design or testing, if tasks get stuck, and you can have a transparent way to prioritize tasks even across projects.

Improve this answer
5

Do your projects sequentially, one at a time. Period.

And how do you prevent the fact that other projects/clients won't be waiting for a month...

Think this one through: say you have three projects to do, and each one will take four weeks (with the entire team working on it). Further assume you wouldn't lose any time switching between them.

If you do these perfectly in parallel, you end up with no project completed until the very last day of the twelve-week period. That is, all your clients end up waiting almost three months.

If you alternate between projects in one-week sprints, you finish one project at ten weeks, one at eleven weeks, and one at twelve weeks. Congratulations, now only one of your clients has to wait three months—but the others only get their stuff one and two weeks before that.

If you do the projects sequentially, one client will have their project at the end of four weeks. A second will have theirs at the end of eight weeks. And a third will have theirs at the end of twelve weeks—which is going to happen no matter how you schedule them, unless you happen to have a TARDIS.

In reality, switching between projects does hurt your productivity, so your actual experience of parallelism or alternation will be worse than you'd get by simply doing them sequentially.

Improve this answer
5
  • You make a valid point, but you make the assumptions that projects are ever done. We're working with a ~6 developer team, and we have at least 2 projects at a time, which do not have date when they will be finished. They're continuously extended, so the art is in fact to split the teams capacities among the projects, and we're back to the initial question.
    – trueunlessfalse
    Mar 28, 2014 at 16:11
  • @trueunlessfalse: A "project" that is never done sounds more like a product (e.g. "the calendaring system") or a service (e.g. "fix any printer problems that arise"). My advice would be to find the smallest next chunk of actual customer value in each product/service, and work to complete those chunks sequentially. (Not necessarily alternating: if A's chunks tend to take a week and B's chunks tend to take two weeks, you might do AAB-AAB. Or if A's are more sensitive to time, or just plain more valuable.)
    – George P.
    Mar 31, 2014 at 21:12
  • George, you're right. My statement was a bit vague. It's definitely recommendable to split projects in chunks, which for themselves for sure are not going forever. However most projects are per se a product. For instance a tech based startup will never be done adding or improving features, or changing the platform based on feedback. If the client is fine having breaks in-between releases you're suggestion would work, and maybe be the best choice for a smaller team.
    – trueunlessfalse
    May 21, 2014 at 12:01
  • 2
    This is a lovely goal but is utterly impractical in our multi-client environment. We have a 10-person team with various skills, and the 3–5 projects that we're working on don't need all of the skills all of the time. Three low-level server devs, three mobile, three web front-end, and a visual designer aren't need in equal balance in equal projects. Some projects have no mobile, some are mostly mobile, etc. We certainly get more work done dividing the group because only 1/3–1/2 of the staff would be doing anything at all in each iteration. It's hard, of course, but it does work.
    – Matthew Frederick
    Jul 10, 2017 at 22:00
  • @MatthewFrederick in my answer I mention this; basically you add buffer-time for the context-switch, whether it's 1 hour or 1 day to account for team members having to re-familiarize themselves with the code/design/docs for the project. This is essentially a capacity/scheduling problem and reduced productivity is okay as long as overall all projects succeed.
    – user27307
    Sep 29, 2017 at 15:02
0

You have a small team. Do not divide the team, thinking you can get more work done. You can't.

Yes, it can be done. It is hard!

There are many things I can recommend but something that will really change the way you work is your comment: "Can we really deliver something in 2 weeks". Yes. Automate absolutely everything. Strive to be able to make multiple deployments per day. Smaller changes. Fewer lines of code. Smaller risks. Smaller tests. Fewer bugs.

When you can deliver with that speed, your conversation with your Projects changes from: "How many weeks do we need to get everything done?" to "What would you like to have tomorrow morning?"

You can start managing multiple projects because your conversation changes from: "can you wait till July?" to "We can have your most important functionality running next week, is that ok?"

Improve this answer
0

I think you need to step back and not worry about SCRUM and sprints.

You have a small team, and multiple clients with multiple projects that they want done.

Focus on one client or one project

For each client and project, it is a good idea to do a rough estimate of the earned value. If possible, as others here have said, try to reduce the number of clients or projects to the highest value client/project.

It is a bad business situation to be in, but if you are small and just starting this is how things will just have to be until you save enough money to hire additional developers and designers. (This is why agencies always look to develop products in the far future, to avoid being reliant only on particular clients and the client/project pipeline).

Add a buffer to time estimates

When you do plan each project, add a buffer for each phase that accounts for the context-switching that will happen. The context switch can happen in the form of maintenance or features (depending on your contractual obligations).

Focus on one tech stack or technology

Try to consolidate the projects so that they are using the same codebase or the same frameworks or libraries or tools. This will reduce context-switching and it's what allows a lot of web development agencies to complete projects quickly and successfully.

For example, I worked at a place that used Python/Django/PostgreSQL for all projects. If a client wanted to use some other technology, it would increase the price of the project (to account for training or hiring new developers). Most clients were content to leave the technology choice up to the agency.

At another company, we only used Drupal and Wordpress which enabled us to get clients who wanted an enterprise-level CMS site or a small business website. The tools gave us the flexibility to work on small sites or large sites.

SCRUM and project management and sprints

Your big problem with multiple projects will be context-switching. A developer and designer will have to switch their workflow. For larger tasks you will need to add a day before any "real" work gets done, for the largest tasks you may need to add 2-3 days for the team member to get back on track. For small tasks you might be able to get away with half a day or a few hours for the context-switch.

You need to set expectations of when client updates/meetings can happen and when you can respond to emergencies and requests from clients. This will allow you to group of chunks of time in order to reduce context-switching.

  • 1 client, 1 project: the ideal, your team is focused on getting one project done, there is no context-switching
  • 1 client, 2 projects: almost ideal, your team can deliver updates and focus on 1 client's needs
  • 2 clients, 2 projects: going to run into trouble with timing and schedules at some point, your team will need to focus on one client and then switch focus to another. You will run into dependencies from developers to designers to clients about which days are good for meetings and when certain tasks have to be finished. You may want to hire temporary help. A good idea is to schedule 1 client/project for the first half of the week and the other client/project for the other half of the week or to alternate between weeks (1 project per week).
  • 2+ clients, 2+ projects: you need to hire more people and split them into teams that focus on 1-2 projects or clients at most.
Improve this answer
-1

I have practiced Scrum for a couple of years now. I came here because I am now working with a small team (4 developers, 1 QA) responsible for a portfolio of enterprise projects, new development, enhancements and support. I think the obvious answer is from George P.; work on one project at a time, get it to completion and move on to the next. You will actually get the projects done faster and better. The throughput from engagement to completion for each customer will be shorter. I have tried running concurrent projects with Scrum and the overhead of the Scrum rituals and distraction of switching projects is wasteful. Try it. Once you are good at it you will astound your customers with your speed.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.