Adapting Agile
Summary
User experience has never been adequately addressed in any Agile guidelines. By user experience of course I mean customer experience. By customers I mean those people at the top of our business hierarchy. Seems crazy, right? Luckily enough Agile is a toolkit that we can build upon to maintain innovation and usability as our competitive advantage. Here is how I undertook the task of adapting our Agile work processes at Avid Gaming for our betting product - Sports Interaction, to put the customer first.
What is Agile?
Agile is a mindset of adaptability for software development. It is also a prescribed process for achieving adaptability including task break-down and team autonomy. It has four key values which make up the Agile Manifesto:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
— https://agilemanifesto.org/
The Challenge – Deliver an Innovative, Intuitive Product Using Agile.
We had a competitive advantage in Canada. Our product was the first choice for recreational bettors because it was easy to use. We wanted to build on this by innovating novel ways of betting and further-raising usability standards.
The main goal of Agile is to maximize the likelihood that our teams spend their time doing the right thing. The right thing means focusing on those projects that add the most value to the organisation at any given time.
Agile really makes sense for software that is delivered as a service. A continuously improving service led by customer demands.
Typically, here is how it looks:
For Users, “Working” Software is the Start, Not the Destination
The 2001 Agile Manifesto emphasised “Working Software over Comprehensive Documentation”. This principle was ground-breaking, but was likely rooted in creating in-house software. It didn’t address the integral role that UX design plays in gaining competitive advantage for a customer-facing application like ours.
Agile practitioners proudly distinguish themselves from the traditional “Waterfall” method, using cross-functional teams to avoid throwing work over a wall to the next team. But cross-functional wasn’t quite cross-functional enough.
At Avid Gaming, when a designer sought developer involvement, it typically involved requesting a favour, thus diverting the developer from his or her designated tasks. This led to designers working in isolation, and optimal solutions were consequently being missed.
We needed true collaboration between design and development, and we got that by rethinking our approach to using the Agile framework.
Adapting Agile for the Users’ Benefit
Declaring our product to be user-centric wasn’t enough. We had to walk the walk by integrating UX at every stage of the product process. I created a plan that brought our customers’ experience to the forefront of our efforts.
At our strategy discussions I emphasised to my colleagues in senior leadership that our customers are buying a user experience. UX is not something to add to a product. In our case it WAS the product. And so the seed was sown for a healthy Agile attitude from the top down.
Carrying this mindset into the process here are the things I put in place:
The Power of Purpose – Using Hypotheses
Early and Continuous Developer-Design Collaboration.
Designing Big and Small.
Determining Valuable Software.
1. The Power of Purpose – Using Hypotheses
It seems obvious but I’ll say it anyway – If someone understands why they are doing something then they will do it better and they will be happier doing it.
Teams didn’t need to deep dive into the company strategy each time they worked on a user story. They just needed to answer one question ‘Why am I doing this?”
Adding purpose to tasks proved to be surprisingly easy. We started to include hypotheses, not only in roadmap epic tasks but in smaller parts of those tasks too. A hypothesis boils down to one essential question: “What positive outcome do I anticipate when I make this change?”
Adopting this mindset meant that solutions coming from the teams were appropriate to the problem we were trying to solve; not just solutions to specific issues, but also part of a broader awareness of the larger problem at hand.
2. Early and continuous Developer-Design collaboration.
We wanted to avoid UX Designers finding out late that they have designed something that can’t be built.
This meant veering away from the traditional practice of handing over a full design and expecting developers to bring it to life.
We embraced collaborative design thinking. This collaborative effort ensured that the user experience was considered at every stage of development, and the development opportunities and restrictions were considered at every stage of design.
We built this collaboration formally into the Agile process. While the designer works out steps, flows, layouts, processes, organisation and navigation, the developer can answer questions about what can feasibly be done and suggest workable alternatives.
Here is what our process looked like now:
3. Designing Big and Small.
In Agile, we like to break tasks up into smaller, manageable pieces. For UX, the smallest possible piece for a larger feature is often the user’s workflow. If we design and test something smaller, we run the risk that we’re not solving the big picture of the true user experience.
Good designers don’t merely fix interfaces, they create quality user paths that mean quality user experiences that lead to happy, loyal customers that make a healthy business that attracts more customers.
The challenge was to take all the good parts of Agile – breaking down tasks, launching and learning, but building good design on top of that.
Agile UX was now carried out with two parallel goals:
The product update must fit in with the overall experience of the product.
Any product design must result in a solution which can be built and released in smaller, independent increments. If development stops at any point, the work to date still has value.
We shifted our approach to begin with user journey mapping. This allowed us to visualise the entire user experience and identify potential friction points.
This made it clear how a project should be broken out. Sometimes the MVP would be the skeleton (horizontal) and sometimes it would be a detailed part (vertical). Mapping a user journey skeleton early allowed us to determine the best way to break out a project. Then we could confidently move forward, fleshing out the detail for each piece.
We were designing big and designing small all at once.
4. Determining Valuable Software
“What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?”
Eric Ries, author of The Lean Startup
We knew that just “Working Software” wasn’t enough for our customers but we needed to be clear on how we determined what “Valuable Software” actually was.
Our approach encompassed A/B testing, user observation, and various success metrics such as activity data and bet placements. We also placed a keen focus on feedback from our customer service team. These adaptable methods allowed us to validate our hypotheses and chart the course of our product development journey.
The true magic of hypotheses emerged at this part of the process. We would learn if our anticipated benefits materialised as expected. This was the compass guiding our product development – build on what we had done, change direction or roll back.
One great example of this was when we introduced a feature we called ‘Play-by-Play’ betting. A person could bet on tiny details of a game quickly as the game was in play. We introduced it to a small number of customers. The hypothesis was that they would engage with it during a game and it would add fun to their game by allowing them to place bets throughout. As it turned out though, customers were more interested in betting on standard live betting or before-game betting. Only a very small percentage engaged with it at all. Our hypothesis was incorrect but our process worked. We rolled back and moved on.
Our testing efforts extended beyond isolated elements; we evaluated how changes impacted the entire user journey. For instance, rather than assessing a password selection field in isolation, we gauged its influence on the overall sign-up success rate.
These metrics and observations served as tangible evidence of our renewed commitment to delivering not just working software but truly valuable experiences for our customers.
The Result
These small but powerful adaptations yielded the following outcomes:
Designers worked more knowledgeably, considering broader implications and opportunities.
Developers enjoyed greater autonomy in addressing business problems, minimizing surprises through early involvement.
Business owners and designers were prompted to specify their change objectives, aligning with business goals and strategy.
Collaboration revealed the complementary skills of designers and developers. We had a shared consciousness of what drove the most value for the business.
As a business we were truly customer focused, delivering value to customers, or else not delivering value but learning from that.
Conclusion
The journey of transforming the UX process at Avid Gaming for our Sports Interaction betting application demonstrates the shift of UX from an afterthought to a driving force for commercial success. Our Agile software development process, which once barely considered UX, now embraced it as an integral, driving part of the process.
The Agile framework was built for software development but software development has changed. It is no longer enough to build “Working Software”. “Working Software” is now a pretty low bar. Right now, fulfilling customers’ need for connection and entertainment are what give our business the competitive edge.
By shifting our focus from “working software” to “valuable software”, embracing holistic design thinking, and prioritising quality user paths, we successfully blended UX with Agile, resulting in a product to delight, engage and build lasting relationships with our customers.
Adopting a lean mindset to question our processes, even our beloved Agile will allow us to keep customers happy and our business growing.