The story of what it's like being a UXer part of a large organisational transformation journey from Waterfall to Agile practices, and the "in-progress" view of the process looks like.
Nell’iperspazio con Rocket: il Framework Web di Rust!
Agile, UX and The Enterprise
1. Agile & The Enterprise
From a UX Perspective
13/03/2015
Presented by: Lexi Thorn & Scott Maywood-Bryant
#agileux15 @ANZ_AU @lexithorn @ScotTheLot
2. Thanks to the awesome speakers
• Ben & Diana – disrupting the disruptor (so meta!), and why agile iterative development
is well suited to a customer centered test and learn approach
• Cameron – agile conversion journey, and overcoming the “cowboys” by not following
agile techniques blindly
• Sophie – we need to go High Definition with our communication, trust needs to be in
the room with distribution
• Ruth & Simon – how not to be dicks to each other – awesome
• Megan – hands on practical advice for conducting diary studies, love the
hand-craftiness too
• Karen – Fadgile -> Wagile -> Radgile and your amaze-gile puns
• Warwick – on setting UXpectations and a framework for measuring the quality of
experience over time
• Jake – the importance of having a Vision, and valuing agility over Agile with a capital A
2
20. Three workshops covered:
Workshop 1 – Product landscape
• Review of Product Strategy and roadmap
• What will make this project a success from a Product point of view?
• What are the best ways of working together?
Workshop 2 – Overarching Vision and Principles
• What do we collectively know about the customer and their needs?
• What is our Vision for the product?
• CX and Content principles
Workshop 3 – Visual Design Principles
• What attributes should our customers use to describe our design?
• How can we articulate the visual design Vision?
• How should the site look and feel to our customers?
We have also revisited previous knowledge gathered e.g. Digital Sales and Marketing analytics,
branch and contact centre visits etc.
20
1.1 Vision: Stakeholder workshops
Goal: Shared understanding of the vision, business context and design challenges
23. 1.1 Vision: We then created a clear brief
Contains:
• Our Vision for the project, and the drivers of success
• Playback of business context gathered to date
• Design challenges:
• They are actionable and meaningful
• I can make design decisions off these
• I can check my design work against these
• …to confirm that I’m heading in the right direction
• We describe what we are aiming to solve rather than how we are solving it
30. 1.3 Concepting & Prototype
30
Q. What’s the output
at this stage?
31. 1.3 Concepting & Prototype: Artefacts
31
Prototypes
Attribute: http://www.paulnobles.com/wp-content/uploads/2011/08/axure-prototype1.png
• Breadth of the system
• Tricky interactions
…deferring detailed design
decisions to the last responsible
moment (within Sprint cycles)
• Interaction framework
• Allows us to estimate
46. 3. Delivery: UX as part of the delivery team
46
IT -1 IT IT +1
2 weeks 2 weeks 2 weeks
Working together with the BA’s
to detail our design ready to
support the development team
throughout the sprint.
Up-front design In-flight design
Working together with the devs
and system test team in the
nuts and bolts of the code,
supporting and making minor
design decisions/tweaks on the
fly as things come to life.
Working together with the UAT
team to make sure the design
meets business acceptance
criteria.
Design acceptance
47. …we could wear one of any three hats in an iteration
IT +1
2 weeks
IT
IT -1
IT +1
2 weeks
IT
IT -1
IT +1
2 weeks
IT
IT -1
49. Moving from a model of solving problems linearly…
49
Attribute: https://farm6.staticflickr.com/5495/9629749173_962f61f5af.jpg
Requirements > Design > Development > Testing
50. …to solving problems as a team
50
https://lh5.googleusercontent.com/-
ZYzhnCG8Gak/Uy24FWTmKEI/AAAAAAAAAFQ/d89KwykVFKA/w654-h654/lego_group.png
55. 4. Supporting elements: Resourcing
• Our CX team are resourced in a way that can work with this process
• People that can do heavy lifting during discovery
• Then have people (1 UX, 1 Designer) that sit alongside the delivery team
55
65. Discussion topics
• Has anyone else got a perspective that they’d like to share?
• Enterprise or other?
• What are the biggest challenges you’ve had to overcome in your Agile projects?
• How does your Iteration 0 planning/discovery process work?
• Do you do one?
• What are the ratios of people in your teams? Product/BA/UX/Visual/FE/BE/Test
• What kinds of research to you do? How do you weave this in?
• How do you manage all of this in “Sprints”
• Do you work, one, two, three or more sprints ahead?
65
Notas do Editor
Thanks!
We’re both part of the Digital Customer Experience team at ANZ based in Melbourne
We have in our team a bunch of highly talented…
User Experience Designers, Visual Designers, UI Prototypers, Researchers and Accessibility Specialists
Our talk today is about Agile and the Enterprise
…as well as the collaborative, cross-functional teams, that make this way of working a success.
…or in real life at ANZ, here we are in our project team
Let’s start by asking Why Agile?
In traditional waterfall, we often “Gold plate” the system so not many features are actually used when we finally get to the end.
Often times when you go through a large project in an enterprise you want to include ALL of the features because usually it’s your ONLY chance to get them into a product (Phase 2 is often something that happens over the rainbow)
One of the best parts about agile is the fact that you get feedback on your work in small incremental phases (rather than in a “big bang” in 6 months time)
This applies to feedback not only from our stakeholders but our customers too – which is why we include research at multiple stages in the process
This is something we really believe in, and helps us to bring everyone (including stakeholders) along on the journey of creating a product
And it’s also awesome working in a great team culture…
Underpinned by cross-functional, collaborative, autonomous teams, working towards a common goal – is where we want to be
Great, so now we’ve discussed the “Why”…
…we’ll look at our “flavour” of agile at ANZ.
This is an “in progress” view as we’re going through this cultural transformation at the moment
So moving on to the outline of our talk today
We wanted to structure this session around the Agile process that we generally follow at ANZ.
1. The first phase being Discovery, where we set the foundation for the project
So that we all have a clear Vision about what we’re trying to achieve
2. Followed by Planning phase (where we break down the work into chunks and prioritise),
3. and then the Delivery phase (where we build and release in iterations)
4. We also wanted to chat a bit about the elements that are really helpful to support this way of working
Such as the workspace, tools, and stuff like that
Let’s deep dive into each of these phases.
Generally two broad things happen in our iteration 0 or Foundation phase –
The first is “Business readiness” - where the goal is to have a shared understanding of the Vision for what are we going to create, and what success looks like for the project.
We also make sure we involve the Accessibility specialists in our team up front
…and from a UX perspective the output of this phase is a prototype which demonstrates the “shape of the thing we’re going to deliver” – we’ll explain more about that a bit later
2. The second is “Technology readiness” – which is getting everything in place in order to build it e.g.
Environments (Development, Test, UAT, Sandbox)
Tooling (Continuous integration e.g. Bamboo)
System architecture
Browser Device OS – what’s our list
Devices – getting the physical devices to test on
While it’s important that the project team is across both, we can use our unique skillsets to divide and conquer and get stuff done.
Looking at this from a UX angle, the 2 key areas we thought would be most interesting to talk about in our Discovery phase are…
1.1 Vision – and what we do in order to create the Vision
1.2 Concpeting and prototype phase – what’s our micro-process within here and what artefacts we create at the end of this process (or what the outputs look like)
To begin with our Vision.
With any “great thing” we build we need to start with a solid foundation.
And in a large enterprise that foundation often starts with People, having a common idea of where we want to head
…because when this comes unstuck or is not aligned that’s when things can start to become a bit wobbly
Generally when a new team is formed on a project we often have different “mental models” of what success looks like (or what we are trying to achieve)
It isn’t too hard to understand why, because people come to the project from different perspectives, and success may mean different things to different people
So we want to try and move from this…where the team has different ideas of success… to…
…to something more like this
Where everyone’s view of success is aligned
and we all have a common (or shared) vision of what we’re going to create
On a recent project that we’ve been working on
we really took the time to get the team together and understand the Business context, Project Vision and priorities – as well as the challenges for design.
We did this through series of workshops (with lots of post it notes of course)
And under these areas we brainstormed and captured everyone’s thoughts and understanding around a set of focus questions (some of them are up there)
Our workshops covered:
Product landscape: Where the Product Owner gave us a great brief on the lay of the land, helping to form context for the project
Overarching Vision and Principles: Where we had a knowledge sharing session about customer research gathered to date, as well as establishing our Vision and Principles
…and then a deep dive into Visual design or aesthetic goals
The other benefits of doing these sessions were:
…it brought everyone in the team together right at the start
Everyone could listen, share and ask questions
…and that ultimately meant we could all share the same view of what success looked like
Stakeholder workshops can be really helpful in unearthing existing insight. We began by gathering and synthesising the research the business has already undertaken.
One of the benefits of being in a larger enterprise is that we have vast amounts of data collected and research undertaken by different parts of the business.
The challenge can be in emerging the insight out of all of that data and determining what is useful and what is not.
It is also during this time that we identified specific questions that still needed answering and we began to plan further research help us do that.
Following these workshops we then synthesised the outputs and documented them in a brief
…good old affinity diagraming (and you can see that happening here in our workspace).
We then created a clear brief which contained a playback of the business context (re-iterating what we understood)
It can be read as a series of design challenges:
Each design challenge was written in a way that followed these guidelines making them actionable and meaningful (see slide)
The more clearly you can articulate the problem, the easier it is to find a solution
The outcome of this process – We all have a common goal and shared vision
It can be easy to underestimate the importance of this part in the process, or just dive straight in and start designing…
But when everyone on the team has the same vision, they are all on the same page for what it takes to succeed.
So now we have a clear Vision / Foundation, we then move on to our process of exploratory design
We start by referencing our Brief and design challenges then go through an:
Exploratory phase = Divergent thinking – explore the problem space. This is often in the form of sketches, rough concepts that answer the design challenges
Refinement phase = Convergent thinking – where we take the strongest ideas and refine them into a prototype
In terms of research
During our divergent thinking phase we often do things like Contextual Inquires
And when we move into refinement we tend to do more tactical 1-on-1 usability testing
…taking a bit of a deeper dive into each:
Upfront research enables us to decide “what is the right design”, by listening to our customers out in the field
Otherwise we often jump straight into research, or bring customer feedback in too late, which happens during the design phase (think traditional usability testing)
So we want to take a step back to properly listen and understand the problem space
This might take a form of contextual inquiry where we’ve gone out into people’s homes and workplaces
This doesn’t have to take a long time, on a recent project we did this in about a week.
It brought home a rich wealth of insight for the team to work from in their first round of design iterations
Based on this insight… and the design challenges we established in our brief
…we do tons of sketches to respond to some of the insights we’ve uncovered during our divergent thinking research
…and as we start to feel as though we’ve exhausted the range of possible ideas, we then find that’s a good place to start refining
…And as we refine, we make sure we get lots of feedback from our customers and stakeholders to do this
We hold these types of sessions regularly
As we we start to refine more and more we then converge the designs, and work them into a prototype
…so what kind of output are we aiming for at this stage?
What are we working towards in our refinement?
At the end of the discovery phase we’d normally have a clickable Axure prototype that communicates the product at a high level
We’re not looking for something highly detailed, we’re looking for something that shows
Breadth of the system: Key user journeys, core pages and modules
Tricky interactions (things we might want to Spike in code at the start to see if they’re going to work)
Framework: How things “fit” together, and how we might scale
Estimating: Allows the developers and testers to estimate their effort
- We’re not trying to solve all of the design problems up front, we can defer some decisions “to the last responsible moment”
From a Visual Design point of view we’ll also create a:
Lightweight style guide
Grid system (particularly important for responsive)
At this point, for design, we’re thinking about those foundation things that might be harder to change later… and things that the Front End developers are really happy about if we’ve thought about them up front.
So the idea is to move from a large detailed upfront design specification to… as needed deliverable documentation
Or you could think of it more like a Foundation or a Interaction Framework for the solution. Think of it like the framework of a house - where you can render in your rooms later on.
…rather than over-designing upfront
Once we’ve completed our discovery phase the next step is to take our Prototype into Planning out our backlog and releases
How do we move from…
…a basic prototype, into user stories that are prioritised and ready for development?
First we look across the prototype we’ve created …then…
Break down the prototype into common components, modules or features
And look at what are all of the building blocks that make up the product (or system)
At this stage we’d work with the Business Analysts to add some acceptance criteria
and we need to provide enough information so they can be estimated by the development team at a high level
Then we begin our estimation with the delivery team:
1 point = 1 good working day (need a baseline to start off) …and then our points become abstracted comparative measurements
Our estimates also include test effort
Now that we have an understanding of size and rough scope…
…we then work with the Product Owner to prioritise our modules in order of build
At this stage it’s so IMPORTANT that everyone has a common understanding of the DETAIL of the backlog AND the priority order before we start delivery
getting the right decision makers in the room is VITAL at this stage.
So moving on to delivery… let’s recap what we’ve got to work with
A great foundation or Vision
Our prototype or framework
Our components or modules
We know our priority of delivery for these
As we move into delivery we start to focus on detailing what we need to support the development team throughout the sprint.
So at this point…
Our lower priority items we model in less detail, because we’re not too worried about those at this stage
BUT we make sure we have “focus” on the items at the top of our backlog, these are the things we model in greater detail, and get ready for build
…but sometimes as you’re designing the options A might be just as good as B, so this is where… (next)
…we can design for OPTIMISATION in mind.
So when we go LIVE we can think about the key things we want to test when we launch, and solve through quantitative analysis.
We’re really lucky because we already have a great Test and Target program that supports this.
Digging deeper into how our UX practice works when it comes to delivery....we have to wear a number of hats.
Prior to an iteration commencing…
This is where we may take a module and do all of the final design / interaction work required, this is our polish. We want to make sure we’ve done everything we can to set the sprint up for success (we’re not changing our minds about design within the sprint)
During an iteration…
We make minor design decisions / tweaks on the fly, together with developers, as things come to life
Post iteration
We make sure the design meets business acceptance criteria, so we can help with this phase too
…but as things really get going and we start delivering we could wear one of any three hats in an iteration – it’s a balancing act
We always try and put our hands up for anything that we can lend a hand to.
After all, we’re a team, working towards a common goal.
To sum up the whole process, we’re really trying to move from a model where we
Solve problems linearly (to)
…to solving problems as a team
We might be a motley crew, but we get it done together
Where we have a highly communicative environment that alleviates the need for work being passed up and down a chain
Let’s have a look at some of the supporting elements that make this way of working a success
Most importantly, working in a team environment, that has a sense of momentum and achievement makes for a great workplace and a happy team
….in an enterprise, great spaces!
We have an open environment where we can bring all of our stakeholders down for our showcases and workshops. It’s a great space for encouraging honest collaborative feedback
We have a workspace that is malleable/reconfigurable
We have lots of wall space
We have pod where we can go for quite huddles
We have comfortable couches
So it’s a really cool space that our team finds comfortable working in and showcasing our work
Resourcing: Our CX team are resourced in a way that can work with this process
as a result is that it has allowed us to work in a truly cross-functional way
The right digital tools are really important
We currently use JIRA and Confluence
…and we put effort in for the the whole team being trained on how to use them
Help to shield team from noise.
Communicate progress up and out to more senior stakeholders if need be. Keep momentum going
Someone embedded in the project team gets to communicate at Governance level so they can clarify any issues
Particularly as you are moving through organisational transition
A great Agile coach that can keep you honest and questioning your process as you go
Probably one of the most important things…
In large environments going through transition we need a culture of support. If you’re a new team going through this transition – be cool, be kind to each-other
Build a culture that supports learning rather than finger pointing
…and have fun
Team culture is so important and not to be underestimated
So we can have happy, collaborative teams…
To create great things.
Questions are our favourite part, so we wanted to leave lots of time for this (or beer?)