Sprint Planning for Agencies

Question

I'm looking for some help finding resources on sprint planning specifically for agencies, namely a web design and development firm focusing primarily on web apps. So a typical project would be a client signing on for a website, let's say. We go through research, UX/UI, design, development, deployment, and—in some instances—ongoing maintenance. I should also clarify that the agency is relatively small with 9 members in total.

Resources seem plentiful for in-house software teams, but not so much for agencies. Specifically, planning sprints for cross-functional teams working on multiple projects at a time for several clients.

The problems/pain points I'm looking to solve through this approach are:

1. Filling in "down time" on a project—e.g. while waiting on design approval on project A, the designer should be working on X, Y, and Z on project B—in such away that blockers are accounted for across the team. Not just filling in the time with random tasks from the backlog.
2. Better cross-team communication on project statuses, when and how blockers are resolved, when work needs to move from one team to the next. People are not accountable to anyone else because they don't really understand how their work on project A might affect how someone else is able to do their work on that same project or even how it may impact a different project.
3. Better understand our capacity for new work.

Right now things are basically set up as an endless list of tasks across several kan-ban boards. Tasks get done when the milestone is due. This is all well and good, but it means project can sit and wait until the next milestone is due or that another person is not aware that their work is no longer blocked.

Any help would be tremendously appreciated.

Also, would be looking for anything detailing accounting for "emergencies" or "rush jobs" from clients interfering with said sprint.

👆This is less important to me, as scopes are pretty solidly set in the contracts we sign with our clients. However occasionally a server will go down or a bug in production will pop up, these are pretty unavoidable across any software team, I'd imagine.

Answer 1

As already mentioned in the comments, the sprint helps to keep teams focused on working on one product without interruption. If there are occasional emergencies, then keeping a buffer in the sprint could help with that.

However, you mention you have cross-functional teams working on multiple projects at a time for several clients. This is a pain to plan into a sprint because each projects has its own (changing) priorities. And once you plan a sprint (which should be an uninterrupted slice of working time) then "emergencies" or "rush jobs" from clients show up, interfering with said sprint. This basically throws a wrench into all the planning you did. If you have too many projects at a time, with many changes, then the planning can easily turn into complete waste, as you plan the sprint one day, and come in the next day and realize you need to do something else because some project just had an emergency or is in need of a "rush job".

In this kind of setup, I would personally give up on sprints and go with Kanban, then focus on prioritization of work instead of planning the work as in a sprint planning meeting (with estimates, for ex). When urgent work shows up, you just look at what is in progress and see if it should displace something from there, or go into your backlog of work and see how it fits in the order of other work you have.

You can keep useful practices that should be done regularly, like reviews or retrospectives (you don't need a sprint for these, they are just a recurring meeting) and work just on what's important next, and next, and next, instead of planning one sprint where you try to figure out what's important for two whole weeks (or whatever time-box you run your sprints at).

Now, for the three points you are interested in solving:

1. Filling in "down time" on a project—e.g. while waiting on design approval on project A, the designer should be working on X, Y, and Z on project B—in such away that blockers are accounted for across the team. Not just filling in the time with random tasks from the backlog.

This is most likely something you need to solve by backlog refining and prioritization, to make sure there is enough work for everyone at any given time. A designer for example should have some work lined up that they can pull from when thew finish some task or await feedback for another. Your Kanban board should reflect the tickets that are blocked or awaiting. You should have some sort of Product Owner, or someone with a big picture over all the projects to be able to line up this work.

2. Better cross-team communication on project statuses, when and how blockers are resolved, when work needs to move from one team to the next. People are not accountable to anyone else because they don't really understand how their work on project A might affect how someone else is able to do their work on that same project or even how it may impact a different project.

Visualizing work is essential here. Daily meetings are also important. People need to see their work and how their work relates to others. You can mark Kanban cards with some information to show the dependencies. You can have people place cards on each others boards to remind them to do something. If you use online tools you can monitor someone else's tasks and get notified by email or something is statuses get updated. People need to keep the big picture in mind, not just focus on their own work (visualization and daily helps with that).

3. Better understand our capacity for new work.

Good WIP limits and measurements like lead time/cycle time or throughput can help here. These can help you in similar ways as velocity can help when doing sprints. You might also have to differentiate between classes of service or different types of projects (e.g. design only, UX only, end-to-end solutions, etc) and pay attention to bottlenecks.

It will take some time to figure things out because of the nature of the work. Ideally, people should work on one project. Two projects are manageable. But from 3 up, you will need a lot of managing overhead to keep things from falling apart. Start looking at what you are doing now, visualize and draw out the process you are using, then slowly change, add, or remove things from it to improve.

Answer 2

Will you guys able to move into Scrum Framework delivery? Because the tasks are put into Kanban board. Its hard to figure out which are the pending and active tasks for the project.

Its better to create a sprint for 2 weeks and add tasks from the backlogs to your current sprint. Based on the updates you receive, you can change the status and ask the folks to look into and act accordingly.

Secondly I would recommend to have daily standups with the team, this way the communication gap can be fixed.

Hope this helps you aswell.