Introduction to SCRUM for Filmmakers
SCRUM is a method of agile workflow designed to empower team members to complete tasks by making decisions at the individual level. It offers a system of breaking complex tasks down into simpler tasks that, once completed, result in the complex task to be accomplished. It is called ‘SCRUM’ because the process was inspired by the way rugby teams work together during games.
Though SCRUM is primarily used by software development teams, its process can be applied to any kind of work. Let me give you an example of how SCRUM would work for a production company creating videos for a YouTube channel:
A pre-production team needs to plan to shoot an entire season worth of videos for scheduled release during the next quarter. Armed with the scripts for each video, the team divides up all the necessary tasks for production to begin – location scouting, hiring of crew, casting of talent, sourcing of necessary things like catering, wardrobe, set construction, props, etc. – into smaller tasks that lead to each necessary item to be completed.
Next, the production team needs to shoot the videos using the plan created by the pre-production team. Each individual task necessary for the recording of the audio-visual content is broken down into smaller pieces – such as the order of scenes to be shot and resolution of any critical problems encountered by the production team.
Once the video is on tape and delivered to the post-production team, all of the necessary tasks for assembly are listed out – ranging from sound design, music placement, color correction, visual effects and editing – and are divided into the individual steps needed to complete each aspect of post-production for completion by the post-production team.
Finally the videos are handed off to the marketing team responsible for getting the videos seen by audiences – scheduling the videos for release, building hype around each release through press relations and engaging audiences through social media – and these very large tasks must be broken into their specific points for completion.
SCRUM is a perfect system for adapting to the film industry because each aspect of creating content is methodological; the steps necessary to create a polished product are virtually the same each time, so a manufacturing process can be created around the specific steps necessary to produce the videos.
Why SCRUM is Great and You Should Adopt It
Generally in any production process when teams have a backlog of work that never gets done it is due to the following reasons:
- No collective process for the team to process producer or director requests.
- Team not sure which work is important, urgent or ranked higher than other tasks.
- No collective processes to handle the volume of new work that flows in, as well as to finish stalled project work.
SCRUM solves these problems by developing a system to assign priority to work to be done, and then breaks work down into individual tasks that mark the completion of that work.
Step 1. Implementing SCRUM in your team
It is vital that your production team is aware of their responsibilities and dedicated to the goal that SCRUM implementation is supposed to assist with reaching.
Within a SCRUM team there are certain roles;
Team:
The scrum team is the most important segment in its completion. The team typically comprises of five to nine members and there are no typical designations involved. Each member is entrusted with doing a particular task but that does not stop other members from supporting each other. On the whole, the entire team is held responsible for a particular task.
Product Owner:
The product owner is the key stakeholder in the development of product (remember, your film / TV show *is* a product). In software development he normally represents users and customer segments related to the project. This role in film development is likely held by the producer or director. Make sure that you find a willing Product owner. This means finding one person who is required to prioritize work on the product itself and who can act as a good communicator. This individual must be dedicated to the success of product and thus can give a substantial amount of time to the product development.
Finding a product owner is key; and if that itself cannot be executed then it’s just no use implementing SCRUM in your business. Your product owner should like be you, someone who is capable of running your business, whether it is your film production company or your YouTube channel.
SCRUM Master:
SCRUM master is responsible for making sure that team is working properly. Though he is not the team leader, he is entitled with removing certain external distractions, if there are any, to avoid the retardation of the whole process.
Once the team is organized, designate yourself as SCRUM Master making you responsible for the SCRUM Team. You must teach and coach them every step of the way in the process.
The next step in implementing SCRUM protocol is to create the Product Backlog. This simply defined is a list of steps or instructions for the product itself. Anyone can add anything to the product list, however a product owner is the one who is solely prioritizing the backlog itself. The product backlog can be anything associated with your channel’s success; faults, issues, possible reasons for failure, etc.
It is important to prioritize the backlog and make it the most important thing to create. It is essential to make sure that the important things and things that can actually be done in reference to the product itself should be on the list and unimportant or ineffectual things should be written of the list assuring the priority and importance of the actual Product Backlog.
Prioritization of work to be done is a business problem that is being tackled every day at every level of hierarchy in any business, and a film production company is no exception. Things on top of your Product Backlog can easily be done in the foreseeable future and thus they are more likely to be resolved. Things that are at the end of the list usually don’t get done and thus it is not recommended to put things that will never be done on the list. The Product Backlog should contain a list of items that are well defined, and deliverable. They should not overlap other issues in the business but should be contained within themselves.
Thus a SCRUM Team is formed composed of a SCRUM Master, a Product Owner and a Product Backlog allowing you to align your team with the goals of the production company; to create an entertainment product that is owned in all its right by the company for the viewer. This is achieved because team work is assigned and prioritized on a constant basis and product development is ensured.
The Product Manager is entirely responsible for not only overseeing the list but ensuring that the things on it are carried out. This is the first step and until this step is achieved implementing SCRUM method is useless.
Step 2. Setup product backlog
Your next step is estimating the Product Backlog. Your initial estimates help you understand the size of Product Backlog items so that you can make informed decisions about the product and its relevant priorities. This lets the Product owner gain an idea of how vast the team needs to be and what kinds of skill-sets are necessary.
It is important to estimate your Product Backlog not in random units of time, but in Points. Using a point system to prioritize the features of your product is a more viable method of estimating Product Backlog.
I suggest the use of the Fibonacci numbers to create the sequence for your points system, as they are a standard method of sequencing. 1, 2,3,5,8,13,21,34 and so on 987…
For purposes of simplicity you should use these numbers for size measurement ( how hard the task is) with most tasks taking place within the range of 1-21; The role of importance here is relativity and labeling a previous problem with a number allows it to be renamed with a number once more, creating a reference. The idea then is to measure the size of the problem with an appropriate number:
1 can be used to signify a problem which is relatively small;
The most difficult tasks can be issued the number 21, signifying that it is much bigger and more important than what was designated 1.
After you have marked numbers to your critical tasks that must be done to create the product, you can organize them in the product backlog from most to least important using the Fibonacci numbers.
The next step is sizing the backlog as a team. Allow all the members to estimate using the Fibonacci numbers for product prioritization than compare their list with each other’s and make changes within the list as a team, re-assigning numbers based on what the group votes is most appropriate for each individual task. This will allow for more discussion about each task, and will create a healthier approach to tackling problems as all members of the team feel they have participated in determining what tasks take precedence over others.
After the above step has occurred the Product Owner should take over and look at the proposed list. The Product Owner must approve the priorities list and clearly be able to see the importance of each individual task, as this will allow the Product Owner to prioritize in more efficient way than if the list was created in a vacuum without the team’s assistance. The Product Owner should always make the decision in discussion with his team thus allowing a more reasonable system of SCRUM delivery.
You should only attempt SCRUM when you have mastered the art of prioritizing and can adapt to its constant change, as SCRUM is an adaptive process. SCRUM is a team based effort and this step is important for establishing the exact needs related to the product.
Step 3. The Sprint Planning Workshop
At this point the first two steps should be completed and a Fibonacci points based Product Backlog should exist. It is now time to plan the sprint in a workshop meeting. This meeting should be attended by the whole team, especially the SCRUM team and the Product Owner.
The first thing to decide is the time duration of the sprint. SCRUM sprints are usually about thirty days, but this number should be adjusted by different teams depending on their own requirements. Usually it ranges from one week to one month but a month often allows for the smoothest implementation. A week is the bare minimum amount of time that should be assigned for a sprint, as the end of a sprint means that practically every task assigned to be completed during the sprint run is complete. A month (thirty days) is usually the longest amount of time a sprint run time should be allowed, as it is not the entire Product Backlog that is to be completed, but rather a small number of critical tasks relative to each other – those tasks which are necessary to be completed together in order to create the product (your film or show) successfully.
It is important to be consistent with the duration of your Sprints, as this allows the entire SCRUM team to get into a familiar rhythm with clear expectations for when the tasks assigned during the sprint need to be completed. This makes the process of sprint runs easier and assigns the Sprint Planning Workshop as a regular step in the workflow.
The duration of each sprint and the goals selected to be accomplished during them should be in sync with each other. Both the Product Owner and the SCRUM team should have a pre-existing idea of how they will go about planning, executing and completing the items chosen from the Product Backlog to ensure they can be successfully completed within the allocated sprint time.
The next step is to select the Target Backlog for the Sprint Planning Workshop. Every sprint run should be based around accomplishing a specific goal that inspires a new goal for the next sprint, and this decision should be selected as a team. This usually means picking a related section or items from the Product Backlog that the team believes can be achieved in the pre-decided sprint duration and are necessary to be completed in order to tackle other items.
Once the items from the Product Backlog list have been selected, the Product owner presents each task and explains its requirements for completion, and this allows the whole team to discuss each item in a detailed way. This allows for an open session for the team to ask questions which will lead to the best possible solutions for the sprint run to be successful. The team should write down the individual tasks they will be responsible for completing during the sprint, and as the discussion proceeds the team members who are responsible for specific tasks will become more clear. Team members can volunteer to perform certain items, or they can be assigned by the Product Owner based on the skill-sets of each individual team member. The Product Owner should keep notes for future reference on which items are assigned to individual members, so a review of each team members’ work ability can be assessed at the end of each sprint.
Remember, the SCRUM Team and the Product Owner must work hand in hand to establish the Sprint Time and ensure that each item from the Product backlog list is successfully checked off.
Step 4. Sprint Planning Breakdown
Once you’ve completed the first part of the Sprint Planning workshop the second part is dedicated to breaking down the tasks in the Product Backlog to estimate the time allotted to complete each item.
Your first step is to set the Sprint Budget; this is not the monetary budget for the project, but rather the time budget for the sprint; the number of hours available for each team member to work during the Sprint. Remember that if you have part time and full time employees they will be working different hours. You should also make deductions for any time you know the team won’t be able to devote to working, such as holidays, meetings, conventions, etc.
Break the requirements of the Product Backlogs items into even smaller tasks that are easier to achieve. These can be divided into Design, Development, Location Scouting, Vendors, etc. etc. Every task in the Sprint should be measured and estimated in hours it will take to complete the task. It is essential to keep the tasks small and well defined.
Generally you should keep tasks small enough that they can be completed within a single day’s time. If a task will take longer than a day to achieve, break it down into a series of smaller action items. This method is beneficial in making the requirements easier to understand and will also improve the accuracy of your estimations, which will make it much easier to successfully complete the Sprint.
Add up every task estimate for the particular sprint. If the number of tasks you allot for the sprint cause you to exceed the allotted time budget for the Sprint backlog, you should remove any lesser priority tasks, keeping only the highest priority ones, until you are now below the budget threshold for the week. You may add these extra tasks to the Stretch Task backlog.
When teams are new to SCRUM they are unfamiliar with the process and take time to become comfortable operating in this manner. Thus it is essential to clarify things every step of the way, to allow the team to raise questions and ensure that every person is aware of their duties.
It is important to note that the Product Owner should not expect the Stretch Tasks to be achieved during the Sprint; no one in the team should be beaten up over this because the Stretch Tasks are only there for motivational purposes. If somehow the Stretch Tasks are achieved, this should be distinguished and rejoiced as the team was able to work beyond expectations.
Step 5. Create the collaborative workspace
The first thing to do is to whiteboard all the walls of your office; you can never have enough.
You’ll need your white boards for posting task boards, charts, procedural notes, and even inspirational pictures that will help keep your team motivated.
The whiteboard area is a collaboration hub and be the center of all team meetings and discussions. This is the place where your team will meet every day and get anything they want at a simple look out at the whiteboards themselves.
One of the most wonderful things that were ever created was post-its. These tiny sticky pieces of paper are the key to organizing all your information on the whiteboards. Once you’re done labeling the columns, and placing all your ideas on it, then the post-its will just be small reminders of the task in progress, who is currently handling what, and which tasks are being conducted one step at a time. The names of team members on the post-its should be moved to the next step according to which team member is progressing to what stage in the SCRUM initiative. Each team member should have their own unique colored sticky note to put on the board so it is clear who is in charge of which tasks.
This post it mechanism allows a clear visibility of which team member is in which stage of task completion. This allows for better time management for the team, product owner and other folks interested in seeing the current status of work to be done.
Your white board should be divided into six columns:
- To Do
- In progress
- Done
- Issues
- Sprint Goal
- Unplanned Items
By moving sticky notes through the columns the team is able to track the progress made each day toward completing the sprint run, as well as keep tracking of new problems (issues) that occur during the sprint that need addressing.
An example of a sprint board.
Using software or interactive internet based methods of communication such as Trello to manage your task board is definitely efficient if people don’t all live in the same location, but if your team is based in the same office I highly recommend the white board method as it makes things much easier.
Acting as a visual calendar the white board allows the team to work together even if they aren’t a natural at collaborating with others. Working together to achieve the goals for each week is the only way the SCRUM initiative can be implemented successfully so your board is crucial.
Step 6. Starting the Sprint
The sixth step in the SCRUM initiative is the actual sprint itself.
The specific manner in which tasks are accomplished is left up to your team mates, using their pre-existing knowledge and skills to tackle the items on the board. Thus the team sprints to complete the Sprint Goal by performing the tasks they were assigned in the previous stages. SCRUM does not dictate how the tasks should be endeavored, it only spells out which tasks should be completed.
Agile teams in SCRUM should be empowered to make their own decision instead of the manager making all the decisions which takes too much responsibility away from the team itself. If the manager or Product Owner disrupts the autonomy of the team to process tasks as decided in the prior stages, this will hurt their ability to successfully complete the sprint, which causes the team to lose morale and their dedication to the project. The manager should only be there for supervision; to give support and assistance where required, but not to micro-manage the specific way every task is completed.
The Sprint Duration is a fixed time frame, which means that an allotted amount of time is only allowed for tasks and there should be no changes in this task assignment to time ratio. Tasks can be added to the Stretch Goals if there is time left, but no extra time or reductive changes in the number of tasks should be done. If there is a chance of finishing late, then the tasks must be reduced in order to complete the deadline which any outstanding tasks moved into the next sprint run.
Each team member should focus on one task at a time before moving on to the next. It is always better to have one hundred percent of something to deliver than ninety of everything, where there is always going to be an unfinished look to the final product.
Product Owners should be aware of the impact that changing the tasks will have, and realize that any new work that was not previously discussed in the Sprint planning stage could disrupt the Sprint and should be carefully considered.
Aborting a Sprint is a serious decision and should only be implemented in rare and unmanageable circumstances. If the Sprint goal is no longer achievable or relevant to the task, or deemed to provide no results then it is time to abort the Sprint and refocus the goal that must be achieved. Aborting a Sprint midway means abandoning all the tasks in progress and reverting back to the Sprint Planning part to re-develop task priorities.
Step 7. Standing Meetings
During the sprint it is important to hold meetings in the collaborative workspace to update the boards. The product owner must be present for all of these stand up meetings. This is called a stand up meeting. During the stand up, the team will literally stand around the Sprint whiteboard in a half-circle for approximately fifteen minutes to discuss the status of the sprint.
You should perform a daily stand up meeting every morning where each team member answers three questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
Each individual team member is responsible for answering these questions and should not be interrupted during their report. It’s okay to ask some questions to clarify the information that is relayed but any major issues should be discussed in more detail after the stand up meeting has ended. When the major issues are discussed only those directly involved in the problem should be in the discussion; everyone else on the team should get back to their work.
During the stand up meeting the SCRUM Master is responsible for supervising, and they should ensure that its focus does not deviate from the original task. Any new problems that are pointed out during the meeting can be written down onto one of the whiteboards to be dealt with later.
The SCRUM Master does not personally have to solve all the issues; they can be assigned to other team members to follow up on. That said it is the SCRUM Master who is accountable for ensuring that any problems identified during a stand up meeting are addressed and resolved quickly and efficiently.
Step 8. Sprint Review
As the Sprint ends it is important to hold a Sprint Review meeting. This is where the whole team, including the business stakeholders, executives, and task members will sit down to perform a review of what was accomplished at the end of the Sprint.
It is important to let the team members present the tasks they were assigned, as they will be best able to explain what happened. This also allows team members to show their contribution to the tasks. This meeting also allows the stakeholders an opportunity to see what has been done and allow them to provide feedback where it can still be included and adjusted to the final product. It also helps the team members to stay centered to the deadline of the Sprint and have something to show at the final demonstration.
The spring review is also a self assessment, to discuss what went well in the completion of the tasks, and how things that didn’t go as well could have gone better. This is important because it allows learning from the mistakes that were made and improving on things so things will flow smoother in the next Sprint.
The Sprint is a continuous learning process. People usually don’t remember the faults and errors in long projects, and thus a Sprint review allows the team to keep looking back at errors in the process and improve on them as they proceed.
In SCRUM the product being developed is broken down into sizeable and understandable chunks, and this continuous process allows reflection, feedback on the project and error adjustment as it goes.
Once the team is armed with the idea of how SCRUM Implementation and Sprints work they can implement it into their work environment as a regular way of working. The process is repeatable, which allows for company strategy to be more proficient.
For new teams attempting to implement the SCRUM method it takes at least four to five sprint runs before the team get the routine down pat. This is one reason why it is helpful to start learning with small projects to ensure the team is working together correctly before charging ahead to complete larger projects.
Conclusion
SCRUM can take some getting used to with your team, but this is to be expected as the process will be foreign to your team until they have experienced it first-hand. I encourage you to stick with it, as it will prove to be a very effective system for managing the fast-moving and multi-headed tasks that are involved in modern day film production.
Have any questions or comments? Feel free to leave them in the field below.
*Also consider purchasing my book, The Lean Channel: YouTube for Entrepreneurs if you’d like more information about how to build a business by running a YouTube channel.
