How Agile Works. Agile defined. Agile Process. Agile Manifesto

Transcription

1 How Agile Works Agile defined Agile Process Breaks work into chunks Prioritize chunks by business value Builds highest value chunks in a time-boxed iteration called a Sprint Delivered chunks are working, ready to be deployed software Deployed when stakeholder says there is enough business value to go to market Agile Manifesto 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 docs 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

2 Agile Process process Key Ideas in Agile From Ron Jeffries Key Ideas in Agile Key Ideas in Agile Putting people with needs in direct contact with people who can fulfill those needs Populating projects with all the needed people and capabilities to get the job done Building work incrementally and checking results as you go Preparing for and influencing the future but not predicting it Making tasks concrete and quickly finishing them Giving people work to do and the knowledge to do it, not pushing them around like pawns on a chessboard Focusing on providing value frequently and rapidly, not solely on cost 2

3 Scrum Scrum on a Page Release Backlog Roles Stakeholders Product Owner Scrum Master Team Artifacts Product Backlog Release Backlog Sprint Backlog Blocks List Information Radiator Meetings Product Planning Release Planning Sprint Planning Daily Scrum Sprint Review Meetings Concept inspired by William Wake s Scrum on a Page, Definitions Who does what? Roles and Responsibilities Stakeholders Input to product business objectives Product Owner Defines the what and why; checks team addresses the problem completely Delivery Team Owns the solution Scrum Master Help Product Owner Team and Delivery Team work together 3

4 Stakeholders Types of Stakeholders Anyone who can give input to the business objectives of the product. Principals End Users Partners Insiders Champion the need for your software and have the authority to acquire and deploy it. Personally interact with your software. Make your product work in real life, such as operations teams and also business partners and system integrators. Are in your own organization; such as developers, support engineers, sales, architecture, and marketing teams. Get inside consumer s mind Outside In Development Understand your stakeholders Align with stakeholder goals Define success in your stakeholders terms Understand organizational context Make products consumable - Outside-in Software Development, Carl Kessler and John Sweitzer 4

5 The customer is always moving, changing, and if you re not out there all the time trying to understand the functional and emotional needs of consumers, your design will simply fall flat. - Matthew May Product Owner Builds the roadmap and prioritizes features in collaboration with: Business Leaders Stakeholders Scrum Master Functional representatives from the team Product Owner Does What? Interfaces with the Product Manager Owns the product and release backlog but does not decide alone what is in it and how it s prioritized Organizes and facilitates product planning sessions with Product Manager, stakeholders and team to generate themes and epics Product Owner Does What? Organizes and facilitates the release planning session with stakeholders and team to generate the user stores Attends the Sprint planning session to answer any team questions Does not decide what is in the Sprint backlog Connects team with customers 5

6 Product Owner Does What? Clarifies questions from team from a business point of view Removes blockers from business view Should attend the retrospective when invited. The product owner does not manage the team. They manage themselves. PM? PO? PMs and POs form a team. They have responsibilities to serve the delivery team. They collaborate on how to meet these responsibilities. Must always meet the 20 minute rule. Product Owner Responsibilities Assess product opportunities Define the problem from the customer and user point of view Do NOT define the solutions Do NOT take delivery responsibility from the team Scrum Master Does What? Facilitates Sprint Planning, Retrospectives & Daily Standups Is the conscience of the team Keeps blocked list and solves blocking issues with and for the team Makes sure the team has what they need to succeed Keeps the information radiator up to date 6

7 Scrum Master Is not a project manager (Team manages itself) Does not have authority over the team (Team makes decisions) Always asks the question: How are the Product Owner and the Team doing? Challenges the organization, Plays a key role in the change Team Add self organizing and ownership bits here. Teams Unleashing Innovation Exercise Collaboration Process Quick Exercise (A) 1. Form pairs 2. Assign one as boss, the other as worker 3. The boss can give the following commands: Go, Stop, Right, Left, Faster, Slower 4. The worker must follow the boss s commands 5. Goal: 60 steps in two minutes, circle the room at least once 6. The boss can command the worker, but can t touch the worker 7

8 Quick Exercise (B) 1. Everyone is a worker and responsible for figuring out how to proceed during the exercise 2. Goal: 60 steps in two minutes, circle the room at least once Unleashing Innovation Exercise Retrospective Collaboration Process Self Directed or Self Organizing Leadership, management, and team involvement very different: Encourages a collaborative environment All roles support one another Everyone stands and falls together Whole Team Concept stakeholders marketing sales line of business delivery team ( dev & test & ) architecture support 8

9 Leadership & Business Process Whole Team and Delivery Team Delivery Team Does What? Whole Team: Involved but not personally committed to delivery May be involved in planning & retrospectives May observe daily standups Delivery Team: Committed to delivery Active participants in planning & retrospective Active participant in daily standup Delivery Team Whole Team Takes ownership of delivery Identifies and removes obstacles Estimates the bigness of the user stories Decides what stories should be completed in the sprint Delivers done, done, done stories Keeps technical debt low Helps each other succeed Holds each other accountable Improves their process Create a Trusting Environment Trust and Ownership Model When you're in a trusted environment, teams tend to innovate better, more quickly and overall transaction costs are much lower. Trust Failure No One Cares Command & Control Energy & Innovation Team Trusted Team Accountable Leader Freed Conflict Sue McKinney Control Low Team Does as Instructed No Ownership Leader / Process is Bottleneck Team Demotivated Mired in Bureaucracy & Wasted Effort Team/Individual Ownership High 9

10 Requires a Trusting Environment Requires a Trusting Environment Leader s View The team won't let me down The team understands what we need They will do the right thing They will tell me if they need help Individuals within the Team We understand the vision and the need We are jointly committed to meeting our goals We stand or fall together We have ownership Discovery Team Product Owner 80% Developer / Arch 20% Interaction Designer 20% Continuous Innovation Business Owner Stakeholder Product Owner 20% Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint n Developer / Arch 80% Interaction Designer 80% Discovery Team Responsible for continuous innovation Works ahead of the delivery team May be temporary Set up when needed Disband when not needed 10

11 Agile Organizational Structure SYM Organizational Structure Product Manager Product Strategy Product Roadmap Launch Readiness Discovery Team Product Owner Product Backlog Release Backlog Delivery Team Dev Drives Continuous Innovation on Project Architect UX Developer Product Manager Product Strategy Product Roadmap Launch Readiness Discovery Team Product Owner Product Backlog Release Backlog Delivery Team Dev Drives Continuous Innovation on Project Architect UX Developer Scrum Master, Developers and Testers Sprint Backlog Program Manager Agile Readiness Risk, Dependency and Interlock Mgmt Scrum Master, Developers and Testers Sprint Backlog Development Manager External Unblocking Resource Management Program Manager Role Ensures team readiness Ties business processes together Ensures business processes and systems support engaged Works with Development Manager to: Identify and mitigate dependencies and risks Ensure interlocks are well understood Process optimization Development Manager Role Ensures Delivery Team is connected to customers Facilitates team resource management, dependency management, team interlocks, and syncing of sprints Collaborates with Scrum Master on agile process optimization Provides development Test Tools and Systems. Focuses on sprint risks. 11

12 Release PGM Role Focuses on release risks. Works with Development Manager on agile process optimization. Facilitates Stakeholder meetings. Launch PGM Role Tying all the business processes together to get to market. Ensures all business processes and supporting systems are engaged for the release. Manages the Launch PGM checklist. Scale Product Team Program Manager Scrum of Scrums Engineering Project Status Reporting Stage Gate Updates PMT Product Manager Product Owner 1 Delivery Team 1 Services Development Dev. Manager 1 Product Owner 2 Delivery Team 2 Delivery Team n Delivery Team n+1 Sales Customers PDT Leader (Product Manager) Stage Gating Finance IT Delivery Team n+2 Dev. Manager 2 Delivery Team n+m Marketing Support 12

13 BnR Scale Definitions Roles Summary Roles in a Nutshell Stakeholders: give input on the product business objectives Product owner: facilitates understanding and prioritizing based on business value Scrum Master: ensures that the team is functional and productive Team: self-organizes to get the work done 13

14 Roles Your Questions? Where are my requirements? Leading Agile User Stories User Stories Collaboration Model Collaboration Process Two Kinds of User Stories Epic User Stories (aka Epics) High level features of a product Fit into a release All epics form the Product Backlog User Stories Breakdown of Epics into smaller features Fit into a sprint (iteration) User Stories form Release Backlog 14

15 User Story Defined What does a user story look like? A concise, written description of a piece of functionality that will be valuable to a stakeholder. As a <role>, I can <goal> so that <business value> Roles As a <role>, I want <goal> so that <business value> Avoid the user as different stakeholders have different needs Use roles so that you do not miss epics Teams may develop a set of user roles to help define relevant epics (personas) Uer Roles Don t focus only on the end-user role. Consider other stakeholder types as well. Principals End Users Partners Insiders Stakeholders who champion the need for your software and have the authority to acquire and deploy it. Stakeholders who personally interact with your software. Stakeholders who make your product work in real life, such as operations teams and also business partners and system integrators. Stakeholders within your own organization; such as developers, support engineers, sales, architecture, and marketing teams. 15

16 Goals As a <role>, I want <goal> so that <business value> Goal is what the role can do Valuable to a stakeholder Doesn't say how, but what Business Value As a <role>, I want <goal> so that <business value> Justifies the value of the epic Clarifies why a feature is useful Can influence how a feature should function Helps prioritize the epic in the backlog Can lead to other useful features that support stakeholder s goals Example: NASA Epic Epic Example As an < astronaut > I want to < write easily with a ball point pen while in Zero gravity > So that < I can record key information that I might otherwise forget > NASA specified and developed, at great expense, a ball point pen that Apollo astronauts could use in space where gravity would not make the ink flow. Russian cosmonauts used crayons. Moral: specify what you want to achieve, not how to achieve it. 16

17 Where s my plan? Student syndrome It is based on estimates like this: Task Local Safety Student syndrome Multitasking It is based on estimates like this: Task Local Safety But we do this: 20-30% time increase to do each task Greater loss on complex tasks Task 1 Task 2 Task 3 Local Safety Task

18 The Effects of Multitasking To do two things at once is to do neither. - Publilius Syrus How does Agile help? Short Planning Cycles - Immediate Action Rapid Releases Iterations every 2 weeks Scrum Meeting Daily Tasks < 16 hours What s a good plan? 18

19 What s an Agile plan? Project Management It is a bad plan that admits to no modifications. -- Publilius Syrus (ca. 42 BCE) In the form of three backlogs: Product Backlog Epics and Themes for Product Release Backlog Release Theme and User Stories Sprint Backlog User Stories and tasks planned for the Sprint (iteration) Product Planning Product Backlog: Develop Release Themes Develop Product Epic User Stories Categorize Product Epics by Release Themes Prioritize based on Business Value Place Epics into releases What s a Theme? Who: Stakeholders, Business and Team 19

20 What are Themes? Release themes are based on business objectives Themes should embody highest business value needs of the stakeholders and the product Focus on stakeholder success Focus on product welfare: reduce technical debt, increase maintainability, etc. Why Create Themes? Provide a common goal for the whole team Used to provide focus for a release Used to prioritize and de-prioritize work A well-known release theme provides a vision to team Theme Examples Stop wasting time on backups. Your data is safe with Symantec. Galapagos Themes: No Unprotected Data Appliance Scalability Performance Improvements New Platforms Example Theme: Appliance Scalability Epic: As a Backup Admin, I want to store my backup images on a single high-capacity appliance so that What is the business value for this epic? 20

21 Example Theme: No unprotected data Epic: As an IT admin I can readily discover my unprotected data So that.. What is the business value for this epic? Example Theme: New Platforms Epic: As an IT Exec, I want to NBU to backup all my data regardless of backup system or application type so that.. What is the business value for this epic? Product Planning Start Up Opportunities & Ideas Product Backlog Input Opportunities and H H M M M Output Who Ideas Prioritized Product Backlog (Themes and Product Epics) Business, Product Owner, Dev Team representatives Exercise: Practicum Pick a project. Pick a project L 21

22 Create a Product Backlog Release Planning, part 1 Select a Product Owner Identify themes for your product Write 1-2 epics for your product As a <role>, I want <goal> so that <business value> Product Backlog H H M M M L Release Backlog Theme H/P H/D H/D M/D H/P H/P M/P M/P M/P M/D M/P M/P L/D L/P Input Product Backlog Output Prioritized Release Epics marked as differentiating or parity Who Business, Product Owner, Delivery Team Exercise: How long will it take Agile Measure of of Size. to read the latest Harry Potter book?. to drive to Austin, TX? Agile measures of size: Story Points 22

23 Story Points Higher Value Lower Story Points Release Planning, part Meeting 2 2 The bigness of a task Points are unit-less Influenced by How hard it is How much there is As a buyer, I want to be able to have some but not all items in my cart gift wrapped. 8 Release Backlog Theme H/P H/D H/P H/D Input Output Who Prioritized Epics Estimated and Prioritized Release Backlog (story points) Delivery Team using planning poker Release Burn Up Chart Using Story Points The Plan Done for sprint results against total release backlog The Plan What we hope for before validating team velocity Original Plan End Date The Goal The sum of points for all stories Goal Plan Velocity Iterations 23

24 Story Points Higher Value Lower Story Points Higher Value Lower Story Points Higher Value Lower Using Story Points Adding to The Plan Using Story Points - A Realistic Outlook Mean Velocity Additional Stories Original Plan End Date New Planned End Date Original Goal New Goal Plan Velocity Actual Velocity Original Goal New Goal Plan Velocity Actual Velocity Outlook 50 Actual Delivery Iterations Iterations Using Story Points - What are our Options? Sprint Planning 400 Option End Dates Iterations Original Goal New Goal Reduced Goal Plan Velocity Actual Velocity Outlook WP WIP WD New User Stories Input Release Backlog Output Sprint Backlog Definition of Done3 Architecture Spike Information Radiator Who Delivery Team 24

25 Information Radiator Visual representation of progress Display of: Work Planned (Product, Release and Sprint) Work in Progress Work Done User Stories to mitigate risk User Stories to gather information to make future decisions Information Radiator Sprint 2 WP WIP WD New User Stories Release Backlog Epic: Information Radiator Information Radiator Sprint 2 WP WIP WD Release Backlog Epic: Sprint 2 WP WIP WD Release Backlog Epic: BH BH AK AK CO CO CO AK New User Stories New User Stories 25

26 Example Information Radiator Example Daily scrums Each team member answers: What did you do yesterday? What are you doing today? What are your blocking issues? No problem solving! Leave after 15 minutes! Team Defines Done, Done, Done Consider: No showstoppers All errors that the team has not agreed to are removed Code is unit tested, function tested, system tested, performance tested, tested end-to-end A meaningful stakeholder review has been conducted Can Done3 Really be Done? This puts a high premium on: Valuable, maintained, nested automation Appropriate coverage (e.g. 80%) True test-driven development Avoiding technical debt Continuous integration Really understanding what quality looks like 26

27 Example: Done4 Example: Done4 Jeff Sutherland (co-creator of Scrum), said PatientKeeper: It took us four years to get done, done, done, done. Patientkeeper provides safety critical patient management software What does Done, Done, Done, Done mean? It is fully developed It is fully tested It has no Severity 1s or 2s It has been deployed before a release in a client environment Example: Done4 They ship A major release every 3 months A minor release every month And minor updates once a week Consider the competitors, teams of developers and they cannot achieve the work flow Patientkeeper does. Sprint review meeting Held the last day of the sprint Attended by team and stakeholders Team demos done user stories to stakeholders Requests feedback Team holds retrospective Updates the process for the next sprint 27

28 retrospective Leadership Role Agile is continuous learning and adaptive planning. Keep? Drop? Add? What surprised you? - M. Buckingham Leadership Role A good agile project will build something that meets customers needs but may be different from original plans. Summary summary - Jim Collins 28

29 Scrum on a Page Agile defined (IBM) Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, stable, time-boxed iterations. Roles Artifacts Meetings Stakeholders Product Backlog Product Planning Release Backlog Release Planning Product Owner Sprint Backlog Sprint Planning Scrum Master Blocks List Daily Scrum Team Information Radiator Sprint Review Meetings Concept inspired by William Wake s Scrum on a Page, Agile Defines needs from a customer point of view Delivers business value in chunks Relies on stakeholder feedback Embraces change Continuous learning A framework for conversation No accumulation of technical debt Agile Decreases time to value Increases revenues Reduces cost and waste Delivers products and services that customers love Increases customer loyalty Delivers the right value 29

30 Leadership Role Agile is continuous learning and adaptive planning. - M. Buckingham 30