Recently, our agency engaged in a project that had many, many moving parts and had only a finite amount of time to get everything done. At the onset, it was difficult to see how the overarching project and subsequent mini-projects could be completed within the scheduled due date. We determined that this endeavor was going to require an altered project management approach for our company: one that emphasizes project visibility, enables easier resource prediction and allocation and adds structure to the project cycle to allow for frequent, incremental updates. We chose to use a derivative of the software and development management process known as Scrum.
Have you ever had anyone ask you, “How do you eat an elephant?” If you haven’t, the answer is “One bite at a time.” At the heart of scrum is the idea that large, multidisciplinary and complex projects, called “epics” (in Scrum speak), can be broken down into numerous mini-projects or “user stories” to make the daily effort much more manageable. Essentially, what scrum does for project management is what the assembly line did for automobile manufacturing. To take this analogy further, think of the car as the “epic story” and consider individual tasks like putting on the tires, installing the seats and applying paint, as the user stories. For our agency’s particular project, our ‘user stories’ totaled 60-70 over a two-month span.
Once we had a complete list of all the user stories for our project compiled, we went through a process of defining how long each of the individual tasks would take. This approach helped forecasting how many resources would be needed for a project, as well as obtaining an accurate measurement for overall bandwidth for the project team. When the time estimation was complete, the stories could be scheduled based on priority level and resource bandwidth. Also, any items that had dependent factors and needed to happen in a linear fashion need to be accounted for. An example of a project dependency is when designs for a page must go through completion and approval before they can be sent to a web developer to be built.
Scrum scheduling is dependent on short-term project cycles – or “sprints” – to get you to an end goal. These sprints are usually 1-3 weeks in length depending on your project and organization. The objective of each ‘sprint’ is at the end of the cycle, the project team has produced a working and tested component/feature/function of the larger project. Theoretically, you should be able to stand up the end result by itself as a working product. For our purposes, we chose to use a two-week sprint cycle.
Throughout the Scrum process there are frequent checkpoints called “stand ups” to allow the project team to communicate the progress that is being made on their tasks. It’s strategically called “stand-ups” because you are physically standing during the meeting. This is used to encourage people to speak while trying to limit the time spent in the meeting, usually around 15 minutes. During the daily stand up, each team member describes these three things:
1. What you worked on yesterday
2. What you will be working on today
3. Any impediments that prevent one from completing one’s work
While we’ve used derivatives of Scrum before, we learned a great deal more about the work and ourselves during this versioning of Scrum. After using this process for around three months, we’ve learned a few things about Scrum in a marketing agency – or at least our version of it. While many of the articles and blogs that I’ve read on the implementation process actually seem to be overwhelmingly positive, we found that there are some good things and some not so good things about scrum. Some of these were attributed to the way we set up the project and others are inherent to the method, which I will explain further in bulleted list form – since I know how important that is to all you blog readers.
- Project visibility for all team members
- Reliable resource forecasting
- Scheduling becomes more predictable
- Short-term goals give the team “quick wins”
- Makes high-volume projects seem more palatable/reduces stress
- Somewhat flexible for allowing scope change outside of the sprint cycle
- Somewhat rigid for adding new stories and scope change within a sprint cycle
- Can be a cumbersome process to set up and maintain
- Frequent checkpoints and updates can take substantial time away from work
- Simultaneous work on can prove hectic for the team
- Requires all team members to provide constant communication, which is not always possible
- Extending timelines in the creative cycle can take away from development and QA time
- Hard to see project dependencies related to other user stories
- Can create a myopic point of view rather than seeing the project as a whole
- Hard to synchronize ad hoc client expectations and needs to the project timeline – specifically with high priority items
Ultimately, the good outweighed the bad and the team did enjoy the process – for the most part. Some team members reported that they felt that the process was overall much smoother and more achievable than if we had just used our traditional process. Unfortunately, frequent scope changes and last-minute-high-priority items almost always caused us to eat into our development cycle and QA time. The lesson to be learned here is the value of implementing the full scrum process and not a scrum-lite version for a better overall result.
Needless to say, we will be making adjustments to our internal processes during the coming months. How we use scrum moving forward is still being determined, but what we have learned throughout the course these past few months, will prove invaluable.