Agile, UX and The Enterprise

Editor's Notes

• #3: Thanks!
• #4: 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
• #5: Our talk today is about Agile and the Enterprise
• #6: …as well as the collaborative, cross-functional teams, that make this way of working a success.
• #7: …or in real life at ANZ, here we are in our project team
• #8: Let’s start by asking Why Agile?
• #10: 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)
• #11: 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
• #12: 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
• #13: 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
• #14: 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.
• #15: 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.
• #16: 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)
• #17: 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
• #18: 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…
• #19: …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
• #21: 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
• #22: 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.
• #23: 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).
• #24: 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
• #25: 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.
• #26: So now we have a clear Vision / Foundation, we then move on to our process of exploratory design
• #27: 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
• #28: …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
• #29: 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
• #30: …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
• #31: …so what kind of output are we aiming for at this stage? What are we working towards in our refinement?
• #32: 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”
• #33: 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.
• #34: So the idea is to move from a large detailed upfront design specification to… as needed deliverable documentation
• #35: 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.
• #36: …rather than over-designing upfront
• #37: Once we’ve completed our discovery phase the next step is to take our Prototype into Planning out our backlog and releases
• #38: How do we move from…
• #39: …a basic prototype, into user stories that are prioritised and ready for development?
• #40: 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)
• #41: 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
• #42: 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
• #43: 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.
• #44: 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
• #45: 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)
• #46: …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.
• #47: 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
• #48: …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
• #49: 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.
• #50: To sum up the whole process, we’re really trying to move from a model where we Solve problems linearly (to)
• #51: …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
• #52: Let’s have a look at some of the supporting elements that make this way of working a success
• #54: Most importantly, working in a team environment, that has a sense of momentum and achievement makes for a great workplace and a happy team 
• #55: ….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
• #56: 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
• #57: 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
• #58: Help to shield team from noise. Communicate progress up and out to more senior stakeholders if need be. Keep momentum going
• #59: Someone embedded in the project team gets to communicate at Governance level so they can clarify any issues
• #60: Particularly as you are moving through organisational transition A great Agile coach that can keep you honest and questioning your process as you go
• #61: 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
• #62: …and have fun Team culture is so important and not to be underestimated So we can have happy, collaborative teams…
• #63: To create great things.
• #65: Questions are our favourite part, so we wanted to leave lots of time for this (or beer?)