It’s hard to juggle planning against the pressures of unplanned work due to change. As a full-time communicator, I’ve found myself trying to balance the organizational needs of planning against the realities of responding to change in a timely fashion, only to realize that I seemingly could not find a way to do both well. Until now.
Over the years, I’ve worked with and around software developers and have come to first appreciate and then come to study and use their secret to delivering code quickly and adapting just as fast to new features and bug fixes.
A very brief recap of they way things used to be versus how they are now in project planning:
- Software used to be fully considered, mapped out, documented and planned for a final finished release. This method, called Waterfall, was to do all of the pre-planning and documentation for everything the software would need to do in one, very large and complex project plan, complete with Gantt charts to estimate work over months and even years.
- Software-as-a-Service (software you use online, in an app, or in a browser, most frequently) changed the need for more iterative software changes that responded to demands and needs of users as quickly as possible – sometimes days or weeks.
- Agile is a belief that a collaborate team working in short durations together can deliver more often and change more rapidly.
- Scrum is a methodology for applying Agile that plans all work in chunks (2 to 4 weeks is common) and follows ‘ceremonies’ that organize the work during.
- Kanban is an Agile method that visualizes work (a board with notes or cards), limits the work in progress (no multitasking allowed!), focuses on workflow, and continuous improvement through measurement, discussion, and learning.
So do I use Scrum or Kanban? Actually, both. I use Scrumban, which is a hybrid model that, in my opinion, takes the best Agile practices of Scrum and the visualization and flow of Kanban. I think it’s ideal for marketing and communication teams that must plan some level of their work (Editorial Calendars) but be able to pivot as new, urgent unplanned work or changes due to external pressures (Social Media timeliness, change in publication dates, a shift in deliverables, etc.).
Marketing is always in a responsive mode given the nature of the work, so planning every detail out with rigid inflexibility for two weeks at a time is lunacy.
Allow me to illustrate how I lead our team in using Scrumban.
We plan our work into two-week Sprints (a term that describes a focused team effort for a limited duration) and spend several hours on the first Monday of a Sprint in a Sprint Planning session. To organize and prioritize our potential work for these two weeks, we first look at our Editorial Calendar to see what’s due next, and when we have to be ready to publish. Once all due dates and work related to these timelines is organized into Epics (over-arching projects) and Stories (tasks and dependencies) with fully detailed User Stories (a short Scope of Work), we then look at what else needs to be done that doesn’t necessarily have a hard deadline. To rank these, we discuss which of the Epics will realize the most value for the company. Finally, if there’s a dead tie between due dates and value, the tie-breaker is WSJF (Weighted Shortest Job First). This simply means that if all other things are equal, do the one that can be done fastest, first.
During a Sprint, we have opted for twice daily stand-ups, as we have European office that’s 7 hours ahead of us that also has a marketing team. By meeting in our morning (their afternoon), we minimize the time lost when they leave for the day and must wait to hear back from them until the next day for shared project work. The daily stand up identifies what we’ve done, what we’re working on and what’s in our way or waiting on approval. Our second stand up is near the end of our day and only includes our U.S. team.
Perhaps the biggest reason we use Scrumban instead of Scrum is because of the nature of change associated with content marketing automation and iterative content development. This is most evident when we have unplanned work (which we call Spikes) that MUST be done. We capture this work as uniquely colored/marked cards to visually represent the unplanned vs. planned work. At the end of a Sprint, we calculate the estimated time vs. actual time spent on planned work and calculate the Delta. We then add the Spike hours (time associated with unplanned work) and subtract those from the Delta, which both more accurately explains why we didn’t hit our 100% planned work completion but still leaves room to show the difference between missed estimates and the not completed unplanned work.
So, to summarize: Scrumban leverages the ceremonies of Scrum and the flexibility of pull-based Kanban, allowing structure and organization to keep the framework in place as well as the accountability and transparency high while also adapting to the realities of change during a Sprint for marketing. I highly recommend following Andrea Fryrear from Marketer Gizmo, who has written a plethora of great content on Agile Marketing.