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.

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

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

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

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

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

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

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.

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
10. None

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

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

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

14. story list units?

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?

16. estimation units • jellybeans • t-shirt sizing • fibonacci •

    function points • COCOMO predictors • SLIM parameters • beware: relative vs absolute!

17. try it for a few weeks

18. None

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

    / turndown chart / finger diagram

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

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.

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

23. cloud.google.com/devops

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

25. technical practices cloud.google.com/devops

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

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

28. retrospective exercises

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

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