“Agile” is a peculiar industry term for designers who have never worked in the software space. It’s a phrase which gets used a lot by employers and recruiters, but what is it exactly? The following is from my perspective as a web professional and looks at what you need to know as a designer within this space.
This is not a comprehensive guide, nor gospel about “scrum” or “agile”, but it will give you a heads up if you're going for a job interview in a company dealing with products or software.
I'll touch on what it is, how it works, including other related terms such as “product backlog”, “sprint backlog”, daily meetings and the concept of potential shippable product increments.
What Are we Talking About Here?
“Agile” came about in 2001 when a group of software developers decided that they needed a different workflow. They formulated twelve principles and wrapped them up as a manifesto. It describes a process, a methodology.
Agile
The following diagram illustrates a typical agile process, in a series of “Sprints”.
Within the definition of Agile there are more refined approaches, one of which (and perhaps the most popular) being “Scrum”. Read more about the specifics of Scrum on scrummethodology.com.
In any case, the Agile method involves working through iterative, incremental cycles. The best way to understand it is to look at it in contrast to the “Waterfall” method.
Waterfall
Waterfall is the more traditional approach to product development. It’s carried out sequentially and is subsequently more rigid and arguably less effective.
Some benefits of agile (rather than waterfall) include the final product being released faster to market, being more collaborative and requiring incremental investments. On the flip side, it can make stakeholders nervous because of its flexible nature. It is also often misunderstood.
How it Works
Let’s see how an agile workflow looks in a practical design situation.
Product Backlog
This is a product backlog; it has all the features that will be in the final product. These features are based on user needs and translate to some benefit. Each feature is placed on an individual index card and is semantically structured, often from the perspective of personas, in a certain way for consistency and clarity. For example, “As Bob, I can.. so that I can....”
Sprint Backlog
For each card you, as the designer, need to estimate how long it will take. The developer also has to make an estimate. It’s just an estimate–after the first sprint you will have a better idea of how much time certain tasks will take. Generally, each feature will be given a “t-shirt size” (XL, L, M, S) and number of different “sizes” will be put into a sprint.
As well as the “project backlog” section there are also other “buckets” such as the current sprint, in review, blocked etc. This is posted on something called Kanban wall (Kanban literally meaning “signboard” in Japanese): a visual way of posting index cards to get a big picture of all the features required. However, you can also use an online tool, such as Trello for similar effect.
Daily Scrum Meeting
The daily scrum meeting is effectively like “standup”. In my experience, everyone on the team already knows what you and what they are working on. It’s a good chance to touch base in the morning and set direction for the day to come.
Potential Shippable Product Increment
After each sprint the philosophy is that you should be able to deliver “shippable increments”. This terms applies broadly to many industries and is, in theory, difficult to achieve. It’s effectively a “slice of the product” something that has an increment of product functionality.
What You Need to Know as the Designer
Working with User Interface Products
Although Scrum Agile methodology is rooted in software engineering, it can be very effective for websites and apps. For example, you may begin from a user persona that you’ve created, outlining the needs of your target user and using that to branch out and identify the features required.
Developing Ability to Estimate Accurately
You will need to collaborate with a product manager, or scrum master (depending on the organisation you’re in) who are generally responsible for keeping things in check. They will ask of you to estimate accurately as possible. You’ll find it tempting to go for optimistic estimates, but be realistic–nobody will hold it against you.
Highly Collaborative
One of the best parts about the Agile methodology is that it is a highly collaborative way of working. For example, in an old school waterfall way of working you will generally hand over your designs to a developer and never see them again. However, an iterative workflow will see you sitting next to the developer and working in tandem to achieve each iteration as you go.
Conclusion
As a designer, making the transition from freelancer to working within a big company, with multiple teams, on Agile projects, can be a big leap. In my experience, it is a useful framework to work within and its principles can even be used in your own personal projects. Understanding the collaborative working style and learning how to estimate will allow you to operate more effectively within a design team.
