The Waterfall method for project management is the most natural process to complete projects in a design office. Each step (Planning, Design, Development, Release) relies on the previous step and is run through like an assembly line. It's easy to use and manage, easy to estimate and schedule on a gantt chart.
Image from Smartsheet.com
But Waterfall comes with disadvantages built in that make it hard to adapt to changes in the project. And the longer a project takes, the more changes become necessary, pushing the release back even farther (and increasing the budget)! Waterfall relies on meticulous planning of the project scope up front to avoid these changes. But it's near impossible to predict what the project requirements will be at the end of a long term project.
Origins of Agile
Agile was developed to take advantage of the "Kaizen" manufacturing processes popularized in the 90s which focus on flexibility, continuous improvement, and speed. Building on the Kaizen philosophy, the 12 core principles of Agile were released as a "manifesto" for software development companies. Agile methodologies all focus on the needs of the end user, face to face communication in the team, constant collaboration with the client, and fast releases.
There are dozens of methodologies relating to Agile philosophies into a production environment. Scrum, Kanban, Crystal, Spiral, Extreme Programming and Lean to name a few. These methods can be used all at once with little overlap, as they each address a different part of the Agile process, but are best applied piecemeal to find the methods that best fit your industry requirements and office culture. And over time if one method doesn't work the Agile/Kaizen philosophy demands it gets removed, improved and replaced as quickly as possible.
While the developers of Agile and many of its methodologies are generally software developers, the principals have been applied to law, PR, finance, healthcare and many more industries. For the design office we can adapt parts of two of the most popular methods: Scrum and Kanban.
The Scrum Process
Scrum adheres closely to the Agile philosophy by breaking the overall process of a project into much smaller cycles called Sprints. Each Sprint contains the entire process you would have in a Waterfall applied to individual features. Each feature is planned, built, revised, finalized and released one by one. All the while collaborating with the client's needs on the one specific feature in the Sprint. This quickly builds high quality reliable results.
Scrum begins with the Product Backlog, which is a series of features/requirements that have been written and prioritized by the client and design team (or project manager) at the beginning of the project. To better focus on the target audience while building the backlog, each requirement should be written as a User Story. I.e. "I am an association member, and I need to make a donation."
At the beginning of each Sprint, a User Story from the Product Backlog is chosen and broken down into smaller individual tasks that are necessary to complete the feature. These tasks are then prioritized, and given a budget of hours based on the complexity of the task before they're added to the Sprint Backlog.
Then over the course of the Sprint (usually 2-4 weeks), the team will complete each task in the Sprint Backlog while collaborating with the client and project manager. Daily stand-up meetings with the team (15 minutes max) keep the team on track, and let project manager know if there are any obstacles the team has keeping them from completing a task.
The end of a Sprint should produce a focused, vetted, high quality piece of the overall project - ready for release.
Image from Smartsheet.com
Kanban in a Can
Kanban is Japanese for "visual sign" or "card." It's basically a method for tracking workload on a board for the team to work on together. A traditional board has three simple columns: to do, in progress and complete. The in-progress column of the board represents the maximum amount of work the team is capable of juggling at once, and nothing can be moved into that column if there is no space.
Image from Smartsheet.com
Kanban's simple visualization can be overlaid on any kind of existing workflow. The board makes it clear to the team which tasks are up for grabs at all times. You can color code each card in the columns to assign specific departments, designers, or related feature. The emphasis on small incremental changes in Kanban makes it a perfect companion to the Scrum process.
Customizing Agile for the Design Office
Visualizing the Scrum process on a Kanban board is pretty straightforward. The Project Backlog and Sprint Backlog are subcategories of the to-do column. When a task is pulled from the Sprint Backlog it's moved to an available space in the in-progress column, which also includes review/revise/test subcategories. And the complete column contains all of the tasks that need to be reviewed (and billed) at the end of a Sprint. The board helps to facilitate the daily stand-ups to check on a Sprint's progress, the team's productivity, and clear up any bottlenecks in the process.
For a design office, two additional columns can be added to the board to clear up a task's status, and help the project manager focus on problem areas: delayed and dropped. Tasks may be delayed for any number of reasons, and will often get pushed back into the next Sprint. And as a project's requirements evolve, it's likely that some tasks will become obsolete. Keeping track of the abandoned tasks will help clear up the active workload, and help the project manager make adjustments to the billable time.
How To Create Schedules and Budgets in Agile
At the beginning of a project the client, understandably, wants to know how long it will take and how much it will cost. But isn't an Agile process constantly changing? How can you give an accurate estimate without a specific scope?
Technically, you can't give a highly accurate estimate or timeline in an Agile environment. Though historically, you can't do this with a Waterfall environment either, you only pretend you can. Agile embraces the reality of a project's process, and from the very beginning makes it clear to your client that it will change, and always for the benefit of the project. Those changes will be clearly marked on the Kanban board as out-of-scope tasks are added, and obsolete tasks are dropped. While constant collaboration and short Sprints negate the sticker shock that inevitably happens at the end of a Waterfall project.
An agile estimate at the beginning of a project is no different than a Waterfall estimate. Each requirement in the scope is given a time estimate that is multiplied by the hourly rate. There's an Agile technique for creating a time estimate in such a way as to maintain flexibility. Once the project's scope is broken down into the Project Backlog, each User Story is given a Story Point value (1-100) that represents the total amount of the team's engagement capability needed to complete that requirement (use this point value to estimate hours available for each task in a sprint). Generate the timeline (and total cost hourly) based on the team's engagement. These Story Points may fluctuate in estimates while teams get used to using Agile, but will stabilize over time.
Design Projects in an Agile Environment
Because Agile was originally conceived in a software development environment, these techniques naturally apply to interactive design projects without much changed. Marketing, SEO and Social Media projects can also easily be adapted to an Agile method because they include specific tasks, and their need for constant change/quick delivery.
Branding and print projects may be a challenge for an Agile environment, because it's more difficult to turn around a final release-ready part of the project after a short Sprint. In these cases, a project can still be broken down into smaller tasks but the output will necessarily be iterative instead of final.
Comments
Questions or comments? Join the conversation!