Unit 6. Managing Work

Transcript

1. i290 lean/agile product management
   unit 6: managing work
   @jezhumble
   https://leanagile.pm/
   humble@berkeley.edu
   This work © 2015-2020 Jez Humble
   Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
   

   View Slide

2. consider key metrics and the effect of measurement
   understand the different roles people play on teams
   be able to explain key frameworks and their goals
   distinguish what is and isn’t essential
   be able to perform planning activities
   learning outcomes
   

   View Slide

3. https://www.gov.uk/service-manual/the-team/what-each-role-does-in-service-team
   …and tester!
   

   View Slide

4. https://www.gov.uk/service-manual/the-team/what-each-role-does-in-service-team
   

   View Slide

5. https://www.gov.uk/service-manual/the-team/what-each-role-does-in-service-team
   

   View Slide

6. https://www.gov.uk/service-manual/agile-delivery/create-agile-working-environment
   

   View Slide

7. the production line
   http://www.flickr.com/photos/toyotauk/4711057997/
   

   View Slide

8. agile principles
   •Our highest priority is to satisfy the customer through early and continuous delivery of
   valuable software.
   •Welcome changing requirements, even late in development. Agile processes harness change
   for the customer's competitive advantage.
   •Deliver working 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.
   •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.
   •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.
   •Continuous attention to technical excellence and good design enhances agility.
   •Simplicity—the art of maximizing the amount of work not done—is essential.
   •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.
   

   View Slide

9. xp scrum kanban
   values
   communication,
   simplicity, feedback,
   courage, respect.
   commitment,
   courage, focus,
   openness, & respect
   -
   principles 14 principles
   empirical process
   control; transparency,
   inspection,
   adaptation
   start where you are;
   incremental evolutionary
   change; respect existing
   roles, responsibilities &
   job titles
   practices 13 practices 3 artifacts, 5 events
   visualize work, limit WIP,
   manage flow, make mgmt
   policies explicit, improve
   collaboratevely
   roles
   whole team including
   customer
   product owner, scrum
   master, development
   team
   use existing
   cadence 1-2 week iterations 2-4 week iterations flow-based (no iterations)
   measuring velocity velocity + burndown lead time
   

   View Slide

10. View Slide

11. team estimates stories, breaking down large ones
    every 1-4 weeks on cadence, put aside 1-3h
    prerequisite: user stories derived from goals/backlog
    product owner verifies capacity and prioritizes work
    team identifies areas of risk and discusses mitigations
    iteration planning meetings
    

    View Slide

12. dependencies on other teams / systems
    we don’t know how we will do the work
    we don’t know if the work will achieve the outcome
    common risks
    

    View Slide

13. user stories
    Leaky abstractions: http://www.joelonsoftware.com/articles/LeakyAbstractions.html
    

    View Slide

14. story list
    units?
    

    View Slide

15. understand if we can achieve our goals
    identify large/risky work and break down/mitigate
    grow shared understanding of how work will be done
    set expectations with stakeholders
    why estimate?
    

    View Slide

16. estimation units
    • jellybeans
    • t-shirt sizing
    • fibonacci
    • function points
    • COCOMO predictors
    • SLIM parameters
    • beware: relative vs absolute!
    

    View Slide

17. try it for a few weeks
    

    View Slide

18. View Slide

19. tracking progress
    Cumulative Flow Diagram (CFD) / burn up chart / turndown chart / finger diagram
    

    View Slide

20. the people who made the estimates do the work
    not a productivity metric!
    can’t be compared across teams
    it can be gamed (Goodhart's law)
    problems with velocity
    

    View Slide

21. design vs delivery
    Product Design and Development
    Software Delivery
    (build, testing, deployment)
    Create new products and services that
    solve customer problems using
    hypothesis-driven delivery, modern UX,
    design thinking.
    Enable fast flow from development to
    production and reliable releases by
    standardizing work, reducing variability
    and batch sizes.
    Feature design and implementation may
    require work that has never been
    performed before.
    Integration, test and deployment must be
    performed continuously as quickly as
    possible.
    Estimates are highly uncertain.
    Cycle times should be well-known and
    predictable.
    Outcomes are highly variable. Outcomes should have low variability.
    

    View Slide

22. 2019 State of DevOps Report: cloud.google.com/devops
    

    View Slide

23. cloud.google.com/devops
    

    View Slide

24. lean mgmt & product dev
    cloud.google.com/devops
    

    View Slide

25. technical practices
    cloud.google.com/devops
    

    View Slide

26. agile principles
    “At regular intervals, the team reflects
    on how to become more effective, then
    tunes and adjusts its behavior
    accordingly.”
    http://agilemanifesto.org/principles
    

    View Slide

27. to propose experiments for getting better
    held at the end of an iteration before planning
    to reflect on—and learn from—the past as a team
    many possible exercises / activities!
    retrospectives
    

    View Slide

28. retrospective exercises
    

    View Slide

29. retrospective prime directive
    “Regardless of what we discover, we
    understand and truly believe that
    everyone did the best job they could,
    given what they knew at the time, their
    skills and abilities, the resources
    available, and the situation at hand.”
    — Norm Kerth
    

    View Slide

30. further reading
    • Extreme Programming Explained: Embrace Change (2nd Edition) by
    Kent Beck and Cynthia Andres
    • Kanban: Successful Evolutionary Change for Your Technology Business by
    David J Anderson
    

    View Slide