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