A few days ago, Liam, a fellow Medium Member, asked me about my experience in integrating designers into an agile (Scrum) Team. Liam is a designer and works in an agile cross-functional team. He is primarily responsible for the design and user experience of the product suite. His questions got me thinking.
- What is the best way to integrate a designer into a Scrum team?
- How should the Product Owners and Developers be integrated into the design process?
- What mindset should be established in the team?
- What should the process look like? At what point should Ux design activities be done?
- What should the designer’s goals be? What are the goals of the Product Owner, and the team?
- What is the added value of the design activity to the product and how should this value be seen by the team?
Here are my top takeaways from a discussion with Liam and from years of experience in working with designers as Team Members of Scrum Teams.
Liam is primarily responsible for the design of the product. He is mostly not involved in backend features because these topics are too technical, but as soon as a change affects the frontend, he is integrated into the design process by the Product Owner. He then takes care of the design and tries to understand the requirements of the users. He works on the designs, creates a design for the user interface, and considers the user experience in a way that creates the greatest possible added value for the user. His designs are then presented to the Product Owner and later to the team in refinement meetings. After that, all artifacts are added to the affected product backlog item. In this situation, he asks himself if it would not be possible and smart to involve the developers earlier in the process.
As a Designer in a developer team, I think your major goal should be to introduce the right thinking and mindset in the Team. You want everyone to think as a designer, understand the user needs, and develop a product with an awesome user experience.
Design should be an established mindset in an agile team. If you only use your developers to write software, you lose a lot of potential. Therefore, every interdisciplinary agile team should strive to fully exploit all potentials and also include the developers in the design process. Good user experience and a good user interface design with excellent usability will lead to increased product value. And this is the main responsibility of a development team — to maximize the product/business value.
Design work must therefore be seen as value creation. Everyone on the team should be responsible for the design — for good user experience, good usability, and design.
As a designer in an agile team, you should try to make yourself unnecessary. Transfer your design know-how to the team and build design knowledge with the developers. Design must be an integrated part of all activities and tasks of the development team. In the frontend as well as in the backend of the product.
Now that we have clarified what the main goal is, the question is how to achieve it. How can we establish design as an important integral part of development work? How can we share knowledge and promote a design mindset?
To improve the collaboration between the development team, the Product Owners, and the designers we need a strategy. We need to be evangelists and talk about different methods, thinking models, and tools like the Dual Track, Personas, the Value Proposition Canvas, the Kano Model, and how to cut features.
The strategy should be:
- Show the value of a good User Experience
- Integrate User Needs in discussions (Kano, Personas)
- Document User Needs not Requirements
- Work close together with Product Owners
- Work regularly and close together with Developers
- Introduce Discovery Sessions in Refinements
Let’s start.
One of the most powerful things a designer and development team can do to find out if their product has a good User Experience is to show the product to the users. In Scrum, we have Reviews where we show our work to the Users and stakeholders. We release our solution early and often and collect feedback. We have the agile principle that “Working software is the primary measure of progress.”
If you’re just using your engineers to code, you’re only getting about half their value. — Marty Cagan
As designers, we define and document User Needs, and Features are only done when they satisfy these needs.
A Feature must be delightful, intuitive, and usable (as shown in the graphic above). Dan Olsen first introduced this pyramid in his book “The Lean Product Playbook” in the context of an MVP. Providing only functionality without these properties is not enough. The Team must learn that and the way to learn this is by getting direct feedback from the users and the market.
But how do we aim for delightful product features? Or in other words: How does the team know what the users want?
The simple answer is, no one knows what the users really want. Not even the users know what they want. But to ensure that the team is on the right track and can find out about the user needs some techniques help the team, the product owners, and the designers to create better hypotheses about the users and the market. Designers, Product-Owners can create Personas of the main User Groups of the Product. They can use the Value Proposition Canvas to design the product and its features accordingly.
By filling out the Value Proposition Canvas (by Alexander Osterwalder et. al.) you get to know the pains, jobs, and gains of your Persona. Thus you can document these needs and craft your product’s value proposition for the Persona.
The Kano Model helps you to further investigate your Products Excitement Features, Performance Features, and Basic Features.
Put all your findings into the right place and link them to Product Backlog Items. Define and document User Needs, not Product Requirements. This will help the Team to explore the problem space and define the right solution in the solution space.
To get the development team on board and on a path to a great user experience, it’s very helpful to put different kinds of tasks in a different perspective. There are product backlog items where the team needs to figure out how to satisfy user needs, they need to be designed, researched, and tested and there are product backlog items where the team almost certainly knows how to develop them and how the user will like the new features. To separate these two kinds of Backlog Items and to get the team into exploration mode it makes sense to talk with them about Dual Track development.
In Dual Track Development (first mentioned by Jeff Patton) we split the development stream into two substreams. In the Discovery Track, you try to understand the user needs, experiment, explore, design, and try to get feedback very fast. The team starts to see the world more through the eyes of a designer. In Delivery Track the team tackles the harder technical but more certain tasks. They have time to focus on things like scalability, reliability, performance, and maintainability because it is already clear that the developed features will satisfy the user needs.
The fastest way to start with the Discovery track is to introduce Discovery Sessions to the development process. We can replace Refinement Meetings with Discovery Sessions and shift the focus of the team from a Meeting where we discuss requirements of features to a working session where we try to understand the user needs, define exploratory approaches to find out what the users really want, and if and how we can build it. To support these sessions we use the created personas, value proposition canvas, and crafted hypotheses of the user needs. In such sessions, it is often useful to also use tools like User Storry Maps and Example Mapping to design and explore User Needs.
With Example Mapping, we can figure out what open questions still need to be explored and answered.
One major success factor for the introduction of a designer Mindset is to set objectives differently. Developers are used to setting Goald output oriented. the job is done when a certain feature is deployed and thereby shipped to the user. The user can use the new product feature and the job is done — right? Wrong!
Especially in a complex environment, we don’t know when we are done if we have developed the right feature in the right way. That is why we need to set objectives and goals differently. Plan outcomes not outputs. If we are only done when we satisfied the users, the users are using the new feature and are happy with it then we are done and made a good job.
That is why you should set your Sprint Goals like this:
- X users are happy with the new features use it daily and create XYZ megabyte of data each day.
Not like this:
- We shipped the new feature and deployed it on the customer system.
Your goal as a designer in an agile team is to convert every developer to a developing design person. You should establish a mindset of added value through good user experience. You can use the Value Proposition Canvas, Personas, Dual Track Development, Discovery Sessions, the Kano Model User Story Mapping, and Example Mapping to define Hypotheses about the User needs and explore these Needs in the Discovery Track. Your team only achieves the goal and makes a good job if they create a product that is delightful for the user, easy to use, and satisfies all user needs.
Dan Olsen — The lean Product Playbook
The Value Proposition Canvas — Alexander Osterwalder et. al.
Marty Cagan — Integrate Developers
Jeff Patton — Dual Track Development
Jeff Patton — Story Map Concepts quick reference: http://www.jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf
Jeff Patton — User Story Mapping: Discover the Whole Story, Build the Right Product. 2014 O’Reilly
