Embed Size (px)
Citation preview
Welcome to the Agile Life
Webbproduktion ME135A October 14, 2014
Agenda• Agility: SCRUM and Product Sprints
• Background - software engineering
• Lean and Design
• Human-Centred Design
• Workshops
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.
Agile Principles1.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 circumstancesBeck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved 14 June 2010.
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.
SCRUM Values• Focus
• Courage
• Openness
• Commitment
• Respect
Waterfall Process
scrum iteration
Scrum Roles• Product Owner
• Scrum Development Team
• Scrum Master
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
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
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
Scrum Meetings
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
Sprint Planning
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.
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.
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.
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.
Backlog Refinement Meetings
Sprint Backlog
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
The Lean Start-Up
• Entrepreneurship
• Continuos innovation
• Management - Learn
• Build Measure Learn: Pivot or Persevere
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.
Buxton, W. (2007). Sketching user experiences : getting the design right and the right design. Amsterdam: Elsevier/Morgan Kaufmann.
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.
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!
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)
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.
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…
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.
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…
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.
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.
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.
User story Diagram
User story Diagram
individual 5 mins
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
Crazy Eights
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.
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.
Storyboard
i10 mins
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.
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)
Conflicts
g10 mins
Generate an assumption table
g10 mins
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.
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
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/
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
