Slides for ME135A Agile Lifestyle

1. Welcome to the
Agile Life
Webbproduktion ME135A
October 14, 2014
daniel.spikol@mah.se

3. Agenda
• Agility: SCRUM and Product Sprints
• Background - software engineering
• Lean and Design
• Human-Centred Design
• Workshops

4. Agile Development
• Individuals and interactions over Processes and tools
• Working software over Comprehensive
documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan
• VIDEO -The Agile Manifesto - 4 Agile Values
Explained
Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved 14 June 2010.

5. Agile Principles
1.Customer satisfaction by rapid delivery of useful software
2.Welcome changing requirements, even late in development
3.Working software is delivered frequently (weeks rather than months)
4.Close, daily cooperation between business people and developers!
5.Projects are built around motivated individuals, who should be trusted
6.Face-to-face conversation is the best form of communication (co-location)!
7.Working software is the principal measure of progress!
8.Sustainable development, able to maintain a constant pace!
9.Continuous attention to technical excellence and good design!
10.Simplicity—the art of maximizing the amount of work not done—is essential
11.Self-organising teams
12.Regular adaptation to changing circumstances
Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved 14 June 2010.

6. Simply Scrum
• A product owner creates a prioritised wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish
list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time — a sprint (usually two to four weeks)
— to complete its work, but it meets each day to assess its progress (daily
Scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable: ready to
hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product
backlog and begins working again.

8. SCRUM Values
• Focus
• Courage
• Openness
• Commitment
• Respect

9. Scrum in detail
more info @ http://scrumreferencecard.com/

10. Waterfall Process

11. scrum iteration

12. Scrum Roles
• Product Owner
• Scrum Development Team
• Scrum Master

13. Product Owner
• Single person responsible for maximising the return on investment (ROI) of the development
effort
• Responsible for product vision
• Constantly re-prioritises the Product Backlog, adjusting any longterm expectations such as
release plans
• Final arbiter of requirements questions
• Accepts or rejects each product increment
• Decides whether to ship
• Decides whether to continue development
• Considers stakeholder interests
• May contribute as a team member
• Has a leadership role

14. Scrum Development Team
• Cross-functional (e.g., includes members with testing skills, and often others not
traditionally called developers: business analysts, domain experts, etc.) Self-organising
/ self-managing, without externally assigned roles
• Negotiates commitments with the Product Owner, one Sprint at a time
• Has autonomy regarding how to reach commitments
• Intensely collaborative
• Most successful when located in one team room, particularly for the first few Sprints
• Most successful with long-term, full-time membership. Scrum moves work to a
flexible learning team and avoids moving people or splitting them between teams.
• 7 ± 2 members
• Has a leadership role

15. ScrumMaster
• Facilitates the Scrum process
• Helps resolve impediments
• Creates an environment conducive to team self-organisation
• Captures empirical data to adjust forecasts
• Shields the team from external interference and distractions to keep it in group flow (a.k.a. the
zone)
• Enforces time-boxes
• Keeps Scrum artefacts visible
• Promotes improved engineering practices
• Has no management authority over the team (anyone with authority over the team is by definition
not its ScrumMaster)
• Has a leadership role

16. Scrum Meetings

17. Meeting Roles
• Sprint Planning Meeting to negotiate the Product Backlog for the Sprint.
• The Product Owner is responsible for declaring which items are the most
important to the business.
• The team is responsible for selecting the amount of work they feel they can
implement without accruing technical debt.
• The team “pulls” work from the Product Backlog to the Sprint Backlog.
• Team decides on time allotted to each of the items
• Functionality is adjusted for each of the items and time estimates are made
using different methods
• A committed Sprint Task list is made
• Sprint Time frames are decide upon from 10-30 days no less than 8 hours

18. Sprint Planning

19. Daily Scrum and Sprint Execution
• Every day at the same time and place, the Scrum Development Team members
spend a total of 15 minutes reporting to each other. Each team member summarizes
what he did the previous day, what he will do today, and what impediments he faces.
• Standing up at the Daily Scrum will help keep it short. Topics that require additional
attention may be discussed by whomever is interested after every team member has
reported.
• The team may find it useful to maintain a current Sprint Task List, a Sprint Burndown
Chart, and an Impediments List.
- During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint
goals. Impediments caused by issues beyond the team’s control are considered organizational
impediments.
• It is almost always useful for the Product Owner to attend the Daily Scrum.
• The Daily Scrum is intended to disrupt old habits of working separately.
- Members should remain vigilant for signs of the old approach. For example, looking only at the
ScrumMaster when speaking is one symptom that the team hasn’t learned to operate as a self-organizing
entity.

20. Sprint Review Meeting
• Demonstrate a working product increment to the Product Owner and everyone else who is
interested.
• The meeting should feature a live demonstration, not a report.
• After the demo, the Product Owner reviews the commitments made at the Sprint Planning
Meeting and declares which items are now considers done.
• The ScrumMaster helps the Product Owner and stakeholders convert their feedback to new
Product Backlog Items for prioritisation by the Product Owner.
• The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end
users) to attend. It is the opportunity to inspect and adapt the product as it emerges, and
iteratively refine everyone’s understanding of the requirements.
- New products, particularly software products, are hard to visualize in a vacuum. Many customers need to
be able to react to a piece of functioning software to discover what they will actually want. iterative
development, a value-driven approach, allows the creation of products that couldn’t have been
specified up front in a plan-driven approach.!
• Given a 30-day Sprint (much longer than anyone recommends nowadays), the maximum
time for a Sprint Review Meeting is four hours.

21. Sprint Retrospective Meeting
• The team reflects on its own process. They inspect their behaviour and take action to adapt it
for future Sprints.
• An in-depth retrospective requires an environment of psychological safety not found in most
organisations. Without safety, the retrospective discussion will either avoid the uncomfortable
issues or deteriorate into blaming and hostility.
• Set the stage, gather data, generate insights, decide what to do, close the retrospective. (1)
- The Art of Focused Conversations, breaks the process into similar steps: Objective, reflective,
interpretive, and decisional (ORID). (2)
• A third impediment to psychological safety is geographic distribution. Geographically
dispersed teams usually do not collaborate as well as those in team rooms.
• Retrospectives often expose organisational impediments.
• ScrumMasters should use a variety of techniques to facilitate retrospectives, including silent
writing, timelines, and satisfaction histograms.
• In all cases, the goals are to gain a common understanding of multiple perspectives and to
develop actions that will take the team to the next level.

22. Backlog Refinement Meetings
• Team considers the effort they would expend to complete items in the Product Backlog and
provides other technical information to help the Product Owner prioritise them.
• Large vague items are split and clarified, considering both business and technical concerns.
• It is common to write Product Backlog Items in User Story form. Oversized PBIs are called
epics.
• Agility requires learning to split large epics into user stories representing very small product
features.
- For example, in a medical records application the epic “display the entire contents of a patient’s allergy
records to a doctor” yielded the story “display whether or not any allergy records exist.” While the engineers
anticipated significant technical challenges in parsing the internal aspects of the allergy records, the
presence or absence of any allergy was the most important thing the doctors needed to know. Collaboration
between business people and technical people to split this epic yielded a story representing 80% of the
business value for 20% of the effort of the original epic.
• Since most customers don’t use most features of most products, it’s wise to split epics to
deliver the most valuable stories first.
• While delivering lower-value features later is likely to involve some rework, rework is better
than no work.

23. Backlog Refinement Meetings

24. Sprint Backlog

26. Trello Resources
• https://trello.com/
• http://www.tommasonervegna.com/blog/
2014/1/9/10-effective-tips-for-using-trello-as-an-agile-
scrum-project-management-tool
• https://trello.com/b/YEXXigXH/template-sprint-retrospective
• https://trello.com/b/Nr3RvsY1/sprint-template

28. The Lean Start-Up
• Entrepreneurship
• Continuos innovation
• Management - Learn
• Build Measure Learn: Pivot or Persevere

29. SRI and the 5 DOI
• Important Customer and Market Need (focus on customer need
and not interesting technologies or product ideas)
• Value Creation (Create customer value NABC (Need Approach
Benefit Competition))
• Innovation Champions (Develop leaders with focus and passion)
• Innovation Teams (Build teams based on shared vision,
complementary skills, and shared rewards)
• Organizational Alignment (Align the team’s vision and rewards,
focus on result, show progress steadily, build organization’s
understanding and achievements in innovation step-by-step.

30. Buxton, W. (2007). Sketching user experiences : getting the design right and the right
design. Amsterdam: Elsevier/Morgan Kaufmann.

31. Product Design Sprints
• Day 1: Understand- Dig into the design
problem through research, competitive
review, and strategy exercises.
• Day 2: Diverge- Rapidly develop as many
solutions as possible.
• Day 3: Decide- Choose the best ideas and
hammer out a user story.
• Day 4: Prototype- Build something quick
and dirty that can be shown to users.
• Day 5: Validate- Show the prototype to real
humans (in other words, people outside
your company) and learn what works and
what doesn’t work.

32. Setting the Stage
• Pick a big fight
• Get (role play)the right people
- Designer
- CEO
- Product manger
- User expert
- Engineer
- Marketer
- Any one who is interested
• Schedule it all!

34. 2 hour design sprint
• (5 min) Read, understand problem
• (5 min) Write notes / define constraints / define users
• (5 min) Competitive research - see how other people have solved similar problems
• (5 min) Define tasks - Write down key user tasks
• (10 min) Mind map - dump all thoughts here, generate as many ideas as possible
• (5 min) User story - create simple user story in the form of a flow chart
• (5 min) Crazy eights - generate as many crazy ideas as possible
• (5 min) Crazy eights - repeat. generate as many crazy ideas as possible
!
• (10 min) Story board - create a more detailed user story
• (~ 20 min) Pick solution & refine
- create a rough user storyboard with cores interactions (a click, writes text, or
does something)

35. An example case
During a crisis, many people turn immediately to
their mobile devices for assistance and
information. One such situation occurs when
parents lose track of a young child at a crowded
theme park. Assume an application about that
park would be installed on devices of a large
number of guests and workers. Design a feature
of that application that could help quickly reunite
parents with their children, without requiring their
children to wear or carry a device.

36. Read, understand problem
• Questions?
• Once I start the sprint, the first thing I do is
understand the problem and clarify it. I do this
by reading the question and asking myself some
basic questions like how might I solve this
problem, how has this been solved before, and
what might users need etc…

37. Write notes / define
constraints / define users
• Focus on the users, the customers imagine their
needs
• Once I understand the problem, I quickly write
down anything that comes to mind. I also define
the users for the app (park employees, guests
and parents). At this point I am thinking about two
possible solutions. One uses facial recognition
technology. Another solution could work by
sending alerts to park guests and having them
visually look for the child.

38. Competitive Research
• I then do some quick research to see if anyone
is solving this problem already. This is very
rapid, and it helps to get ideas going.
• use the internet - duh…

39. Define Tasks
• I always define tasks early in any design process.
These tasks inform all my interaction design
decisions. Tasks also focus me on the user and
their needs.

40. Mindmap
• Mind mapping is my way to get as many ideas out
of my head and onto paper as fast as possible.
Anything goes here.

41. User Story
• I sketch up a quick user story. A user story tells the basic
interactions a user will do to complete key tasks.
• The user story that is developing at this point is an app
that uses facial recognition technology. The theme park will
have cameras setup throughout the park. A user starts by
taking a picture of their child, and uploads it to the park
servers. When a child is lost, the park can search for that
child in the park and alert the parent when found. There is
also a backup solution where if the child is not found within
a minute or so using facial recognition technology, then
nearby guests will be alerted about the missing child so
they could join the search.

42. User story Diagram

43. User story Diagram
individual 5 mins

44. Crazy Eights
• 1 sheet of paper fold in half 4 times
• 5 minutes to draw eight sketches
• 40 seconds for each
• Crazy eights x2 - 10 mins
• Now that I have a rough idea of how my solution might
work, I want to sketch as many UI concepts as fast as
possible. I do this using crazy eights, which is a sheet of
paper folded into 8 sections, and I sketch a UI in each
section. I repeat this twice.
i5 + 10 mins

45. Crazy Eights

46. Storyboard
• Now that my concept is becoming more clear, I
create a more detailed storyboard. Here I further
develop the interaction design, and note any
conflicts or issues.

47. Storyboards
• Make it stand alone — Just like a real product, your
drawing has to make sense by itself, without you there to
pitch it. In the next steps, people will be looking at these,
but you won’t have a chance to talk about your idea until
the end.
• Keep it anonymous — Don’t write your name on your
drawing. You’ll want all ideas to start on a level playing field
and it can be distracting to know which one was drawn by
the CEO.
• Give it a name — Come up with a catchy title for your idea.
That makes it easier to discuss and compare later.

48. Storyboard
i10 mins

49. Pick a solution
• Further develop key interactions and finalize a
storyboard. I then create a UI sketch for each
screen or interaction in my solution.

50. 2 hour design sprint
• (5 min) Read, understand problem
• (5 min) Write notes / define constraints / define users
• (5 min) Competitive research - see how other people have solved similar problems
• (5 min) Define tasks - Write down key user tasks
• (10 min) Mind map - dump all thoughts here, generate as many ideas as possible
• (5 min) User story - create simple user story in the form of a flow chart
• (5 min) Crazy eights - generate as many crazy ideas as possible
• (5 min) Crazy eights - repeat. generate as many crazy ideas as possible
!
• (10 min) Story board - create a more detailed user story
• (~ 20 min) Pick solution & refine
- create a rough user storyboard with cores interactions (a click, writes text, or
does something)

51. Conflicts
g10 mins

52. Generate an assumption
table
g10 mins

53. SRI and the 5 DOI
• Important Customer and Market Need (focus on customer need
and not interesting technologies or product ideas)
• Value Creation (Create customer value NABC (Need Approach
Benefit Competition))
• Innovation Champions (Develop leaders with focus and passion)
• Innovation Teams (Build teams based on shared vision,
complementary skills, and shared rewards)
• Organizational Alignment (Align the team’s vision and rewards,
focus on result, show progress steadily, build organization’s
understanding and achievements in innovation step-by-step.

54. Product Design Sprints
• Day 1: Understand- Dig into the design problem through
research, competitive review, and strategy exercises.
• Day 2: Diverge- Rapidly develop as many solutions as possible.
• Day 3: Decide- Choose the best ideas and hammer out a user
story.
• Day 4: Prototype- Build something quick and dirty that can be
shown to users - CUSTOMERS and real humans.
• Day 5: Validate- Show the prototype to real humans (in other
words, people outside your company) and learn what works and
what doesn’t work. YOUR CUSTOMER

55. Other inspiration
• http://www.gv.com/lib/how-to-choose-the-right-ux-
metrics-for-your-product
• http://www.gv.com/lib/the-gv-research-sprint-a-4-
day-process-for-answering-important-startup-questions
• 3 hr mini sprint http://chrisvallejos.blogspot.se/

56. Thanks
• http://www.gv.com/lib/the-product-design-sprint-a-five-
day-recipe-for-startups
Daniel Spikol
Assistant Professor
Program Responsible for Master’s
programs in Computer Science
room K2:B338
phone 040-66 57630
!
office hours if door is open or by appointment
daniel.spikol@mah.se