Before you start reading this post, I want to make you aware that it is part of a series on Sprint Planning for Agile Marketing teams. Here are some of the post in this series:
- Put On Your Game Face - The Basics of Sprint Planning
- Some Assembly Required - The Tools
- This Post - Content Developers, Cross-Functional Teams, and Commitment
- Breaking Down The Tasks
- Go Run! Starting a Sprint
- How do I End My Sprints Well?
- What Do I Do When Things Go Wrong?!
We are almost to the halfway mark! In the first part of this series, I gave you an overview of the Sprint model of Agile planning for marketers. Next I addressed the tools you can use to plan and execute your Sprints and some examples of how to be paper-based or digital.
This brings us to part 3 of 7 in our Sprint Planning Series as we talk about the content delivery team, what it means to lower the bus factor, and the importance of commitment to the Sprint on your team.
The focus of this section is to talk about the team. We are building content assets but our team is also made up of assets to our organization. Each member brings their strengths and weaknesses to the table and those have to mesh well with the others that are already there. We will have alphas at our table who want to be heard, doers who want to be told what to do, visionaries that can predict what is to come and early adopters who want to move us places.
The other thing our team members have is a limited skillset of what they are trained to do. Some folks are amazing writers but have never touched a graphics editor in their careers. Others are amazing storytellers with video, but struggle when it comes to the written word. The list goes on and on.
We are now Content Developers working in an environment with three different types of skills: the ones required by everyone, those we are learning, and those we are teaching. Each team member should possess a few in each category and I suggest that they are part of a documented Content Strategy. When something changes on our team, then our ability to execute the strategy can be affected positively or the negatively.
Measuring Your Bus Factor
One important measurement we use in agile is called the Bus Factor. While it is probably a very crude concept, it has stood the test of time so we continue to use it until someone comes up with something different.
The Bus Factor is a number that represents your ability to execute a particular type of task or a general skillset on the team. The question is asked, “For XYZ, how many buses will it take if our team crosses the road at the wrong time?” In other words, if there is a major event, such as sickness, injury, promotion, leaving a job, maternity leave, or even death, how effected would we be in delivering on these Content Items?
The lower the number then the higher the risk we have on not being able to deliver overtime. Content Marketing is all about consistent delivery so if our video guy leaves, what will we do?
So before you begin your Sprints, your ScrumMaster and your team need to know the risk we have with the makeup of our team and then make plans to address those areas of high risk.
These plans could include working on those tasks as soon as we can in the Sprint to make sure there is time for the other tasks, making changes if needed, or even pairing people together for cross-functional education. More to come on these.
A Sprint in the Life
So let’s take a look at a couple of examples from the same team over time. This may very well describe your team as you get started as it has many teams that I have helped over the years.
In the first Sprint, you take an audit of your team’s skillset and find you have a Bus Factor of one for the video production in your resources. He is a very reliable team member, even has a background in television that helps him stay organized and get the shots we need right away. So your team decides they want to make a splash with Agile Marketing and with 20 points worth of work available in the Sprint, you pull in two 8-day Content Items that require video and one 3-day blog post. Heck, you even have a day to spare.
To continue Sprint Planning, your team breaks down the tasks associated with the three Content Items. The blog post is easy. You need about 1200 words of copy, a few graphics, a headline, review, and some social media content. For each of the two videos, you have tasks for a script, story boards, three interviews, some extra B-reel footage, and the production.
Over the Sprint, the first part is getting the storyboards and scripts ready and creating the blog post. About halfway through, you schedule the interviews and send your video asset out to get B-reel. Towards the end of the Sprint you notice a few interviews still in the Open Item column but the video asset is completely booked with his current load of finishing up the interviews for video one and the final production. On the last day of the Sprint you decide to cut one of the interviews and borrow some of the footage from the first video and go straight to production. Your team stays late watching the video asset do his thing and learns a lot about the process.
During the retrospective, we are all immediately aware of the lack of resource planning we did in the Sprint. We decide it is only possible for us to take on one video per Sprint and that everyone on the team needs to spend some time becoming familiar with the parts and pieces that go into the production.
When the team goes into the next Sprint Planning session, we create an item on the Content Backlog that is not a Content Item but is for time allocated to learning. You label the card Education for Video Production and you estimate it at 8 to allow ample time for the key assets we need for our second line of defense and for everyone to learn more about the different parts that go into video production. You only pull in two other Content Items in the Sprint, a video so you can produce something for the first item and another blog post.
Now that you have the items selected, you task out the blog post and video Content Items the same as before. On the learning item, you have tasks allocated for pairing up with the video assets to watch and record your findings, some time for self-education, a day for the video assets to create a lunch session for the team, and some research tasks for other members of the team.
Before you start the Sprint, the ScrumMaster ordered a few copies of Adobe Creative Cloud for those backup members and had them install the tools on their machines. They also went to the local library and grabbed a few good books on video, as well as went on Amazon and bought a couple copies of the best-selling Premiere Pro book. The team is also encouraged to use Slack to communicate any good articles or videos people find on the topic and a prize is announced for the person who contributes the most helpful articles in their off-time based on the Slack thumbs-up poll.
When the Sprint begins, the first card the video asset grabs is the lunch session so the ScrumMaster plans to get lunch for the team on the following day. The rest of the team grabs research cards.
During the lunch, we find two resources that are really excelling and they are selected for the second line of video assets. On the third day, they begin work with the video assets to capture interviews and the others continue their research and help on various tasks. One of our best writers turns their focus on the blog post about halfway through to make sure it is finished along with another who will work on the other tasks attached to the blog. As we come to the end of the Sprint, the team has experienced some part of the video production and we have completed the Content Items without needing to stay late.
What is next for the team?
Should they go back to producing two videos and one blog post in the next Sprint? Probably not. They should move the priority of other items the team is equipped for and continue with the one video over the next few Sprints. Over time the second-line of video assets will start working on tasks and the main video asset will watch and teach. Then they will begin to work on items separately and bring them together for final review.
At this point the team should bring in another video into the Sprint. The one caveat is making sure everyone is aware of problems that might arise. The Bus Factor is getting better but they are not out of the woods yet. However, this time they are more prepared to complete the work and know what problems to look for.
It will take a long time for the second line of video assets to become as strong as our main video team member. They will have to go through their own trials and keep up with the tools, the equipment, and the techniques but it is possible. Since they are part of a team, they are not alone.
Working in Pairs
In the scenario I have outlined, there are several times where I suggested the team pairs up during their work day to accomplish a task. In the early 2000s when Extreme Programming was the rage, a concept called Paired Programming was something most development teams tried. The idea was to put two developers together in one cubicle with one machine to address a problem. The four hands on deck approach created the ability to speak freely and debate solutions without taking a single person down a path without the consensus of another.
Some teams tried this approach on every problem and others used it on the bigger ones with larger consequences. On the other hand, I found the process to be excellent for not only problem solving, but for education. Just having the ability to describe a process, limits you to the imagination of the other members of the team. A demonstration is typically controlled and the problems have all been solved before the presentation begins. When you work in groups on a task, the scenarios and troubleshooting processes appear on their own and questions can be asked when there is a need for clarification or discussion. It is not on the person driving to make a speech, prepare slides, or fill the time with words. Instead they are just doing their job with an audience.
Commitment to Deliver
Each time the Content Developers took on a Sprint, it was their responsibility to finish it. Even though the majority of marketing teams that just raised a white flag when the video assets were not able to deliver and blamed it on resourcing, that is not the position of an Agile Marketing team. These teams finish what they start and make adjustments over time to their commitments and estimates to match what is possible and sustainable.
Why do I draw such a thick line in the sand on this item? For Content Marketing, we need to make sure we have frequent and consistent deliveries of Content because we are building an audience who is expecting it. Imagine the evening news in your town not airing because they didn’t have enough time or a resourcing issue arose. That would be unheard of and just plain wrong. The show must go on and the same goes with your marketing efforts.
Another reason is most marketing teams complain about not having enough resources and too much work but how is anyone outside of the department going to be able to measure that? With a strong commitment and some skin in the game, you can demonstrate what is possible with the team you have and show examples Sprint after Sprint of delivering on your promises. With data like this, you can forecast what a new member of the team would need to possess in skillset and the impact it will have when they are a fully productive member of the team. Those numbers are hard to ignore and the Content Owner or manager of the team can take that to the next budget meeting when describing the resourcing issues.