In our last post we talked about GOOBing (Getting out of the building) with your data. In this post, we explore what Lean and Agile UX methodologies can teach us about working together.

One of the biggest challenges people face when trying to execute data projects is navigating departmental, organizational and team silos. This problem is more common than we think, and spans organizations and industries.

For a long time in the tech sector, project owners, designers and developers would work with a waterfall model. This involved a very linear and hand-off process. Each individual was responsible for one step without really understanding the impact of their work on the overall project. (This model was adopted from construction and manufacturing, and is still used in many industries today.)

The waterfall model often resulted in very costly projects. Project owners and designers couldn’t see flaws until the project was finished. This meant more design and development would then be needed. The process also required stakeholders to write extensive instructions. These would be passed on to the stakeholder in the next phase – a very time consuming task, as you can imagine.

Then came Agile and Lean User Experience methodologies. While one stems from the development side of tech and the other from design, both embrace similar values and principles that focus on:

• People (instead of documentation and processes)
• Collaboration throughout teams and different roles (breaking down silos)

Working collaboratively (or tearing down the data silos)

Lean and Agile UX methodologies have encouraged close collaboration between designers, developers, business execs and product owners. This ensures that a project evolves in alignment with everyone’s goals. It also reduces time and wasted resources, while increasing the project’s likelihood of success.

Remember, people should be at the centre of your process. You shouldn’t be spending more time documenting your efforts than actually working with your team. Otherwise you’re doing something wrong.

It all starts with building the right team. Select people with different backgrounds and various perspectives from within the organization – otherwise you may overlook important aspects. Someone who works on the floor will bring a very different perspective than someone at the exec level, and vice versa. Your team benefits from having both because you need buy-in from all levels of your organization.

Also consider bringing someone from outside of your organization to be part of your team (either a third party consultant or the identified stakeholder/audience of your data project). If this is not possible, designate someone on your team as your audience champion. They will be responsible for reporting on your GOOB activities and should challenge any assumptions you are making.

Less friction and better project outcomes

Our clients have told us that navigating the silo culture within their organization is one of the greatest problems they face in working with data. Teams and departments have difficulty accessing and sharing data with each other. Corporate policies cause friction and delays in making the data available. They also create overly protective data gatekeepers. Inexperience and unknowns nourish fears that lead to ineffective data projects or inaction.

Ultimately, data project goals should align with the organization’s business and strategic goals. Resources and knowledge should be shared across teams. The outcomes of data projects should also be shared in order to benefit everyone.

This doesn’t mean everyone should be involved at every step of the project. But it does mean that everyone should be considered at some point (ideally at the beginning). Remember, people benefit from knowing the project’s progress.

So next time your organization is planning a data project, take the time to set up a team with a range of invested stakeholders. It could mean the difference between a successful project and one that gets tangled up in organizational politics or red tape.