Can the Scrum Framework be effectively used to develop and deliver on a multitude of projects, with a larger team of 15+ people? In other words: can the adoption of Scrum alleviate some of the typical planning, collaboration and delivery issues encountered with organizations taking on complex challenges from multiple clients?

To answer this question, I will go back to 2003 and describe how we were working at the time at an “internet agency”, how things have changed for me since Scrum became mainstream for working on single products with a small team and how I believe Scrum can be effectively applied beyond the single product/small team context.

Life in 2003: the Planning Spreadsheet

It was 2003 and I was working as a Lead Software Developer at an internet agency called Zappwerk. We developed websites for clients, with a team of about 10 Software Developers, 4 Designers, 4 Project Managers, 2 Sales people, including the Boss/Owner, and an Office Manager. A very typical set-up for an internet agency at the time I would say and we were quite successful at delivering advanced and creative solutions to our clients.

However, planning was always a big challenge. The sales people wrote proposals, promising a jaw-dropping solution to a client, including estimated hours, price and delivery date. Whenever a proposal was accepted The Project Managers had to transform what was promised in the proposal into a detailed planning, specifying which role (Designer, Front-end Developer and Back-end Developer) would be needed for how long at which moment in the coming weeks and months.

At the time we were doing ‘waterfall’ (like everybody else), no Scrum or other Agile way of working, so design was neatly planned before any development would start, with a hand-over of a “Big Upfront Design” in the shape of a set of hi-fi screen designs or an HTML mock-up.

The Project Manager would then sit with the Office Manager, putting the planning into a big “Planning Spreadsheet”, with for every week of the year all people in the team on 1 axis and all projects on another axis, with number of hours in each cell. In this way it became transparent who would work for how many hours in which week on which project.

Everyday planning challenges

When putting a new project into this Planning Spreadsheet, the Project Manager and Office Manager would of course run into issues, like that the promised delivery date did not allow for sufficient hours by the necessary roles. So the Project Manager would need to align (i.e negotiate) with other Project Managers and/or talk to the client about a later delivery date, or deliver the project in parts.

Also, once a Software Developer was working on a project, it would turn out that more hours were needed than estimated by the Sales people, so they would inform the Project Manager, who would then need to talk to the Office Manager, other Project Managers and/or client about a change of plans, possibly also negotiating more budget, or delivering less than promised. And the Office Manager then needed to update the Planning Spreadsheet.

Furthermore, people would be sick or decide to take a vacation, so the Office Manager had to continuously update the Planning Spreadsheet, informing the Project Manager of any changes, who then would need to align with other Project Managers, client and/or Office Manager to resolve their issues.

I estimate that the Office Manager spent about 50% of their time on managing the Planning Spreadsheet and the Project Managers each 25% of their time, including all conversations and e-mails they needed to have and send with/to each other, the Designers and Developers and their clients.

Nobody really liked this Planning Spreadsheet and we knew it needed a lot of time spent in alignment, negotiation and communication between ourselves and clients, but we did not have a better alternative. And the Spreadsheet did give transparency and clarity, it gave us something to hold on to, a source of truth as to what each one was working on.

For example, at the start of every week a Designer and Developer only needed to open the Spreadsheet and see how many hours they could spend on which project that week. For most project hours they had a good hunch of what to work on, so went ahead. For some project hours they would talk to the Project Manager to ask what was expected of them. And whenever getting a task done or delivering a milestone for a project would (turn out to) require significant more time than planned, it was not their problem, but the problem of the Spreadsheet, and the job of the Project Managers to solve it.

The “free Friday” happiness

A few times per year the Boss gave us the Friday “free” to work on whatever project we wanted to. We always had plenty of cool and creative ideas and working our behinds off on one of them gave us loads of energy and stuff to talk about for weeks. We never made a plan for these Fridays. We just agreed on an idea to work on for that day and a practical goal we wanted to achieve at the end of it. We would conclude with a demo and then went out to have a dinner together.

On these Fridays we felt super productive and it was such great fun all working together on the same goal. We wondered: why can we not always work like this? What if we would use this way of working to deliver a new website to a client in a matter of days instead of weeks or even months? But we did not know how to practically make that happen, so when coming back to work on Monday it was time to open up that Planning Spreadsheet again…

Life since 2015: Scrum

Fast forward to 2015, I join an in-house Scrum Team at the Ministry of Justice & Security where we develop two software solutions. I am a Certified Professional Scrum Master and have tons of experience in Software Development, but still need to learn the ropes as Scrum Master. My colleague and good friend Robert de Wolff who set up the team as Scrum Master brings me up-to-speed and in a matter of months I can take over. I am amazed how effective and smooth the team operates, successfully delivering to our stakeholders, while maintaining a super-pleasant co-responsible and fun working culture. We become informally known as the “showcase” for how to successfully develop software using Scrum.

For me it is clear: Scrum is the way to develop software in teams, I never want to go back to the old days. Since 2015 I have supported many clients in adopting and optimizing Scrum and working Agile, most notably the team at 510 of The Netherlands Red Cross.

However, these have always been relatively small teams of about 5 to 9 people, focusing on 1 product only. Although at the Red Cross we are also operationally supporting clients besides our product development and we have recently taken on the development of a second product, I cannot help but wonder: would we have been more effective and happy at Zappwerk if we had used the Scrum Framework to manage our work, instead of the Planning Spreadsheet and its related working procedures?

Good practices to effectively use Scrum for multiple projects with a large team

Can Scrum be effectively used to develop and deliver a plethora of large and small projects for various clients, with a cross-functional team of 15+ people?

I have a hunch that Scrum can extend to that, resulting in many upsides that single-product smaller teams also benefit from. And I would love to take it to the test (where is that DeLorean?). In the mean-time, I asked some fellow-Agilists for their experience. I got an extensive response from Arnaud Viguié, Leader of the Agile Community of Excellence for Jaguar Land Rover, and he conformed my hunch, along with some good practices of making it work. Below is a list of 9 good-practices, based on the insights that Arnaud provided and my personal views.

Good practices to effectively use Scrum to deliver on multiple projects with a large team:

1. Put the work for all clients into items in a single Backlog.
2. Tag each item with the project/client, to keep track of spent effort/points.
3. If feasible, let team members write on actual time per project (at 510 everyone writes their time at the end of the day, we round off to the hour per project).
4. For each project work with stakeholders to understand the need, come to an agreement of the expected solution, estimate the time/effort needed and agree on a delivery date. If the client needs a fixed time and cost, then spending substantially more time refining and estimating all items for that client is needed. This can result in a Waterfall-type of contract. Better to get an Agile-based contract.
5. Agreement on effort and timeline for each project results in a prioritized Backlog for the team to work on.
6. In practice steps 4 and 5 will not be a 1-time thing, but continuous planning, re-assessment, alignment, and re-prioritizing is needed, as new clients come in and circumstances, priorities and insights change.
7. Let the team work on as few projects as possible per Sprint, preferable just one, better even for multiple Sprints in a row. This reduces the cost of context switching.
8. Depending on the context, split large teams into smaller cross-functional teams of 5 people, with each team their own Sprint Backlog and one joint or two Product(s) Backlog. Research shows that increasing deviation from this number decreases overall efficiency.
9. If splitting up is not possible because of many people having highly-specialized individual skills, start developing cross functionality in the team, towards them being “T-shaped” or “π-shaped” (pronounced “Pi-shaped”).

Why would Scrum work better?

Now, let’s look at the underlying principles of how we collaborated at Zappwerk and contrast them with contemporary Scrum and related “good practices”:

1. Sales people (or Project Managers) estimate time needed to get tasks done for delivering a project vs. let people who actually do the work estimate.
2. Estimate specific tasks for specific roles in absolute time (hours) vs. let the team estimate relative effort for delivering across functions/roles, preferably based on historic data.
3. Assign specific people in specific roles to specific time-bound tasks in sequence for weeks or even months ahead vs. let the team jointly pick up and take responsibility on delivering an acceptable result in a time-box (Sprint).
4. Have people individually assigned to and work on multiple projects (sometimes 5 or more) in a week, for each project taking at least several months to complete, vs. let the team focus on 1 project, or at least as few projects as possible in a Sprint, delivering a functional result at the end of the Sprint.
5. Have people work in varying “teams” working with different people per project who have their own role/task-based responsibilities, with their own “assigned hours” vs. having a stable cross-functional team where people are enabled to collaborate and share responsibility to deliver.
6. Have a very detailed Planning Spreadsheet indicating which person works on which project for what amount of hours per week that needs constant updating, aligning and communication with many inside and outside stakeholders vs. a prioritized Backlog with delivery dates per project that also needs constant updating, aligning and communication (although since far less detailed, it would require less time to do this).

All in all, I believe that Scrum provides sufficient process and structure to effectively and efficiently deliver multiple projects to multiple clients and manage their expectations, while also giving the team that “free Friday feeling” of enabling intensive collaboration, autonomy, work happiness and shared responsibility for delivering excellent results.

Shall we take it to the test?

– Diderik

Photo by Husna Miskandar on Unsplash