1

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.

3
  • 3
    I'm not sure you'll find what you're looking for. Most methodologies that align with Agile Software Development focus on building teams that are focused on a single project or product. Although this kind of thing does happen, it's often seen as something to correct rather than to live with and most of the advice is how to split into smaller teams focused on particular projects/products. – Thomas Owens Mar 9 at 0:01
  • 3
    What do you want to get out of Scrum? The Sprint is meant to create focus and incremental, releasable progress toward a larger goal. If you're looking to juggle priorities and manage quick asks, it's very likely that Scrum isn't the right tool for the job. – Daniel Mar 9 at 1:00
  • If you are on LinkedIn then there is a fantastic LinkedIn Learning course available called: Agile at work: building your agile team. It is by Doug Rose. He covers the whole sprint process. From planning to scrum meetings and also breakaways (Emergency work for clients). Was very informative and will definitely cover your points :) – Mike Mar 9 at 11:41
2

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.

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

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

5
  • Currently we are doing almost exactly what you're doing and are seeing the issues around priority, forecasting, etc. This does not work very well because when you have 3000 tasks across 30 different project boards—some projects need multiple boards because of the difference in nature of design vs. development tasks—its next to impossible for a PM to visualize, let alone a team member who needs to decide what to do next. – Charles Punchatz Mar 14 at 14:01
  • If you have 3000 tasks across 30 different projects with 9 members in total, then maybe the problem isn't one of organization, but one in which you have bitten more than you can chew. – Bogdan Mar 14 at 15:30
  • Maybe I've not been clear here about what the problem is. The issue is not workload—everything gets done to meet their deadlines—nor is it disorganization—we are currently using kan-ban. The issue that I'm looking to sprints to help resolve are that work isn't necessarily done efficiently because people don't always know when a task is no longer blocked which can stress the team—kan-ban adds due dates but not a ridged schedule—there is no accountability across teams to solve that problem, as a result, it is difficult to know what our capacity for new work is months out impacting profitability. – Charles Punchatz Mar 14 at 18:37
  • If there is no accountability or no communication on blocked items, then I don't see how sprints can help. During a sprint, the team should be allowed to work with no interruptions. If something shows up that isn't show stopping, then it will have to wait for the next sprint. All clients need to accept this way of working. And because there are more clients, possibly they will have to wait even more sprints depending on overall priorities. Sprints will slow down things. And you will still have the communication and accountability problem. – Bogdan Mar 14 at 19:58
  • Thank for all the help. – Charles Punchatz Mar 15 at 3:48
0

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.

1
  • "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." — this is what I'm asking for advise on given the complicating factors specified above. – Charles Punchatz Mar 14 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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