How to build a UX and development team that really delivers (Part 2/2)

In Part 1 of this series, I talked about the people-related challenges of integrating UX into an Agile team. Once you create a cohesive team, it’s now time to polish the process. Are you ready?

It is true that process for the sake of process won’t do you any good. But, if you’ve already adopted Agile as your development methodology, then it makes sense to integrate your UX into that same rhythm. In this post, I describe the areas you’ll need to focus on to be able to integrate these disparate processes.

Share the big picture (constantly)

As Product Managers, we own the big picture, and it’s our responsibility to ensure everybody is on board. People in your team need to know “why we are doing this”. It is also important for each individual to understand how they are contributing to the overall success of the product and the company. Knowing the big picture will help them understand the trade-offs and the “why” behind the many decisions you make every day.

In marketing, they say a message needs to be received 7 times before it registers and people even become aware of what the message was about.  It’s the same thing with vision-type messages. You need to be consistent and communicate often. It’s your job to ensure the message is understood by everybody and that may require customizing the message for different groups.  A team that is well aligned behind overall objectives will be a more efficient, satisfied and productive team.

To drive this home, let me share a story. Rumor has it that in the 60’s, an auditor visiting NASA bumped into a janitor mopping the floor. The auditor stopped and asked the janitor: “excuse me, can you tell me what you do at NASA?”.  To their surprise, the janitor answered: “I’m helping send a man to the moon…” That’s exactly the type of cohesion we should pursue in our teams! That’s big picture trickling all the way through the organization!

In Agile, we are all one team

When people of different disciplines come together, it is natural for people to form teams within a team. When integrating UX into Agile, the initial (and natural) tendency is to treat it as “the UX team” and “the Development team” that are now working together.  Unfortunately, that’s not integration. What you are after is having a unified “product team”.  This product team includes UX designers, developers, architects, QA testers, scrum master, scrum owner, etc. And together, the team produces amazing software.

The key to a unified team is bringing everybody together under the Agile umbrella. In Agile, there are chickens and there are pigs. Everybody in your team, regardless of their discipline are pigs (i.e. they are committed). Therefore, everybody will be aligned behind the sprint goals. No exceptions. We are all one team. And as a team, we fail or we succeed together.

Therefore:

– There’s only one backlog: the product backlog. No separate backlogs for designers or developers.
– Everybody has stories and tasks. In a sprint, incomplete tasks cause the team to fail, regardless if the missing tasks were design or development.
– Everybody attends stand-up meeting. This is important because it serves as a daily reinforcement of the sense of team.
– Everybody uses the same Scrum board.
– Everybody attends planning, demo and retro.

Use “sprint zero”

One of the main challenges you’ll face when integrating UX into Agile is that their methodologies are quite different. For designers, the creative process is more akin to waterfall, and therefore is hard to adapt to Agile which is iterative in nature. As a simplification, the creative process can be defined like this:

So how do you incorporate these opposing processes? A good way is by using “sprint zero”, meaning that the UX designers should always be one sprint ahead from the developers. During sprint zero, you (as Product Owner) work with the UX designers to define the features and create wireframes. During sprint 1, the developers implement the designs created in sprint zero and the designers supports the developers with any questions or fixes that might arise.

I’m personally not a fan of the term “sprint zero” because it implies that developers are completely useless until the designers deliver their first set of wireframes. To me, this sounds like a very “design-centric” view of the world. Taking a “product-centric” view, all it means is that the UI development shouldn’t start until some wireframes are ready.

There are plenty of tasks the back-end team can work on before the need for a UI. They can work on the software architecture, initial proof of concepts, studying feasibility of some unknown technology, etc. The only reason I use “sprint zero” in my post is because it’s an accepted term and that’s how plenty of the documentation out there refers to it. Not a big deal, just putting things in perspective.

Go lean on the UX deliverables

The Agile manifesto states that “We have come to value working software over comprehensive documentation”. In this sense, working software is the ultimate deliverable. Anything else, including UX deliverables are just means to an end. My advise is to focus on collaboration between designers and developers an keep the work of polishing UX deliverables to the bare minimum. For example, it’s better to start with sketches and then iterate on a white board than spending a whole sprint creating beautiful pixel-perfect wireframes. Wireframes and other UX documents need to be internal communication tools, not final deliverables for a client.

A big advantage of going lean with UX deliverables is that the time your are saving in design artifacts can be applied to user testing. That’s is a great trade-off and one that will pay for itself many times over.

Plan for user testing

User testing is one the biggest benefits you get from having a UX team. Plan for it in an Agile way! Instead of testing at the end (like in waterfall), incorporate user testing throughout your development cycle. Ideally, you should test some portion of your software every sprint. Regardless of having mockups or working software, testing often with real users will not only save you money, but will also ensure that you come out to market with a product that users really want.

As Agile Product Manager (i.e. Product Owner), it’s your responsibility to add user testing to the backlog, and to prioritize it for every sprint. User testing should have stories and tasks plus it should be tracked using burn-out charts, just like any other activity your team does. User testing will be foreign at first, but the more you do it, the more natural it become. Everybody, from developers, to management and specially final users will see the value and benefit from this activity.  In the end everybody wins.

In Summary

I know implementing process is not the most exciting thing in the life of a Product Manager. But in this case, taking the time to understand the different disciplines within your team and working towards a clear integration is an exercise worth doing. In the end, sprints will go down more smoothly and the ultimate winner is your user.