Your SlideShare is downloading. ×
How we integrate UX and design in to Scrum - Transcript
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

How we integrate UX and design in to Scrum - Transcript


Published on

Published in: Design

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. 1(slide 1)How We Integrate UX and Design into Agile(slide 2)Just a little bit about me first.My name is Gavin Coughlan. I have been working at Boost New Media for the last 6years, initially as a frontend developer, after which I moved in to project management.Boost adopted Scrum about three years ago, and I started the transition from projectmanager to Scrum Master at the same time, a path I’m sure a lot of you have taken. AtBoost no longer works outside of Scrum at all, it is written in to all our proposals now,and I guess have no need to go in to the benefits we have seen at Boost.I now run several Scrum workshops for free at Boost to help spread the good word, aswell as facilitate our monthly Scrum lunch, or Scrunch, where we invite Scrumpractitioners around Wellington to discuss any issues or successes we are having. Ithas attracted a wide array of people from various industries so far, and is a great way toinformally meet other people going through the same things as yourself. I also getritually abused and man the mixing desk of our fortnightly Agile TV show, The Board.So my talk today will be about UX and design within Scrum, and it will be very muchfrom a Scrum Masters point of view.I’ll quickly run through what points I’ll be talking about today(slide 3)• Why the waterfall approach fails• Some existing approaches to UX in Scrum• Our initial approach to Agile design• Our current approach to agile design• What we will be doing in the futureWe will have time after the presentation for questions where I’ll be joined by SeanLipidis, one of the designers at Boost, so we will be able to answer anything you askfrom a couple of different perspectives.I want to start by getting in to why I’m even here. Why is UX and Design in Scrum evena topic we feel the need to discuss? The origin of Scrum lies in software engineering,there was a need to change the way we worked to adapt to change quicker, so itobviously concentrates on development practises, but UX and design is trickier to breakdown in to smaller increments. Upfront designs have been the norm for so many years
  • 2. 2that people find it hard to imagine a different approach, and there has been a lot ofresistance in the design world to Scrum. But there was resistance in the softwareengineering world at the start too, and it’s up to us to change that. It can work, in fact, itnot only works, but in my opinion is a much more logical approach to UX design.Hopefully by the end of today’s presentation you’ll see why.The first thing I want to go through is how Boost worked when I first joined back in 2006,the waterfall approach.(slide 4)I won’t go in to the pitfalls of the waterfall process as a whole, just how it fails when itcomes to design and UX. And the reason I am mentioning this at all is to illustrate howfar we have come, and how some approaches to UX design in Scrum are really quitesimilar to waterfall.On each project we would undertake a large discovery phase where we would try to getan understanding of everything the client wanted, from full functionality to a completelook and feel. Moodboards would be produced and pixel perfect wireframes would gothrough many iterations until we were happy to move of to a full site design.This would involve many rounds of visual design, an often painful process where clientscouldn’t divorce themselves from the idea that what they saw at this stage had to be thefinal product. There was a huge amount of back and forth as each and every elementthat that made up a site was perfected. During this process there was also a hell of a lotof waste which costed both sides money.Once we had a design, it was set in stone. But sites aren’t buildings meant to last manyyears in their initial form. In fact, a site built that way is a failure in design. They shouldbe modified and improved continuously over time. In the waterfall process the design isfinished before development even begins, and if the needs of the site change, as theyalways will, all the design hours have been used up in the initial phase of the processand can’t be revisited.I’m going to touch on a couple of the the current approaches to UX in Scrum that weavoided as they seemed doomed to failure from the outset.The first is doing a big upfront design.(slide 5)Big upfront design is when all the design is completed at the start of a project, once thedesign is nailed down development can start, and the team can start their sprints. Thisis basically no different then using the waterfall approach, it isn’t agile and it promoteswaste. Designers can’t see any potential issues without first seeing some
  • 3. 3implementation, and assumptions are made about what is needed and may neveractually be required.The second approach is skinning.(slide 6)This is where you see the developers implement all the features and the design isbrought in at the end of the project to apply the design. Again Boost avoided thisapproach as it means that there is a lot of rework involved as the UX is fixed.Developers are not usually experts in UX, so this is not a priority as the design-free siteis built. So a designer has to work backwards and fix the issues that will definitely arise,which also leads to a lack of consistency interactions.And if a designer is brought in at the end, how do they make the best decisions? Theyhave not been involved up to this point and aren’t intimate with the site.Another issue we could see here is the development period eating in to the budget. ifyou tell a designer they will have 50 hours of design time on a project, but when itcomes time for them to jump on board there is only 20 hours left, the quality is going tosuffer pretty drastically.We didn’t take either of these approached when we started using Scrum. When we firststarted, we applied the washing machine approach.(slide 7)The washing machine approach involves wireframing and designing a sprint ahead oftime. You start with a sprint 0 and do all the UX design work for sprint 1, and in sprint 1you do all the UX design work for sprint 2, and so on throughout the project. Usertesting is done as much as possible and the UX is revised as needed. Stories will havetasks for UX and design, and often the these tasks are separated out and worked onwell in advance of developmentWe used this particular approach when we began the DigitalNZ project.(slide 8)Digital New Zealand is a project led by the National Library, and it aims to make NewZealand’s digital content easy to find, share and use. This includes content fromgovernment departments, publicly funded and private organisations and communitygroups in the culture and heritage sector.We worked closely with DigitalNZ to create wireframes and design a sprint ahead,essentially a sprint 0. We user tested as much as we could in the time allowed until the
  • 4. 4UX was good enough to start development, with the intention of refining as the projectprogressed.Once we got in to the sprints proper we kept doing design and UX a sprint in advance,splitting the design out from future stories occassionally so we could work on it ahead oftime.We were finally able to minimise the amount of rework and waste associated with awaterfall approach, and the design and UX was fully integrated in to the process, whichin turn lowered the cost of any necessary amendments.But there were still downsides associated with this approach. We still had to revisitearlier designs as more features were added in order to keep it coherent and consistent.Also, the designers felt that they were not allowed to consider the site as a whole whendesigning it, and the staggered approach frustrated them. And a frustrated designer isnot going to be producing there best work. And it’s not all that agile, as we are notvaluing the people over the process this way.And finally, we never felt that a Sprint 0 was ideal for us. We never thought thisdelivered value, something we wanted to do from the very beginning of the project.Sprint 0 often seemed to just become a time for documenting requirements and creatingwireframes and design upfront, again, not very agile. We wanted to integrate theseelements in to the stories so that we could deliver small increments of value, andreleasable features, from sprint one.So that takes us to the approach we use today, which isn’t to say this is the approachwe will be using tomorrow. We are constantly looking to refine and improve our designprocess. Boost has had many conversations and meetings to seek out better ways ofintegrating design in to the Scrum process, some productive and some heated.We don’t claim to have the silver bullet, and whilst our current approach has it’schallenges, it is the best process we have discovered.We’ll use The National Library website as an example to help illustrate how we dothings at Boost.(slide 9)The National Library beta website launched in October 2011 for public feedback andhas since replaced the Library’s corporate website, as well as a number of its separateand siloed collection databases.In the past we had produced hi-fidelity wireframes to outline all the functionality and UXof a site. We produced these wireframes with a variety of tools and printed them out so
  • 5. 5we could go through them with clients. This again led to time being used up that didn’thave to be.So we needed to adjust how we worked, and we used the concept of hi-fidelitywireframes as a starting point to do so.(slide 10)We created a simple, usable design that was very modular. Rather then concentrate onany real design elements, the designer was focussed on the UX during this phase. Thedesigns were built directly in HTML and CSS by the designer, and effectively becameworking, usable high fidelity wireframes. This dramatically improved the workflowbetween the designer and the developer, as they were both working on the samefeatures at the same time, with feedback being passed back and forth with an efficiencythat wasn’t possible before.The designs followed a set of simple rules which enabled the developers to implementfeatures. Because this design was so modular it could be tweaked as we went by thedesigner as they saw fit.One thing that is worth pointing out is that the product owner had very limited input intothe design at this stage. This ensured that the process was kept as lightweight aspossible.We were able to do this due to the long history we had working together. There was ahigh degree of trust there, and of course trust needs to be earned. We are using thisprocess on other projects now, and luckily we also have earned trust with these otherclients as well. We realise that this would be much more difficult to utilise with a newclient.Clients traditionally expect a full design and wireframes outlining the UX in advance ofthe build. Many even expect this during the proposal process. This is the way that it hasalways been done but of course that doesn’t mean the old way works or should becontinued to be followed. Convincing new clients that they will achieve more value morequickly this way is a challenge, and it will be for some time.Anyway, back to the National Library beta.(slide 11, 12, 13, 14)As mentioned before, the initial design was implemented immediately and a separateGit repository was setup for the designer. This was used to manage and share theHTML and CSS. Whenever possible the designer provided the HTML and CSS for theimplemented design, correcting semantic or accessibility issues as he worked.
  • 6. 6UX testing was undertaken from day one. This largely took the form of interviews withpeople from the user group. As soon as we had results from this testing, they werepresented back to the whole team.If we were unsure about the best approach for a particular feature in terms of the UX,we would choose the option we felt worked best and implement it. We could then testhow this work - this was a good way to cut down on the time it takes second guessingthe best option and what may be the best experience for the user.We were very aware of the pitfalls of leaving the design until late in a project, aspreviously mentioned, so we established a rough timeline for the main design. Fromthere we could plan backwards from the required launch date to establish when in theproject we should start the full design.Because the interim design was so lightweight and modular, we could easily fit anydesign needed for new functionality into the designers workflow while he was alsoworking on the full site design. The UX was constantly revised as new features wereadded.At this stage, the designer now had an intimate knowledge of the project as a whole,especially the audience. This made the design process a lot more fluid, and the designwas much more informed then if we had produced it all before any development hadbegun.We started with a reverse brief to the client which took into account the feedback on theinterim design. The designer had a wishlist of ideas for UX refactoring to implementwhen doing the full design, which were presented to the product owner. At that stagethe designer and product owner worked together to prioritise these ideas.The next step was to create moodboards so that the client could provide some focussedfeedback.(slide 15, 16, 17)We create the moodboards to take the client through some ideas for colours, fonts andvarious design elements across the site such as button types and navigation styles. Theclient picks out the bits they like and don’t like, and we feed this information in to the fulldesign. It’s an invaluable process that we use on all our projects.The initial design was then produced and presented to the client.(slide 18)This only went through one minor revision and was accepted. Due to the constantinvolvement of the designer throughout the project, alongside the client, the back andforth when it comes to producing a design has been drastically reduced.
  • 7. 7Once we had an accepted design, the designer then iterated it out through all of theexisting functionality across the site.(slide 19, 20, 21)Due to the fact that we already had the HTML and CSS in place, and the workflowwithin the team fine tuned, the process of implementing the design was relativelystraightforward.On top of that, there was no need for wireframes at this stage as we had a working site,which removed a dependency for the designer that enabled the work to proceed as fastas possible.In summary the key benefits were:(slide 22)• Workflows established and optimised early• Simple initial design reduces cost of adding new features and revisiting design• Have a potentially shippable product at all times• Designer had a great deal of intimacy with the client and the project when creating the final design• Able to design the site as a whole rather than piecemeal, which contributed to a high level of design polish which has in the past been difficult with agile projectsChallenges included:(slide 23)• Users became quite attached to the interim design• Required a very high level of trust with the client• Required and a true team approach• Wireframes could still be a bottle-neck during development as it took time to explore different UX optionsI’d also like to quickly talk about a process we used with a new client on a short project.(slide 24)NZonScreen is the online showcase of New Zeland television and music video, withover 2,000 titles available to watch on their site for free. they came to us with a basicbrief, they wanted an iPhone app, Reel Choice, which played the latest releases fromthe NZonScreen website.
  • 8. 8We did have to create concepts for the app as they needed to show these to get fundingfor the project.(slide 25)These concepts acted as wireframes for the project. We did no design upfront, andeven though this was a new client, we were able to begin development immediatelybefore any designs were seen. We were able to do this largely because the client wasvery keen to work in an Agile way, in fact they didn’t want to work any other way, sothey trusted the process.We had four weeks to complete the app, we started doing one week sprints, but aftersprint one the team decided during a retrospective that two week sprints would beprefereable so that they could have more to show at the reviews.Much like the National Library project, the developer and the designer worked togethervery closely. In this case they actually sat beside each other, and were committed 100%to the project. The communication between them was constant, and both had an equalunderstanding of what they were trying to achieve at all times.When the client saw each iteration at the reviews, they saw both the functionality andthe design for the first time simultaneously. This allowed us to get the app completed ina short timeframe, and due to the interaction between designger and devloper, thequality did not have to sufer as a result.And finally, what Boost will be doing in the future.(slide 28)We are continuing to inspect and adapt our process and have some ideas to helpsmooth out some of the pain points.• Get a good headstart on the UX• Reduce the time to complete wireframing• Team design studios - bring the whole team together for a wire framing session for each new feature• Improve workflow between developer and designersSo thats the presentation, I will be posting this on the Boost blog tomorrow, thank youvery much for listening.We have some time for questions now, where I’ll be joined by a Boost designer, SeanLipidis.(slide 29)