3. Culture is not about what is absolute, real, or true. it’s about what a group of people get together and agree to believe. Culture can be healthy or toxic, nurturing or murderous. Culture is made of stories... —Thom Hartmann, author
8. Your Goals workflow in relation to web design/visual design a list (or "toolbox") of UX design methods adjusted for Agile, that can be used based on specific project needs (e.g., RITE testing, paired design/development, Design Studio, Story Mapping, etc.) More detail on Design Studio (a la Jim Ungar) and Story Mapping (a la Jeff Patton), and when they should take place? I attended the Bentley Usability Bootcamp in 2006. How out of date am I in my UCD approach? How can Agile work with 3 types of projects: Design from scratch, open source and implement commercial, off-the-shelf products? staggering design and code tasks architecture and design done piecemeal adding to a legacy application design controls artifacts for the fda and agile
42. Agile Manifesto 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 & interactions Working software Customer collaboration Responding to change Processes & tools Comprehensive doc Contract negotiation Following a plan over That is, while there is value in the items on the right, we value the items on the left more.
44. Principles Behind Agile Our highest priority is to satisfy the customer through early and continuous deliveryof valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
45. Principles Behind Agile Deliverworking software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project.
46. Principles Behind Agile Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
47. Principles Behind Agile Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
48. Principles Behind Agile Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential.
49. Principles Behind Agile The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
78. A lot of potential Real feedback faster Closer ties to stakeholders and developers Faster, less effort on low importance features Pervasive understanding of UX Real User focus Less waste, decide as late as responsible
85. Sample Goals Define problem/benefit Prioritized and measurable goals Contractual obligations Target users and their goals Key assumptions that need to be validated by research Relationship of users to business goals User tasks or scenarios Refined, estimated, and prioritized stories Release roadmap
90. User Stories As a (persona) , I would like to (action) , so that (value) .
91.
92. Photo by David Paul Ohmer http://www.flickr.com/photos/the-o/
93.
94. example As a gardener, I want a shovel so that I can dig a hole As a gardener, I want to dig a hole so that I can plant a tree As a gardener, I want to plant a tree so I can have some shade.
While I’m confident that there is plenty of doubt and frustrationI believe each one of you has some confidence, or at least some hope,That this can work
Agile, like adopting UX practices is a cultural shift, and while hard to do, you can change culture
you have a basic understanding of what agile meansWe’re going to cram the core concepts into your brainI will go through the origins of agile, the manifesto, scrum and some additional conceptsExperience designing in an agile way.
2. I want you to come away with not only a new way thinking, a way of understanding what it means to be agileyou’re able to take the basic concepts, see how they fit together, and maybe how you could use themThere is no magic UX tool list that will make you agile, Can’t tweak a few things and all of a sudden be agile.Good news is you will use a lot of what you already know.
But also the confidence to engage in conversations on how you can apply agile to your current situationUX is too important to agile to let our role be dictated by someone else. I want you to feel prepared to collaborate with your teams to determine how you fit in
Have reasonable expectations. Won’t get to everything. I’m going to try and cram 6 weeks worth of activity into 4 hours. We can’t cover everything.
Name, role, something about you and agile, fun outside of work & some detail about it
3 teams, any of you work together now or in the past?
3 teams, any of you work together now or in the past?
Whole marshmallow must be on topCan break or cut any other materialsFree standing
Come get your materials
Reactions?
Business school grads?
Kindergarten grads
10 minutes
10 minutes
If you’re not working in an agile environment, chances are you will be, soonWhen that happens, you can be part of the process, or let others define it for youBut what does it meant to be agile?I have come across very different ideasAnd what this term means to you can have a big impact on your likelihood of success
The beginning of wisdom is a definition of termsBut when it comes to agile, I think the more relevant quote
Is from Inigo MontoyaYou keep using that word, I do not think it means what you think it means
The good thing is that agile is like Othello
There are three things that I hope you take away from this presentation
While it is easy to learn the basics,It can be very challenging to implement successfullyAdopting agile is a cultural shift. It’s more than what you do, or how you do itIt’s how you think and learn
* Changes hit the real world fasterYou get real input more oftenShorter feedback cyclesIterations based on real dataYou can react much more quickly when releases are possible every 2-4 weeksAnd that is part of the normal flow of work, not an exceptionSince everything is not defined upfront, success relies on tight collaboration between everyoneFrom stakeholder, designer, developer, marketer, etc.* You are given the vision, the team figures out how to deliver.These are just some of the benefits. I’m sure you’ll pick out more as we go.
Worked in UX for 15 years, Agile for almost 5
Now,I’ve always been a process personBut I’ve never followed that ‘perfect’ processIt’s not that I didn’t want to----- Meeting Notes (5/23/11 16:43) -----stay on this longer through next bit
I’ve read books and worked in many places that each had their own methodologyThey were all pretty much the same. What most distinguished them was the number of D’sThat was ok. It makes sense. But I never worked on a project that followed the ideal process laid down in the book or sales pitchThere were always real world constraints that had an impact
Every project was about understanding the project constraintsthe tools at our disposalAnd figuring out which ones to use and how to put them together
to solve the problem presented by our clients(internal or external)That was interesting to me, And even though we were solving problems and making clients happy,it always felt like we were making exceptions, compromising on an integral wholeIn agile, that flexibility is built in.
Isn’t that liberating? Freedom!But there is another side to it
As you will see, agile and its related methodologies are very loose frameworksYou still have to fill them with the right processes and tools that make sense for your work
In February of 2001, reps from different ‘lightweight’ methodologies met to find common groundSome might be familiar (scrum, crystal, xp)Each methodology was a reaction to waterfall, a lightweight software dev methodThe reps of each methodology all felt like they were more successful than traditional modelsThis group wasn’t coming together to create something new, But to find common underpinnings that made them successfulThe outcome was the agile manifestoOne thing many don’t realize is that these methodologies existed before agile
This is agile. 4 values & 12 principles. Now I’m going to a do a bit of reading here, because I think it is important, so please bear with me
One common reaction is, “woohoo, no documentation!”That is the wrong conclusion. Doc can be very valuable, but extensive doc is likely unnecessaryThat last statement is very importantWhile there is value in the items on the right, We value the items on the left moreIts not all or nothing, its about an intentional application of effort
That was the 4 valuesNext, I’ll briefly go through the 12 principlesAs you’ll see, these refine and expand on the values
No designers involved. FuglyThat is the heart of agile.These principles are refinements to the values, but they still don’t tell us what to do
Agile isn’t about what to do, it’s about how to think about what you do.
That brings us to scrum. What is scrum?
Not something you need to scrum off of your tubOne of the most common frameworks that supports the agile values and principlesThere are certainly others, like I mentioned before, but scrum is currently the most popular
When Jeff Sutherland created the scrum process in 1993, he borrowed the term "scrum" from an analogy put forth in a 1986 studypublished in the Harvard Business Review. In that study, the authors compare high-performing, cross-functional teams to the scrum formation used by Rugby teams.
Like agile, scrum is fairly minimalThere are a lot of practices that people have found useful over the years that have gotten attached to scrumWhich can make adoption seem dauntingBut I think it is important to distinguish the essence of scrum from these add-ons
PO: Responsible for the business value, defining projects, goals, requirements, etcTeam: Self organizes to get the work done. Work not assigned, they decide what they will do and how they will do it, based on prod backlogSM: Keeps the team productive. Not mgr, but a facilitator, problem solver, obstacle removerVery important, can make or break the teamSH: 4th role – connected to the PO. Many of them feed PO requests. PO has to manage them
I don’t like this, but since you’ll encounter it. Here is the origin.Based on this comicPigs are the team, they are committed to delivering. Chickens are stakeholders. Have an interest, but not on the hook.In scrum, some things are for pigs only, and some allow chickens to participateThe idea is to protect the team from too much outside direction, allow them to self-organize without outside pressureCan be a bit rigid, and not flattering. Who wants to be a pig or a chicken?
Here’s how it works. First, the PO creates a backlog (the first artifact)A backlog is just a prioritized list of desired outcomes or features.Imagine taking a spec and breaking out each major element and prioritizing them Often written as stories, more on that later----- Meeting Notes (5/20/11 16:51) -----hard to read----- Meeting Notes (5/23/11 16:43) -----nix numbers
1st ritualWork is broken down into fixed time boxes called sprints or iterationsTypically 2-4 weeksPrefer iterations, Principle of sustainability---during planning, the product owner reviews items in the prioritized backlog and the team commits to the work they will deliver by the end of the iterationThis is the iteration backlog (2nd artifact)Sometimes will also break big chunks into smaller pieces to make them more manageable
During the iteration, no one is allowed to change the iteration backlogThis allows the the team to work uninterrupted for that period of timePO can manipulate the backlog all he or she wantsTo adjust priorities of what will be done in the next sprintLeave the team alone to do the work they committed toReplace things of like sizesIn extreme cases, can cancel the whole sprint
2nd ritualEach day, the team meets to share status and struggles with each otherThe goal is to create awareness and facilitate collaborative problem solvingTypically done standing (and referred to as stand-ups) as a reminder to keep it short, 5-15 minutes
The team does not solve any issues during the daily scrum, The goal is to raise them and only involve those necessary.It is common for the right people to meet right after scrum to address issues.Interesting note: Status is given to the team, not reported to the PO or SMFor the benefit of the team, not reporting to a higher authority
One thing that is often reviewed during the daily scrum is the burndown chart3rd ArtifactAt a glance view of the work remaining in the iteration (or project)Typically measured in hours remaining on tasks,But can also track story points(more on that later)Gives the team an idea of whether they are on track or not
3rd ritualAt the end of the iteration, team demos the work done for the PO and any stakeholders(hopefully more stable that this, but equally impressive)Work done should be ‘potentially shippable’ so PO/Stakeholders could decide to releaseIf there is enough value in itDon’t have to218,792
4th ritualTeam meets,Celebrates their successes,and looks for ways to improve the product and their processIt’s not just about improving things that went badly.Good things may have room for improvement as wellThis is why we often talk about pluses and delta’s rather than minusesSomething that can be improved is not necessarily a negativeCritical to identify specific actions that the team will take towards improvement
doing the same thing over and over and expecting different results.Sometimes just raising issues is enough, But better to have specific actions that specific individuals will takeImprovements and recs can happen at any timeDon’t need to wait until the end of the sprint
And the whole thing starts again.One of the advantages is that the team focuses on the most important workThings that are less important don’t get done.When releases happen every 6mos or longer…Let me summarize.
Three levels of reflection and adaptationThat’s scrum. As you can see, it is also a very loose structureThere is plenty of space for the team to determine how to get their work done----- Meeting Notes (5/20/11 16:51) -----show title laterput in eyes & nose----- Meeting Notes (5/23/11 16:43) -----better transitionadd snowman effects
A lot of blame gets put on scrum when new attempts fail
Adopting a new process and a new way of thinking is hard It will take some time to adaptAnd it will initially have a negative impactAs the team learns and gets better, it will improve,Don’t underestimate the initial challengeThe better the team understands the V&Ps, the better the chance of a steep curve
What do you do when you want to try a new recipe?Some people will improve right away
It might be great, but you’re increasing your chances that it will turn out badly.Even though scrum and XP and others are fairly light, it helps to try the recipe a few times until you get it right before doing too much experimentationOr, if you’re going to adopt practices piecemeal, keep the values and principles in mind and be ready to adapt and adjust quickly and often
Sometimes Scrum doesn’t fitHighly regulated, need to know upfrontMay not be the right approach**design controls artifacts for the fda and agileMay want to speak with an expert, post to community
To get a sense of what it is like designing in a scrum environment, we’re going to work together on a project
To get a sense of what it is like designing in a scrum environment, we’re going to work together on a projectNew medical toolPatients can go online to schedule appointments and communicate with their docsDuring the visit, the doc sends prescriptions to the pharmacistPharmacist has access to all medical records, checks for interactionsPatient gets reminders about drugs and has access to all of their records
What do you need before you start design? Break up into your teamsNot activities, focus on knowledgeCome up with as many goals as you can, and then prioritize themAssign roles, scrum master, product owner
Not important that our lists matchDifferent projects will have different needsnew vs. existing, etc.Important to be intentional
How do we know we’re done? What are our goals?
Brainstorm some goals for your part of the project
Who are we doing this for?Research is great, but lets start with what we knowColleague thought ~80%. Rest is valuable, but this is a lot to go on.Go ahead and define your personas, less important to be right than to agree right now.Note KEY assumptions, candidates for researchAnother 10 minutes
Not thisA way of loosely capturing requirementsNot requirements themselves, but reminders for conversationsThe details live within the memory of the team
Some add a persona prefixAndy Active Trader says, “I want to…”
Some stories are very high level, often referred to as epics
Some stories are very high level, often referred to as epics
To the very detailed
The understanding of the value can change the understanding of the needHow would it change if the user was a city planner instead of a gardener?
Take the big epic
And you break it down into smaller pieces
Until you have small bits of functionality that can be developedDon’t need to break down everything, only the most important onesThe rest can wait until they get closer to the top of the backlog
Independent – can be done in any orderNegotiable – not a contract, value that can be expressed different waysVal & est gives ROI. Can’t est? consider splittingSmall – depends on the team and iteration length, but manageableTestable – how will I know when I’ve done that?
Write as many stories as you canDon’t worry if they are to epic or to detailedFastest way to do it is to have everyone writing at the same time, dedupe later
Group related storiesremove redundant storiesRewrite, if you’d likeThen name the groupsIf possible, try and arrange as sequential an order as possible---Release planning
10 minutes
10 minutes
Each team run us through what you have so farMay inspire each other to add stories to your map or reprioritize
What has your team done well, What can you improve?5 mins
Your first design sprint is 20 minutes. Decide what you’ll tackle2 ways: Group sketch or individual sketch/reviewShare the pen
Your first design sprint is 20 minutes. Decide what you’ll tackle2 ways: Group sketch or individual sketch/reviewShare the pen
Each team run us through what you have so farMay inspire each other to add stories to your map or reprioritize
What has your team done well, What can you improve?5 mins
Your first design sprint is 20 minutes. Decide what you’ll tackle2 ways: Group sketch or individual sketch/reviewShare the pen
Your first design sprint is 20 minutes. Decide what you’ll tackle2 ways: Group sketch or individual sketch/reviewShare the pen
Each team run us through what you have so farMay inspire each other to add stories to your map or reprioritize
What has your team done well, What can you improve?5 mins
As we break down these stories, don’t we lose some of the vision?
What did you take away?What worked well in the class?What could be improved?
I put a lot of effort and experience into this classIf you got some value out of it, I’ll ask you for something in returnI believe very strongly in my own continuous improvementAnd in order to do that, I need specific feedbackOf course, my preference is for face-face conversations,But if that isn’t yours, or there isn’t time, urlThank you for your time. Any questions?Will stick around if I didn’t answer your burning questions--winston royce - described agile in the 70's in a paper (said waterfall was great for building houses)
