scrum with asana

Click here to load reader

Post on 11-Feb-2017




1 download

Embed Size (px)


  • Scrum with Asanaan agile project management and software development process

    James G. KimStrategic Planning Director of LiST Inc.

    [email protected]

    April 17th, 2015

  • Agile Manifesto


    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

  • Project Vision Drives the Features


    Waterfall Agile




    Cost Schedule

    Plan Driven


    Cost Schedule

    Value - Vision Driven

    The Plan CreatesCost/Schedule Estimates.

    The Vision CreatesFeature Estimates.

    Derived from Arrielle Malis slides

  • Pull Systems

    4Derived from Arrielle Malis slides

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

    Input Capacity

    Pull systems have a steady flow that provides predictability.

  • Agile Principles


    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

  • Rugby Approach


    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

  • Moving the Scrum Downfield


    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


    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

  • 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.

  • 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.

  • Scrum Roles: Product Owner & Team


    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.

  • Scrum Roles: Scrum Master


    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

  • Asana: Teamwork without Email


    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.

  • Product Backlog


    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


  • Product Backlog: DEEP


    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