Five Tricks to Ease the Integration of Designers in an Agile Team

I have been working within Agile teams for three years now, and I love it. But it was not always so. At first, I had to overcome several problems: insufficient design budgets, lack of understanding of my role within the team, too little time due to too many meetings

Here are a few tricks I picked up over the years.

1- Take the time to get to know your team

When you start a new project and are working with your teammates for the first time, get to know them. One way to do this is to organize a project launch session to collectively define your project objectives, your individual roles and responsibilities, and your respective expectations. With your designer hat on, explain your approach and what you would like to accomplish with this project. Get the team to validate that your project is within budget and that your ideas are not too complex to execute. This will save you much frustration down the line.

If a launch session is too time-consuming, at the very least, you should have a team lunch session or happy hour. This will allow you to get to know your teammates in a more informal setting. 

2- Build a multidisciplinary team that will stick together

In the Agile world, the more a team works together, the better it becomes. The more various and diverse the projects, the better you get to know your teammates’ strengths and weaknesses. For example, feedback sessions are a good time to talk about what’s going right and what’s going wrong, and to discuss strategies to iron out the issues. The longer a team works together, the less the same issues crop up again and the more positive the feedback sessions become.

If you work with more than one team at a time, you will have to adapt to each team’s personality. Refer back to trick number one: get to know your team. Then, when you see something that is working well for one team, you can talk about it during feedback sessions with the other teams. 

3- Break down your sprint in three stages

What works for me is to break down my sprint in three stages: future, present, past. The order you tackle these three stages can change from one sprint to the next. 

The following is an example where the team is on sprint 2. 

Future: First, I prepare interfaces for sprint 3 by making sure I thoroughly understand the client’s user needs. Then, I validate my prototypes with the client and with the team. All this will ensure that the criteria for success of sprint 3 are met. 

Present: Then, I work on the current sprint, in this case sprint 2, ensuring that the design is well integrated and that the objectives are fully understood by the team. 

Past: After giving the client and end-users an adequate amount of time to test the application, I ensure that sprint 1 interfaces and functionalities are validated by all stakeholders and that their experience with the application is positive. Any modifications or corrections are prioritized for the next iteration.

As I said, the order of the three stages can vary from one sprint to the next. Also, your time will not be split in three equal parts. At the beginning of the project, you’ll want to spend more time on the “future”. While you won’t be able to plan it out to the last detail, you should at least have a good overall vision of the project in order to build logical interfaces throughout the sprints. Towards the end of the project, your efforts will turn to testing and validation. 

4- Choose your meetings

Most of the time, I work on two or three projects simultaneously. That means a doubling or tripling of daily meetings, planning activities and feedback sessions. This on top of client meetings and work sessions… And when the various projects involve as many teams, well, you spend your day in meetings.

Your best hope is to stagger your projects rather than launching them all concurrently. As a designer, your time will be heavily solicited in the first few sprints. By staggering your projects, you can spend more of your time on the new projects while still keeping an eye on the others.

Do, however, always attend the feedback sessions in order to confirm that your involvement in the various projects is adequate and that there are no major issues. 

5- N’oubliez pas la base de l’agilité

Post the four values of Agile Software Development by your desk:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan. 

Adopting Agile development is not always easy, especially in the beginning. But it helps to remember why we seek to be Agile and what it means for our work.

Adapting from waterfall working methods to an Agile system takes time, on both the team’s part and the client’s part. So give yourself time. And give yourself license to make mistakes.

Source : https://fr.wikipedia.org/wiki/Manifeste_agile