The Agile Designer Series - Choosing the Right Agile Practice
Prologue: The following article is targeted for Product Designers wanting to understand Agile and how to apply Agile methodologies into their daily process. Although, many of the recommendations can be applied to other design industries and disciplines.
The many flavors of Agile
There are many many types of Agile methodologies such as Scrum, Kanban, Extreme Programming, Crystal, Dynamic Systems Development Method, and Feature-Driven Development to name a few. I would encourage you to research them so you can better understand which practice fits your needs. For the purpose of this article I’m only covering Scrum and Kanban as I have experience with those.
Scrum
With Scrum, the product is built in a series of fixed-length iterations called sprints and work is pre-defined in what are called “user stories” that are in priority order as defined by the Product Owner. Each user story is kept in what’s known as a Product Backlog.
During each “sprint” the teams decided on how many users stories they think they can complete within the fixed timeline. Furthermore, during the Sprint no new work can be added. Work is basically set and committed to. Any new work or issues that arise automatically get put into the Backlog where they will be “groomed” and prioritized relative to current priorities by the Product Owner.
Benefits
One of Scrum’s main benefits include working from a prioritized set of user stories within the Product Backlog. The backlog is a prioritized feature list containing short descriptions of all functionality desired in the product. The backlog is mostly comprised of User Stories but larger efforts are grouped into Epics.
To be clear, a Product Backlog is not the solution rather it’s the user problem, feature or functionality that’s desired in the product. Because design is responsible for creating the visual and user experience, solutions should be written as part of the requirements.
One of the key components to Scrum are the meetings. To most Designers meetings really means one thing — time suck. Meetings can be the death of productive designing because we need large swaths of time to think through problems and meetings tend to break that up. Since implementing Scrum with my design teams, we’ve reduced the number of meetings with shorter, more focused and more productive ones.
Scrum has a set number of meetings that bring structure to each sprint.
Sprint planning — The sprint planning meeting involves pulling items from the backlog into the sprint and prioritizing the user stories that will be carried out during the sprint.
Story grooming — Story grooming meeting involves sizing and understanding what requirements are and typically happen before planning and usually with key decision makers.
Daily stand-up — The daily scrum or stand-up meeting includes a short daily meeting where each member of the team briefly shares what they are working on. The daily stand-up typically lasts no more than 15 minutes.
Sprint demo — The Sprint demo meeting reviews the team’s progress after each sprint.
Sprint retrospective — The retrospective meeting discusses ways to improve the process.
Drawbacks
Some see the Scum meetings as too invasive. In addition, a good many software companies are moving towards continually delivering features. For instance, Amazon is known for releasing features every five minutes and Facebook developers are expected to release code into production on their first day. With Scrum framework that would be hard to do. Pivoting or continuously delivering new features constantly is where Scrum would not be a good method.
Kanban
The Kanban methodology is way less structured than Scrum. Essentially teams work from a prioritized backlog of stories and there typically isn’t a specific timeline like Scrum. In Kanban, you organize your work on a Kanban board. You have columns also known as states, which every work item passes through — from left to right. individuals pull work items through the columns as work progresses. Boards may have various swim lanes — horizontal “pipelines” for different types of work. Typically boards consist of the following pipelines:
- Backlog
- In Progress
- Blocked
- Delivered
- Done
The basic principle is you move a work item from the “Backlog” into “In Progress”. Work that item until it moves to “Done”. Blocked is there in case progress get’s “Blocked” by a dependancy. Once you’ve completed a story you move to the next highest priority story, rinse and repeat. Obviously, each team can set up it’s own pipeline as needed, but basically that’s how it works.
For every column (state) on your Kanban board you should define a “Work In Progress” or what’s known as the WIP Limit. The WIP limit tells you how much work items are allowed to be in a certain state at any given point in time. If a state reaches its predefined WIP limit, no new work can enter that state.
Benefits
Kanban allows for quick, fast and constant iterating on features. Typically teams that have been practicing Scrum and want to move faster use Kanban due to its constant delivery cycles.
Drawbacks
For design teams straight Kanban can be challenging because it focuses on continual improvement and to some extent feels as if there is “no end in site.” Often times designers benefit from taking time to create a vision or longer term path. Not to say Kanban can’t do this but it’s really geared towards short iterations and constant tweaking.
That being said, Kanban is a great way to force process management and allows a clear understanding of what’s being worked on and where things may be “blocked”. Kanban boards are one of the most appealing aspects of Kanban and is why so many teams use this method. In fact so many teams love the Kanban board they often times combine Scrum and Kanban into one — ScrumBan.
Next steps..
When deciding which Agile method to implement for your team, the best advice I can give is to experiment with both Scrum and Kanban. Agile is about adapting to change quickly. For my team we practice what’s known as ScrumBan.
In my next article I outline Scrumban methodologies and describe how to take first steps towards implementing Agile into your daily design routine. Look for that sometime in July 2016. In the meantime, if you have any questions feel free to ask in the comment section below.
