Scrum with Asana

30
Scrum with Asana an agile project management and software development process James G. Kim Strategic Planning Director of LiST Inc. [email protected] April 17th, 2015

Transcript of Scrum with Asana

Page 1: Scrum with Asana

Scrum with Asanaan agile project management and software development process

James G. KimStrategic Planning Director of LiST Inc.

[email protected]

April 17th, 2015

Page 2: Scrum with Asana

Agile Manifesto

2

In February 2001, seventeen software developers, including Kent Beck, Ward Cunningham, and Martin Fowler, met at the Snowbird ski resort, and published the Manifesto for Agile Software Development:

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 and Interactions over Processes and Tools

• Working Software over Comprehensive Documentation

• Customer Collaboration over Contract Negotiation

• Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

Derived from AgileManifesto.org

Page 3: Scrum with Asana

Project Vision Drives the Features

3

Waterfall Agile

Contraints

Estimates

Features

Cost Schedule

Plan Driven

Features

Cost Schedule

Value - Vision Driven

The Plan CreatesCost/Schedule Estimates.

The Vision CreatesFeature Estimates.

Derived from Arrielle Mali’s slides

Page 4: Scrum with Asana

Pull Systems

4Derived from Arrielle Mali’s slides

CapacityInput ?Push systems overwhelm capacity, creating turbulence, waste, and delay.

Input Capacity

Pull systems have a steady flow that provides predictability.

Page 5: Scrum with Asana

Agile Principles

5

The Agile Manifesto is based on 12 principles:

• Customer satisfaction by rapid delivery of useful software

• Welcome changing requirements, even late in development

• Working software is delivered frequently (weeks rather than months)

• Close, daily cooperation between business people and developers

• Projects are built around motivated individuals, who should be trusted

• Face-to-face conversation is the best form of communication (co-location)

• Working software is the principal measure of progress

• Sustainable development, able to maintain a constant pace

• Continuous attention to technical excellence and good design

• Simplicity — the art of maximizing the amount of work not done — is essential

• Self-organizing teams

• Regular adaptation to changing circumstance

Derived from AgileManifesto.org

Page 6: Scrum with Asana

“Rugby” Approach

6

The holistic or “rugby” approach has been defined, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth” in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in The New New Product Development Game.

Derived from The New New Product Development Game

Page 7: Scrum with Asana

Moving the “Scrum” Downfield

7

From interviews with organization members from the CEO to young engineers, we learned that leading companies show six characteristics in managing their new product development processes:

• Built-in Instability

• Self-organizing Project Teams

• Overlapping Development Phases

• “Multilearning”

• Subtle Control

• Organizational Transfer of Learning

These characteristics are like pieces of a jigsaw puzzle. Each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference.

Derived from The New New Product Development Game

Page 8: Scrum with Asana

Scrum Methodology

8Derived from The Scrum Primer

In the early 1990s, Ken Schwaber and Jeff Sutherland developed what would become “Scrum” at their respective companies, and in 1995, they jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of OOPSLA ’95.

Page 9: Scrum with Asana

Scrum Roles

9Derived from The Scrum Primer

In Scrum, there are three roles: Product Owner, Team (also called Development Team), and Scrum Master. Together these are known as the Scrum Team.

Page 10: Scrum with Asana

Scrum Roles: Product Owner & Team

10

The Product Owner represents the stakeholders, and is the voice of the customer. He or she is responsible for maximizing return on investment (ROI) by identifying product features (typically user stories), translating these into a prioritized list (i.e., Product Backlog), deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list. The Scrum Team has one and only one Product Owner, and while he or she may also be a member of the Team, this role should not be combined with that of the Scrum Master.

Derived from The Scrum Primer

The Team (also called Development Team) is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint (the Sprint Goal). The Team in Scrum is “cross-functional” and it is “self-organizing” (self-managing), with a very high degree of autonomy and accountability. The Team decides how many items (from the Product Backlog) to build in a Sprint by adding them to the Sprint Backlog, and how best to accomplish that goal. Since each member of the Team is just a team member, the Team is not only cross-functional but also demonstrates multi-learning.

Page 11: Scrum with Asana

Scrum Roles: Scrum Master

11

The Scrum Master helps the product group learn and apply Scrum to achieve business value. The Scrum Master does whatever is in their power to help the Team, Product Owner, and organization be successful. The Scrum Master is not the manager of the Team members, nor are they a project manager, team lead, or team representative. Instead, the Scrum Master serves the Team; he or she helps to remove impediments, protects the Team from outside interference, and helps the Team to adopt modern development practices. He or she educates, coaches, and guides the Product Owner, Team, and the rest of the organization in the skillful use of Scrum.

Derived from The Scrum Primer

Page 12: Scrum with Asana

Asana: Teamwork without Email

12

Asana is a Web-based solution for the effective collaboration of teams. Main user focus is to plan and manage projects and tasks online without the use of email.

The Asana workflow for Scrum: • Each team gets a “workspace” for each project, • Workspaces contain ”projects” for lists, and • Projects contain ”tasks” for items.

In each item, users can add notes, comments, attachments, and tags.

Users can follow lists and items, and when the state of a list or item changes, followers get updates about the changes in the inboxes.

Page 13: Scrum with Asana

Product Backlog

13

The Product Backlog is a prioritized list of customer-centric features desired in the product. It exists (and evolves) over the lifetime of the product.

Derived from The Scrum Primer

The Product Backlog includes a variety of items:

• New Customer Features(e.g., “enable all users to place book in shopping cart”)

• Major Engineering Improvement Goals(e.g., “rewrite the system from C++ to Java”)

• Improvement Goals (e.g., “speed up our tests”)

• Research Work(e.g., “investigate solutions for speeding up credit card validation”)

• Known Defects, if there are only a few problems(A system with many defects usually has a separate defect tracking list.)

The Product Backlog Items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

The Product Backlog exists (and evolves) over the lifetime of the product; it is the product roadmap (Figure 2 and Figure 3). At any point, the Product Backlog is the single, definitive view of “everything that could be done by the Team ever, in order of priority”. Only a single Product Backlog exists for a product; this means the Product Owner is required to make prioritization decisions across the entire spectrum, representing the interests of stakeholders (including the Team).

Figure 2. The Product Backlog

Figure 3. Visual Management: Product Backlog items on the wall

The Product Backlog includes a variety of items, primarily new customer features (“enable all users to place book in shopping cart”), but also major engineering improvement goals (e.g., “rewrite the system from C++ to Java”), improvement goals (e.g. “speed up our tests”), research work (“investigate solutions for speeding up credit card validation”), and, possibly, known defects (“diagnose and fix the order processing script errors”) if there are only a few problems. (A system with many defects usually has a separate defect tracking system.)

Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain “user stories”; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.

A good Product Backlog is DEEP…

6

Page 14: Scrum with Asana

Product Backlog: DEEP

14

A good Product Backlog is:

• Detailed appropriately: The top priority items are more fine-grained and detailed than the lower priority items, since the former will be worked on sooner than the later.

• Estimated: The items for the current release need to have estimates, and furthermore should be considered for re-estimation each Sprint as everyone learns and new information arises.

• Emergent: In response to learning and variability, the Product Backlog is regularly refined. Each Sprint, items may be added, removed, modified, split, and changed in priority.

• Prioritized: The items at the top of the Product Backlog are prioritized or ordered in a 1-N order.

Derived from The Scrum Primer

Page 15: Scrum with Asana

Product Backlog in Asana

15

Page 16: Scrum with Asana

User Stories

16

Product Backlog Items are articulated in any way that is clear and sustainable. Items can be expressed as User Stories, Use Cases, or any other requirements approach that the group finds useful.

User Stories are written by or for business users or customers as a primary way to influence the functionality of the system being developed. User Stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.), though primarily it is the task of the Product Owner to ensure User Stories are captured.

As a <role>, I want <goal/desire> (so that <benefit>).As a purchaser, I want to search for generic equivalents of brand named items so that I can save money.

Derived from Wikipedia

Page 17: Scrum with Asana

User Stories: INVEST

17

INVEST Criteria for User Stories:

• Independent: The User Story should be self-contained, in a way that there is no inherent dependency on another User Story.

• Negotiable: User Stories, up until they are part of an iteration (i.e., Sprint), can always be changed and rewritten.

• Valuable: A User Story must deliver value to the end user.

• Estimable: You must always be able to estimate the size of a User Story.

• Small Sized: User Stories should not be bigger than one Sprint.

• Testable: The User Story or its related description must provide the necessary information to make test development possible.

Derived from Wikipedia

Page 18: Scrum with Asana

User Stories in Asana

18

Page 19: Scrum with Asana

Product Backlog Refinement

19

Product Backlog Refinement is the ongoing process of the whole Scrum Team’s refining (or “grooming”) the Product Backlog to support future Sprints.

The Product Backlog Refinement takes no more than 10% of the capacity of the Team for the Sprint. For example, in a two-week Sprint, perhaps one day is spent on refinement.

• Detailed Requirement Analysis

• Splitting Large Items into Smaller Ones

• Estimation of New Items

• Re-estimation of Existing Items

Derived from The Scrum Primer

Page 20: Scrum with Asana

Priorities based on Risk, Effort, and Value

20

Asking the following questions of the different items will start a conversation that will start to determine priorities:

• Which items add the most value to the user (or customer)?

• Which items post the most business risk?

• Which items pose the most technical risk?

It’s helpful to rank items along the three questions using a scale.

• Fibonacci Scale: 1, 2, 3, 5, 8, …

Page 21: Scrum with Asana

Sprint Planning

21Derived from The Scrum Primer

Sprint Planning is a meeting to prepare for the Sprint, typically divided into two parts (part one is “what” and part two is “how”). Each part is timeboxed to one hour per week of Sprint.

• Sprint Planning Part One: The Product Owner and Team review the high-priority items in the Product Backlog that the Product Owner is interested in implementing in this Sprint. The Team and the Product Owner may also devise the Sprint Goal, a summary statement of the Sprint objective.

• Sprint Planning Part Two: The Team forecasts the amount of items they can complete by the end of the Sprint, starting at the top of the Product Backlog and working down the list in order. The Team selects the first item on the Product Backlog and work their way down until they are ‘full’. For each item, they create a list of work which consists of either decomposed Product Backlog items into tasks, or simply the Product Backlog item. This list of work to be done during the Sprint is called the Sprint Backlog that details the time it will take to do that work.

Page 22: Scrum with Asana

Tracking Progress during the Sprint

22

this is the reality of product development. The important thing is that it shows the Team their progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in terms of progress), but in terms of how much work remains in the future – what separates the Team from their goal. If the burndown line is not tracking downwards towards completion near the end of the Sprint, then the Team needs to adjust, such as to reduce the scope of the work or to find a way to work more effectively while still maintaining a sustainable pace.

While the Sprint Burndown chart can be created and displayed using a spreadsheet, many Teams find it is more effective to show it on paper on a wall in their workspace, with updates in pen; this “low-tech/high-touch” solution is fast, simple, and often more visible than a computer chart.

Figure 6. Daily Updates of Work Remaining on the Sprint Backlog

Figure 7. Sprint Burndown Chart

12

this is the reality of product development. The important thing is that it shows the Team their progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in terms of progress), but in terms of how much work remains in the future – what separates the Team from their goal. If the burndown line is not tracking downwards towards completion near the end of the Sprint, then the Team needs to adjust, such as to reduce the scope of the work or to find a way to work more effectively while still maintaining a sustainable pace.

While the Sprint Burndown chart can be created and displayed using a spreadsheet, many Teams find it is more effective to show it on paper on a wall in their workspace, with updates in pen; this “low-tech/high-touch” solution is fast, simple, and often more visible than a computer chart.

Figure 6. Daily Updates of Work Remaining on the Sprint Backlog

Figure 7. Sprint Burndown Chart

12

Everyday, the Team members update their estimate of the effort remaining to complete their current work in the Sprint Backlog. It is also common for someone to add up the effort remaining for the Team as a whole, and plot it on the Sprint Burndown Chart.

Derived from The Scrum Primer

Page 23: Scrum with Asana

Sprint Backlog in Asana

23

Page 24: Scrum with Asana

Estimate of Effort in Asana

24

Page 25: Scrum with Asana

Daily Scrum

25

The Daily Scrum (or stand-up) is a short (15 minutes or less) meeting that happens every workday at an appointed time. It is the Team’s opportunity to synchronize their work and report to each other on obstacles.

• Before the Daily Scrum: Each member makes sure that the personal ”Assigned to Me” list in the workspace in Asana is properly reflecting the prioritization for the day and the Team’s involvement in the project.

• During the Daily Scrum: One by one, each member of the Team reports three things to the other members of the Team:

1. What has been accomplished since the last meeting? 2. What will be done before the next meeting? 3. What obstacles are in the way? There is little or no in-depth discussion during the Daily Scrum.

• After the Daily Scrum: Each member updates the “Assigned to Me” list and any relevant lists in Asana.

Derived from The Scrum Primer

Page 26: Scrum with Asana

Scrum Board in Asana

26

Many Teams have a Sprint Backlog in the form of a wall-sized task board (often called a Scrum Board) where tasks (written on Post-It Notes) migrate during the Sprint across columns labeled “To Do,” “Work in Progress,” and “Done.”

Page 27: Scrum with Asana

Working with Gitflow Workflow

27

• When starting work on a Backlog Item by the Team: - First, move the Backlog Item from the “To Do” Section to the “Work in Progress” Section in Asana. - Second, start a new Feature or Hotfix with Git.

• After finishing work on a Backlog Item by the Team: - First, move the Backlog Item from the “Work in Progress” Section to the “Done” Section in Asana. - Second, finish up a new Feature or Hotfix with Git.

• After reviewing work on a Backlog Item by the Product Owner: - Mark the Backlog Item completed in Asana.

• At the end of the Sprint: - Make a release with Git.

The Gitflow Workflow is Vincent Driessen's strict branching model designed around the project release (i.e., the end of the Sprint).

Page 28: Scrum with Asana

Sprint Review

28

After the Sprint ends, there is the Sprint Review, where people review the Sprint.

• The Sprint Review is an inspect and adapt activity for the product.

• For a two-week Sprint it is a maximum length of two hours.

• Anyone present is free to ask questions and give input.

The review definitely includes using the actual live software that the Team built during the Sprint, but if the focus of the review is only looking at the product rather than having a conversation, there is an imbalance.

The “live software” portion of the Sprint Review is not a “presentation” the Team gives — there is no slideware.

Derived from The Scrum Primer

Page 29: Scrum with Asana

Sprint Retrospective

29

The Sprint Retrospective, which follows the Review, involves inspect and adapt regarding the process and environment. It’s an opportunity for the Team to discuss what’s working and what’s not working, and agree on changes to try.

• Timeboxed to 45 minutes per week of Sprint.

• Team, Scrum Master, and Product Owner (optional) attend.

• Sometimes the Scrum Master can act as an effective facilitator.

• It’s important to ensure that every Retrospective focuses not only on problems, but also on positives or strengths.

Derived from The Scrum Primer

Page 30: Scrum with Asana

Thank You.

30