Agile project management day 2
- 2. Agenda today • Scrum and the Scrum team • The project managers role towards the Scrum team. • Scaling Agile • Multiple teams and System Anatomy • User stories • Estimation and velocity • Agile contracts • Empower teams – managing delegation 2Agil Projektledning Dag 2
- 3. 3 How do you manage requirements? Who owns the requirement? Agil Projektledning Dag 2
- 4. So what is agile? • Agile Software Development is defined by the Agile Manifesto. • The base for Agile is Lean, Knowledge theory and complexity theory. • Agile is designed to manage uncertainty and changes. • Core in agile is self-organizing and empowered teams, cadence, interactions, transparency and visualization 4Agil Projektledning Dag 2
- 7. Scrum – sprint releases • Roles – Product Owner – Scrum Master – Team • Artifacts – Product Backlog – Sprint Backlog – Product Increment • Activities – Daily sprint – Sprint review (Demo) – Sprint retrospective 7Agil Projektledning Dag 2
- 8. Kanban – continous releases (e.g. maintenance) • Visualize the workflow • Limit work in progress (WIP) • Measure lead time 8Agil Projektledning Dag 2
- 9. 9 Scrum – measure by velocity Kanban – measure by mean lead time Agil Projektledning Dag 2
- 10. Definition of project management • Project management is the discipline of planning, organizing, motivating, and controlling resources to achieve specific goals. … The temporary nature of projects stands in contrast with business as usual. 10Agil Projektledning Dag 2 Source: Wikipedia
- 11. Projects in a line organization 11Agil Projektledning Dag 2
- 12. Projects in an agile organization 12Agil Projektledning Dag 2 Projekt
- 13. SCRUM Roles 13Agil Projektledning Dag 2
- 14. When it comes to Agile Project Management it is worth noting that most agile processes - and Scrum in particular - do not include a role called “project manager”. Without a specific person tasked with performing all managing duties, those responsibilities are distributed among the other roles on the project, namely the team, the ScrumMaster, and the Product Owner. Mike Cohn Agil Projektledning Dag 2 14
- 15. Product Owner The product owner has responsibility for deciding what work will be done. This is the single individual who is responsible for bringing forward the most valuable product possible by the desired date. The product owner does this by managing the flow of work to the team, selecting and refining items from the product backlog. The product owner maintains the product backlog and ensures that everyone knows what is on it and what the priorities are. The product owner may be supported by other individuals but must be a single person (SCRUM alliance) 15Agil Projektledning Dag 2
- 16. The SCRUM-master The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. (The SCRUM Guide, Sutherland/Schwaber) 16Agil Projektledning Dag 2
- 17. Four scenaries 17 Projekt SCRUM- team SCRUM- team Projekt SCRUM- team Projekt Agil Projektledning Dag 2 SCRUM SCRUM SCRUM SCRUM SCRUM SCRUM Projekt
- 18. 18Agil Projektledning Dag 2 Development/maintainance team Projekt
- 19. What function shall the Project Manager have towards the Srum team? Agil Projektledning Dag 2 19 Scenario Scrum Master Product Owner Customer Stakeholder 1 2 3 4 Projekt SCRUM- team SCRUM- team Projekt SCRUM -team Projekt SCR UM SCR UM SCR UM SCR UM SCR UM SCR UM Projekt 1 2 3 4
- 21. 21
- 22. 22
- 23. Scaled Scrum PSI • -------- • -------- • -------- • -------- • -------- • -------- Increment backlog Build release candidate, Demo & Release review meeting Joint teams retrospectiv e meetingHardening period 3 weeks RC PSIPSIPSI PSI PPB 1 (Project Portfoli o Board) PPB 2 Sprint plannin g meeting Daily Scrum Weekly Scrum of Scrums Year 1 Year 2 Inc 1 Inc 2 Inc 3 Inc 4 Inc 5 Pre- planning meeting Release planning meeting PSI Fiel d test Software integration Sprint retrospective One-pager release report • Aggregated increment burndown • Status &progress each Epic • Improvements to be done • Impediments • ---- ---- • ---- ---- • ---- ---- • ---- ---- • ---- ---- • ---- ---- NFI - Project Management in Agile Organizations @ Tele2 23
- 24. 24
- 25. Spotify 25NFI - Project Management in Agile Organizations @ Tele2 https://dl.dropboxusercontent.com/u/1018 963/Articles/SpotifyScaling.pdf
- 26. Who steers what? 26NFI - Project Management in Agile Organizations @ Tele2
- 27. Squad responsibilities 27NFI - Project Management in Agile Organizations @ Tele2
- 28. Dependencies between Squads 28NFI - Project Management in Agile Organizations @ Tele2
- 29. 29
- 30. Release preparation & verification R n.1 Merge Corrections TG0 TG5 PD2Release content decided Which features to include in a release, both developed, under development and not yet started. 21 272019181716 ...12 .... 1511 GO Decision Verified “up and running” system version: Feature implementation decision R n.1 R n.2 Development “Go” per Decoupling of release projects DesignRelease Integration & Automated Regression Test (with load) Streamlined Development NFI - Project Management in Agile Organizations @ Tele2 30
- 31. Product Owner Hierarchy or team? 31NFI - Project Management in Agile Organizations @ Tele2
- 32. DeLaval 32
- 33. 33 Program and projects at DeLaval Leveransprojekt Affärsområden Mjukvaruleverabel Marknadsrelease Support Krav- arbete Program NFI - Project Management in Agile Organizations @ Tele2
- 34. De Laval Continuous Delivery of Multiple Projects Where one release is interdependent of one or more teams Where one release is directed at one or more projects Inc n + 1 Inc n + 2 Inc n + 3 Inc n + 4 Project A System Architecture Quality Releases Project B Project C Project D System Releases NFI - Project Management in Agile Organizations @ Tele2 34
- 35. Portfolio Level 35NFI - Project Management in Agile Organizations @ Tele2
- 36. Program Level 36NFI - Project Management in Agile Organizations @ Tele2
- 37. Team Level 37NFI - Project Management in Agile Organizations @ Tele2
- 38. Scaled Agile Framework™ Big Picture NFI - Project Management in Agile Organizations @ Tele2 38
- 39. System Anatomy to manage multiple teams 39NFI - Project Management in Agile Organizations @ Tele2
- 40. Visual Planning in the Fuel Reduction Team 2013-10-02 40 GDP banner with major verification activities Backlog next XX weeks week Fuel consumption FC reduction ideas Anatomy Increment Plan B20
- 41. 41NFI - Project Management in Agile Organizations @ Tele2
- 42. 42NFI - Project Management in Agile Organizations @ Tele2
- 43. ATM Functions 43 Cash withdrawal Account balance User interface Authentication Communication ATM - Bank Handling of bills
- 44. ATM Functions 44 Cash withdrawal Account balance User interface Authentication Communication ATM - Bank Handling of bills
- 45. ATM Anatomy 45 Cash withdrawal Account balance User interfaceAuthentication Communication ATM - Bank Eject bills
- 46. 46 User Stories NFI - Project Management in Agile Organizations @ Tele2
- 47. Agile requirement hierarchy, Dean Leffingwell 47NFI - Project Management in Agile Organizations @ Tele2 Theme Epic Story Feature Story Epic Task Task Epic Feature
- 48. Mike Cohn 48NFI - Project Management in Agile Organizations @ Tele2 http://www.mountaingoatsoftware.com/presentatio ns/introduction-to-user-stories
- 49. 49NFI - Project Management in Agile Organizations @ Tele2
- 50. 50NFI - Project Management in Agile Organizations @ Tele2 User stories are the primary object that carry the customer’s requirements through the value stream – from needs analyses through code and implementation.
- 51. User Story Format A <role> can <action> or As a <role> I want to <action> So that <value> A company can pay for a subscription with a credit card. As a consumer I can see my daily energy usage so that I can lower my energy costs. 51NFI - Project Management in Agile Organizations @ Tele2
- 52. Card, Conversation, Confirmation 52NFI - Project Management in Agile Organizations @ Tele2
- 53. Why User Stories? • User stories emphasize verbal communication. • User stories are comprehensible by everyone. • User stories are the right size for planning. • User stories work for iterative development. • User stories encourage deferring detail. • User stories support opportunistic design. • User stories encourage participatory design. • User stories build up tacit knowledge. 53NFI - Project Management in Agile Organizations @ Tele2
- 54. User Stories should be: • A function – not an implementation • Independent – Not linked to other stories. • Negotiable – A base for discussion. • Valuable – For an identified user/customer/stakeholder. • Possible to estimate – The developers must understand what is needed. • Right size • Verifiable 54NFI - Project Management in Agile Organizations @ Tele2
- 55. Everything is not user stories • Descriptions of user interface (UI) • Descriptions of (API) • .. 55NFI - Project Management in Agile Organizations @ Tele2
- 56. Constraints & non-functional requirements NFI - Project Management in Agile Organizations @ Tele2 Source: www.agileproductdesign.com 56
- 57. Define constraints on cards. • Do not make it hard to internationalize the software if needed later. • The new system must use our existing order database. • The software must run on all versions of Windows. • The system must achieve uptime of 99.999%. • The system must manage 200 transactions / second. 57NFI - Project Management in Agile Organizations @ Tele2
- 58. Dean Leffingwells Model 58NFI - Project Management in Agile Organizations @ Tele2
- 59. Use Case /User Stories • Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. • Stories, on the other hand, are not intended to outlive the iteration in which they are added to the software. While it is possible to archive story cards, many teams simply rip them up. 59NFI - Project Management in Agile Organizations @ Tele2
- 60. Personas NFI - Project Management in Agile Organizations @ Tele2 60
- 61. Virtual customer visits NFI - Project Management in Agile Organizations @ Tele2 61
- 62. 62NFI - Project Management in Agile Organizations @ Tele2 Estimating requirements
- 63. Story Points and velocity 63NFI - Project Management in Agile Organizations @ Tele2 • Story Point can be equal to Ideal Development Day • Velocity = (average) storypoints per sprint
- 64. 64NFI - Project Management in Agile Organizations @ Tele2
- 65. Agile contracts
- 66. An Agile System 66NFI - Project Management in Agile Organizations @ Tele2 Your vendors Your customers Your company The Agile System
- 67. Basics in an agile agreement • Delivery in frequent releases. • Demo of progress per release. • The customer re-prioritize the backlog before each sprint. • The project can be started before a complete specification is ready. • Requirements (backlog) may change. • Time and cost fixed, not scope. 67Agila kontrakt, Knowit 2013.05.29
- 68. Would you use an agile agreement? 68Agila kontrakt, Knowit 2013.05.29
- 69. Agile – from customer perpective Plus • Flexibility – adaptive to changes in scope • Time to market • Exploratory approach. • Matches internal agile way of working • Innovative vendor feedback Minus • No warranty for delivery of scope within time and cost. • Requires an active buyer. • Requires knowledge on agile. 69Agila kontrakt, Knowit 2013.05.29
- 70. Agile – from vendor perspective Plus • Minimized risk • Encourages innovation • Closer customer relation Minus • Value bases pricing will not work. 70Agila kontrakt, Knowit 2013.05.29
- 71. Risks with agile contracts • Price and time control! – To much flexibility – Unclear constraints 71Agila kontrakt, Knowit 2013.05.29
- 72. Agreement models • Fixed price • T&M • T&M with shared risk • Almegas “Agila standardavtal” • Vested 72Agila kontrakt, Knowit 2013.05.29
- 73. 73Agila kontrakt, Knowit 2013.05.29
- 74. 74 1. Focus on Outcomes, Not Transactions 2. Focus on the What, Not the How 3. Agree on Clearly Defined and Measurable Outcomes 4. Optimize Pricing Model Incentives 5. Governance Structure Should Provide Insight, not Merely Oversight Agila kontrakt, Knowit 2013.05.29
- 75. Fixed Price or T&M Passive buyer Active buyer Fixed Scope Open Scope FP FP T&M T&M Agilt Vested 75Agila kontrakt, Knowit 2013.05.29
- 76. How to select vendor • Trust • Cultural fit • Team competence • Team productivity • Price per hour 76Agila kontrakt, Knowit 2013.05.29
- 77. Empower Teams © Jurgen Appelo version 1.05 management30.com
- 79. View #2: Empower Teams Teams can self-organize, and this requires empowerment, authorization, and trust from management. 79
- 80. self-organizing teams Agile software development works because of 80
- 81. self-organization is often complex, not chaotic Sometimes it needs a little management management self-organization 81
- 82. Delegation “Delegation (or deputation) is the assignment of authority and responsibility to another person (normally from a manager to a subordinate) to carry out specific activities.” http://en.wikipedia.org/wiki/Delegation 82
- 83. Situational Leadership http://en.wikipedia.org/wiki/Situational_leadership_theory Four different “leadership styles” 1. Telling 2. Selling 3. Participating 4. Delegation Work your way to level 4 83
- 84. Situational Leadership However… It might be good to distinguish between informing people (push your opinion) vs. consulting them (pull their opinions) 84
- 85. 1. Tell: make decision as the manager 2. Sell: convince people about decision 3. Consult: get input from team before decision 4. Agree: make decision together with team 5. Advise: influence decision made by the team 6. Inquire: ask feedback after decision by team 7. Delegate: no influence, let team work it out The Seven Levels of Authority 85
- 86. flow from left to right 86
- 87. controlled by the manager Authority boards are 87
- 88. 1. Find Delegation Poker Cards, and Delegation Poker Stories 2. One person picks a story and reads it out loud OR tell a story from personal experience 3. Everyone choose (privately) one of the 7 cards 4. After everyone has decided, show all cards 5. Everyone earns points except the highest minority (see examples…) Game: Delegation Poker 88
- 89. 5. Keep track of the points people earned (optional) 6. Let both highest and lowest motivate their choices 7. Play it again for the same topic (optional) 30 minutes Game: Delegation Poker 89
Editor's Notes
- #87: The nice thing about this approach is that there is an urge to make things flow from left to right, just like a regular task board.
- #89: l
- #90: Make it clear that the most value in this game is achieved by discussing the lowest and highest card values that were chosen. The other stuff (calculating points and playing again for the same topic) is optional.