Adopting an Agile Culture
Download session PDF
Add to calendarSuccess in adopting an Agile culture depends on the team’s ability to adapt, while establishing common objectives/principles across the team. This case-study observes this theme via the lens of a project team at Liquidnet. The project’s concept was actually originated by the UX team. Eventually, with an interdisciplinary team of 30, the vision became a reality. It wasn’t until a major change in scope occurred when Liquidnet decided to bring an agile coach to facilitate process change. This experience report documents the team’s experience integrating the Agile culture into their very own.
Case study presentation – slide format: 40 min
• Brief description of the company - Liquidnet is electronic marketplace that facilitates institutional equities trading for asset management firms worldwide that brings buyers and sellers together and enables them to anonymously trade…
• Brief description of project and breakdown of team - The objective of the project is to implement an electronic trading application, designed with a specific interest to expand the company’s core business offering. The team of ~30 consists of UX designers, front-end and back-end developers, business analysts, QA testers, as well as a product manager/project leads in various capacities…
• Process from beginning to current (challenges and successes) - (This documents the initial research phase of the project to the current state. The timeframe covers a span of 3 years, focusing heavily on the induction of the Agile process onward)
• Learning Outcomes (see below)
Q&A: 5 min
- Breaking the waterfall paradigm - prepare for changes in role as product matures (owner of specifications to design facilitator). Rely on tools such as UI pattern libraries, scenarios, and personas:
- Prior to assembling and beginning the implementation of the project, the UX team presented the concept as an entire framework with an end-to-end scenario as its scope. This framework was actually instrumental in creating a milestone plan. Everything was running smoothly until a major change in scope occurred due to business decisions. That’s when Agile was introduced to the company in order to deal with the restructuring that needed to happen. This change in process brought up some major challenges for the UX team, who was used to designing up front and presenting flushed out specifications prior to implementation. The challenge became more evident as the build’s architecture became more complex. The system could not support what was presented in the specs. The UX team needed to step back and shifted the “waterfall” paradigm of spec delivery towards a more collaborative and flexible approach. We played the roles of facilitators, expending more effort on identifying the problem space and drove the feature team design sessions using scenarios and personas to generate solutions that served the needs of developing and testing.
- Process change needs to happen iteratively, yet the project team has to account for time to adapt to the transition and that business objectives are not compromised:
- It’s important that the team reviews the work after every sprint and engages in retrospectives (capturing what was done well, challenges across the team) accordingly to assure that best practices are kept up to date. There are, however, trade-offs with evolving the process to work in parallel to sprint cycles. For example, in order to satisfy the need to create deeper focus on implementing certain features, our project team suggested breaking into “feature teams”. While the idea seemed to address the problem, it also caused an unexpected silo effect and in some cases spread certain individual’s time thinly across the project team. This in turn led to a decrease in the next sprint’s velocity. Luckily the team was able to identify these issues early on and we were able to take small steps to adapt to feature teams in subsequent sprints. We learned that change needs to happen incrementally and that we need to understand its longer term effects.
- User experience is not just a practice or discipline within the project – it should be a way of thinking across the team:
- Satisfying the needs of the customer is what our product aims to accomplish. This common understanding across the team has contributed to the success of the project. This was essential in collaborative design sessions, communicating ideas, and supporting sprint work. Maintaining confidence that our product really is establishing customer satisfaction, the UX team along with business leads has also managed to gather concrete evidence by conducting product validation in incremental stages, taking the build to customers and delivering the feedback to the rest of the team.
- User experience is integrated into the overall business strategy:
- Because UX is part of the business strategy, it needs to be aligned with the product owner team. In turn, the UX team needs to understand business objectives and should be able to compromise UX objectives. This has enabled the team to agree on prioritization tactics and success metrics. i.e. “this feature is a delighter – it’s better than what’s currently out there in the market and therefore we want to expend the effort to create the most desirable experience possible”. There are also challenges in being cognizant of volatile business scope changes. There are a few accounts when the design of the product had to undergo heavy and quick facelifts in order to satisfy the changes in scope.
- Note: Further description on the team breakdown, collaboration with our Agile coach, and how the agile process evolved can be found in the process portion of the paper.
