Agile and lean product development the fundamentals
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile and lean product development the fundamentals

on

  • 2,439 views

 

Statistics

Views

Total Views
2,439
Views on SlideShare
2,439
Embed Views
0

Actions

Likes
3
Downloads
197
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile and lean product development the fundamentals Presentation Transcript

  • 1. Delivering value early and often, giving ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve The Fundamentals
  • 2. Copyright © 2008 Russell Pannone. All rights reserved. 2
  • 3.  What's in it for You  The Business Proposition  Mastering Agile and Lean Product (System-Software) Development with Scrum  User Stories Applied  5 Levels Agile Planning  Monitoring Progress and Business Value-Added 3
  • 4. Class Exercise 4
  • 5. How to Organize a Children's Party Copyright © 2008 Russell Pannone. All rights reserved. 5
  • 6. What Type of System is Ours? Chaotic Ordered Complex Copyright © 2008 Russell Pannone. All rights reserved. 6
  • 7. Four Spheres of Influence 1. Stakeholder Needs and Business Processes 2. Architecture and Design 3. Technology CMU/SEI-2002-TR-009, ESC-TR-2002-009, July 2002 4. Program/Project Management These four spheres are simultaneously defined and traded through the life of an agile and lean project because a decision in one sphere will inform and likely constrain the decisions that can be made in another sphere 1. Sphere 1 - Stakeholder Needs and Business Processes: This sphere denotes requirements (including quality attributes such as performance, security and reliability), end-user business processes, business drivers and operational environment. 2. Sphere 2 - Architecture and Design: This sphere denotes the essential elements of the system, the relationships between them, and how they fit with the enterprise system. The elements include structure, behavior, usage, functionality, performance, resilience, reuse, comprehensibility, economic and technologic constraints and tradeoffs. 3. Sphere 3 - Technology: This sphere denotes available and emerging technology and products, non- development items and relevant standards. 4. Sphere 4 - Program/Project Management: This sphere denotes the management aspects of the project. These aspects consider the cost, schedule and risk of building, fielding and supporting the solution. Key to these management aspects are the cost, schedule and risk of changing the necessary business processes. 7 Copyright © 2008 Russell Pannone. All rights reserved.
  • 8. A Common Delivery Framework Common Delivery Framework Work Type USAIT performs multiple types of work: A common delivery framework Standard Practices (programs, projects, enhancements, of introduces a consistent governance break-fix, maintenance operations) work prioritization, selection, Solution Approach communication and representation of These work progression to completion that work‟s types are supported by standard practices whichCommittee, (i.e. Executive Steering establish expectations of theCommittee, Portfolio Steering minimum activities that must be conducted Committee, Infrastructure Steering to ensure a viable solution is created (i.e. Architecture Review Board, requirements, funding, testing, Enterprise Change Management deployment) At the core of the framework is the solution approach – where the actual work gets done. The framework itself may establish guidelines to aide in choosing a solution approach, but does not dictate any particular approach. The team doing the work is empowered to make this choice! 8
  • 9. Roadmap to “being” agile and lean Objectives  Delivery of commercial or operational value early and often, giving ourselves the best opportunity to beat the Agile competition to market, realize revenue and discover Coaching & insights that we can use to help us improve Training  Cross-functional, collaborative and adaptive teams developing and delivering value-added product (system- software) increments in a continuous flow from requirements to deployment  Avoiding the high cost of discovering defects late in the Scrum Cultural Agile development cycle by discovering defects early in the Coaching & Renewal Adoption Training development cycle which is accomplished by eliminating waste, increasing feedback loops and developing code from the point of view of provability and outside-in design  Emphasis is placed on the need for teams to nurture group cohesion, and paying attention to norms that serve as a guide that strengthens positive practices Organizational Change  Minimizing frustration levels and making the art and Management science of system-software development enjoyable and not a burden or death march  The what, why, and how of agile/lean product (system- software) development and delivery is not one persons vision alone; to become reality it needs to be a "shared" vision through negotiation and compromise between individuals, the team and the organization Copyright © 2008 Russell Pannone. All rights reserved. 9
  • 10. Copyright © 2008 Russell Pannone. All rights reserved. 10
  • 11. SS Agile SS Agile 11
  • 12. Our highest priority is to satisfy the customer through early and The most efficient and effective method of conveying information to and continuous delivery of valuable software. within a development team is face-to-face conversation. Welcome changing requirements, even late in development. Agile processes promote sustainable development. The sponsors, Agile processes harness change for the customer's competitive developers, and users should be able to maintain a constant pace advantage. indefinitely. Deliver working software frequently, from a couple of weeks to a Continuous attention to technical excellence and good design enhances couple of months, with a preference to the shorter timescale. agility. Business people and developers must work together daily Simplicity--the art of maximizing the amount of work not done--is throughout the project. essential. Build projects around motivated individuals. Give them the The best architectures, requirements, and designs emerge from self- environment and support they need, and trust them to get the job organizing teams. done. At regular intervals, the team reflects on how to become more effective, Working software is the primary measure of progress. then tunes and adjusts its behavior accordingly. 12
  • 13.  What's in it for You  The Business Proposition  Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise  User Stories Applied  5 Levels Agile Planning  Monitoring Progress and Business Value-Added 14
  • 14. Recent Data Points Russell Pannone (805) 910-6481 15
  • 15. 16
  • 16. 17
  • 17. Copyright@ 2008 Russell Pannone. All rights reserved.
  • 18. Gain feedback Accept Lower through change project risk iterative without through incremental slowing higher value down visibility delivery Delivering value early and often, giving ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve 19
  • 19. Copyright © 2005, Mountain Goat Software 1. Agile puts the Product Owner (aka “the business” or customer representative) in the driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the development process. 2. Agile allows the business to quickly react to changing market conditions and needs – The only thing constant in today‟s economy is change. Businesses need to be able to make quick course corrections in order to survive. 3. Agile provides visibility into the development process – For many customers software development is a dark art. They don‟t have the background in order to understand the technical details and in most cases the development team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development lifecycle, providing enhanced visibility. 4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system- software product Copyright © 2008 Russell Pannone. All rights reserved. 20
  • 20. Tooling Project - Product Backlog 21
  • 21. 1. Performing tasks to complete the story 2. Completing the story based on story acceptance criteria and team's definition of done 3. Developing and delivering commercial or operational value incrementally Copyright © 2008 Russell Pannone. All rights reserved. 22
  • 22. Reduce Waste Feedback Loops • Remove what isn’t of • Sprint Review & Planning value to the customer • Sprint Retrospective • Quicker delivery of value • Daily Scrum & ROI 23
  • 23.  What's in it for You  The Business Proposition  Mastering Agile and Lean Product (System- Software) Development  User Stories Applied  5 Levels Agile Planning  Monitoring Progress and Business Value-Added 24
  • 24. Candidate Practices A practice is a common approach for doing something with a specific purpose in mind
  • 25. Usage scenario – When a project team wants to “be” agile they self-organize & self-direct around the 9 practices – The team then selects 1 or more practice to apply to their work at hand Benefits – Iterative & Incremental adoption of “being” agile and lean – Gives team a context and narrow focus to rally around – Provides a non-threatening easy way for team to learn together, “be” agile, apply an iterative and incremental approach, and get better at what we do 26
  • 26. Copyright © 2008 Ivar Jacobson Consulting. Sprint/Iteration Copyright © 2008 Russell Pannone. All rights reserved. 27
  • 27. Traditional Development  implied sequential “waterfall”  time delay in obtaining feedback Iterative & Incremental Development and Delivery
  • 28. What is Iterative and Incremental Development? Iterative development is a time-boxed approach that “cycles" through a set of activities, from understanding requirements to producing and refining an increment of the product Copyright © 2008 Russell Pannone. All rights reserved. 29
  • 29. 30
  • 30. Scrum Explained “The… „relay race‟ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth— may better serve today’s competitive requirements.”- Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986 In Scrum you work in iterations delivering value-adding results incrementally Copyright © 2008 Russell Pannone. All rights reserved. 31
  • 31. Scrum Roles & Definitions (continued on next slide) Copyright © 2005 Mountain Goat Software. Copyright © 2008 Russell Pannone. All rights reserved. 32
  • 32. Scrum Roles & Definitions (continued on next slide) Copyright © 2005 Mountain Goat Software. Copyright © 2008 Russell Pannone. All rights reserved. 33
  • 33. Scrum Roles & Definitions (continued from previous slide) Copyright © 2005 Mountain Goat Software. Copyright © 2008 Russell Pannone. All rights reserved. 34
  • 34. Copyright © 2008 Ivar Jacobson Consulting. Copyright © 2008 Ivar Jacobson Consulting. Copyright © 2008 Ivar Jacobson Consulting. Copyright © 2008 Russell Pannone. All rights reserved. 35
  • 35. Copyright © 2008 Russell Pannone. All rights reserved. 36
  • 36. Class Exercise 37
  • 37. Copyright © 2008 Russell Pannone. All rights reserved. 38
  • 38. Kanban Board Pending WIP Done Story Story Story Story Story Story Define Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Build & Story Test Design Implement Story Story Story Story Story Story Story Story Story Story Story Story Code Story Story Copyright © 2008 Russell Pannone. All rights reserved.
  • 39.  What's in it for You  The Business Proposition  Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise  User Stories Applied  5 Levels Agile Planning  Monitoring Progress and Business Value-Added 40
  • 40. User Stories Business Story Points Priority Story A 1 5 Story B 2 8 Story C 3 1 Story D 4 8 Story E 5 2 Story F 6 2 Story G 7 2 Story H 8 8 Story I 9 5 Story J 10 1 Copyright@ 2008 Russell Pannone. All rights reserved. 41
  • 41. A story is a “placeholder” for a requirement formulated as a brief description written in the everyday language of the customer or user describing desired functionality; containing just enough information so that the product team can produce a reasonable estimate of the effort to implement it Copyright@ 2008 Russell Pannone. All rights reserved. 42
  • 42. Five (5) “whys” analysis applied as an effective reflective technique in the world of “being” agile and lean 1. Why is our Product Owner, unhappy? Because we did not deliver the product release and business value when we said we would 2. Why were we unable to meet the agreed upon timeline or schedule for delivery? The product took much longer to develop than we thought it would 3. Why did it take so much longer? Because we underestimated the complexity and uncertainty of the stories 4. Why did we underestimate the complexity and uncertainty? Because we did not have acceptance criteria associate with each story, our stories were not at the right level of detail and we did not realistically size each story prior to committing to a schedule for delivering the release 5. Why didn't we do this? Because the higher powers were still working under the traditional waterfall planning mental-model, as a result we felt pressure to work faster and skipped steps  Solution: We clearly need to review and improve our approach to writing stories, prioritizing stories, sizing stories, deriving/estimating duration and committing to a schedule for delivering the product >>>>> Then get buy-in and visible support from the higher powers Copyright © 2008 Russell Pannone. All rights reserved. 43
  • 43. Copyright@ 2008 Russell Pannone. All rights reserved. 44
  • 44. Where do Optional Stories come from Optional Optional Bus Strategy Use Cases Business Model System Requirements Customer Functional Business Partner & Non-Functional Product Owner Team Solution/IT-Services Copyright © 2008 Russell Pannone. All rights reserved. 45
  • 45. Characteristics of good stories As a <who> I want <what> so that <why>  A good story is negotiable, testable, estimatable, commercially or operationally value-adding, cohesive and loosely-coupled  It is not an explicit contract for features or functionality; rather stories are short descriptions of functionality, the details of which are to be refined in a conversation between the Product Owner (aka, the business or customer) and the development team  The challenge comes in learning to include just enough detail to be able to prioritize and estimate the size of story and minimize ambiguity Story1 Story4 As an eligible user, I want to pay the As an eligible user, I want to access my Story11 onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list that I can access my driver’s record in information to keep it current of assembled answers to questions the future asked most frequently of the DMV Story5 Story2 Story12 As an eligible user, I want to access my As an eligible user, I want to create a As an eligible user, I want to be able record and change any or all of my unique user name and password so find an address for my local DMV information to keep it current that my access is limited to my record office and print the results and to track activity and payment Story6 Story13 Story3 As an eligible user, I want multiple As the application, I want to maintain As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits correct DMV site that require payment Copyright © 2008 Russell Pannone. All rights reserved. 46
  • 46. Meeting the Product Owner’s Conditions-of-Satisfaction  Outside-In-Design > One of the key characteristics that make stories so fitting for delivering value early and often is that they focus on describing the source of value to the Product Owner, instead of the mechanics of how that value is delivered  Stories strive to convey the Product Owner wants and needs, the who, what and why and not the specifics of the solution or the details about “how” the team will implement the story Copyright © 2008 Russell Pannone. All rights reserved. 47
  • 47. Story Size  The fact of the matter is some stories can be too big, some can be too small, and some can be just right  Stories that are too big are called Epics  Epics are difficult to work with because they frequently contain multiple stories  Epics typically fall into one of two categories:  The compound story  The complex story Story As an eligible user, I want to access my record, so that I can verify that it is Epic (compound story) correct As an eligible user, I Story As an eligible user, I want to access my want to view , add, record and delete any or all of my information, so that I can keep it change or delete my current DMV information so that Story As an eligible user, I want to access my I can keep it current record and change any or all of my information, so that I can keep it current Copyright © 2008 Russell Pannone. All rights reserved. 48
  • 48. Complex Story  Unlike the compound story, the complex story is a story that is inherently large and cannot easily be disaggregated into a set of constituent stories  If a story is complex because of uncertainty associated with it, you should estimate the size of the story at the highest range of your estimating scale (1, 2, 3, 5, 8, 13, 21, 34)  Then prior to the sprint where you are going to pull it in have an investigate story to more clearly understand what the solution involves to deliver this story Epic (complex story) As an eligible user, I want multiple payment options to pay my fees so that I am able to access the features of the DMV site that require payment For example, suppose the team is given the story depicted above, but none of the developers has ever done credit card processing before. The team would then decide to disaggregate the story like this: • Investigate credit card processing over the web • A user can pay with a credit card In this case the first story will send one or more developers on a spike. When complex stories are split in this way, always define a time-box around the investigative story, or spike. Copyright © 2008 Russell Pannone. All rights reserved. 49
  • 49. Acceptance Criteria  Acceptance criteria, represents the details for a story and specifies the desired behavior and functionality the system-software must implement  Acceptance criteria answer the question, “How will I know when I’m done with the story?”  Acceptance criterion is high level tests to verify and validate the completeness of a story or stories implemented during a Sprint/Iteration, expressed in a business domain language  These tests are created ideally through collaboration between business customers, business analysts, testers and developers; however the Product Owner (aka, the business or customer) is the primary owner of these conditions-of-satisfaction  Test cases and acceptance criteria are two different things  Test cases answer the questions, “How do I test and what are the test steps?” Copyright © 2008 Russell Pannone. All rights reserved. 50
  • 50.  Depiction of the user interface or maybe even a report layout, is just as much a part of the details behind a story as acceptance criteria  Wireframes and screen mockups are often attached to stories as a basic visual guide used in interface design by the development team  Low fidelity diagrams depicting a candidate solution may also be attached to stories to visually communicate its design 51 Copyright © 2008 Russell Pannone. All rights reserved.
  • 51. Product Backlog high priority low Five factors to consider when prioritizing 1.The commercial or operational value of the delivered story 2.Degree of uncertainty - the amount and significance of learning and new knowledge gained by developing the story; focused on requirements and technology 3.The amount of risk removed by developing and delivering the story – focused on schedule, budget, scope, operation, technology 4.Dependencies – stories that must be developed together and are delivered together to provide value to the customer 5.The cost of developing and delivering the story Copyright © 2008 Russell Pannone. All rights reserved. 52
  • 52. Story Prioritizing Exercise 53
  • 53. Story Points: Relative Measure of the Size of a Story Sizing stories is often confused with "how long" it takes to implement it but in fact "how big" and "how long" are very different things  The "how long" is highly dependent on which developer is performing the work  The "how big" bears no relationship to who is performing the work Copyright © 2008 Russell Pannone. All rights reserved. 54
  • 54. Copyright © 2008 Russell Pannone. All rights reserved. 55
  • 55. 56 Copyright © 2008 Russell Pannone. All rights reserved.
  • 56. Why are We Doing This 1. Refine team‟s understanding of requirements (stories) 2. Estimate level-of-effort 3. Derive high-level cost, schedule, and scope 57
  • 57. Look, See, Imagine, Act Remove Ambiguity Copyright © 2008 Russell Pannone. All rights reserved.
  • 58. Copyright © 2008 Russell Pannone. All rights reserved.
  • 59. Agile & Lean Product Development and a Project Delivery Framework ROM estimate of Cost, Schedule, Scope Commit to Cost, Schedule, Scope Copyright © 2008 Russell Pannone. All rights reserved. 60
  • 60. Velocity is a measure of Deriving estimates a team‟s  4 iterations based rate of on team velocity progress per  Each iteration 3 weeks long Iteration  12 weeks total duration  Estimated cost of $15,000 per iteration  Estimated total cost of $60,000 Copyright © 2008 Russell Pannone. All rights reserved. 61
  • 61. 1. Selecting Stories from the Product Backlog based on the team’s velocity 2. Identifying the tasks to realize a selected Story 3. Estimating the level-of- effort required to complete the task Copyright © 2008 Russell Pannone. All rights reserved. 62
  • 62. Copyright © 2008 Russell Pannone. All rights reserved. 63
  • 63. Copyright © 2008 Russell Pannone. All rights reserved. 64
  • 64. Copyright © 2008 Russell Pannone. All rights reserved. 65
  • 65. Copyright © 2008 Russell Pannone. All rights reserved. 66
  • 66. Copyright © 2008 Russell Pannone. All rights reserved. 67
  • 67. Team Velocity Copyright © 2008 Russell Pannone. All rights reserved. 68
  • 68. If my velocity, as a painter is 30–40 points every 2 days, and I have 10 homes to paint, like this, I have a total of 490 points (49 points X 10 houses = 490 total points) ---------------------------------------------------------------------- I can then take the mean of my velocity which is 36 and figure out how many sprints/iterations I would have 490 / 36 = 13.6111 ---------------------------------------------------------------------- Since my sprints/iterations are 2 days long it will take me 27 – 28 calendar days to complete this job 2 (days per sprint) X 13.6111 (number of sprints) = 27.2 69
  • 69. Technique for Deriving Story Points Planning Poker
  • 70. Story Sizing Exercise 71
  • 71.  What's in it for You  The Business Proposition  Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise  User Stories Applied  5 Level Agile Planning  Monitoring Progress and Business Value-Added 72
  • 72. Candidate Practices A practice is a common approach for doing something with a specific purpose in mind
  • 73. 5 levels of Agile Planning What, Who, Why, When, Constraints, Product Vision Assumptions Releases – Date, Theme/Feature Set, Product Roadmap Objective, Development Approach Iteration, Team Capacity, Stories, Priority, Release Planning Size, Estimates, Definition of Done Stories – Tasks, Definition of Done Iteration Planning Level-of Effort, Commitment 1. What did I do yesterday? Daily Planning 2. What will I do today? 3. What is blocking me?
  • 74. Integrating Agile and Lean System-Software Development with a Project Delivery Framework
  • 75. A common delivery framework Common Delivery Framework USAIT performs multiple types of work: A common delivery framework (programs, projects, enhancements, of introduces a consistent governance Work Type break-fix, maintenance operations) work prioritization, selection, Standard Practices These work types are supported by of communication and representation standard practices whichto completion that work‟s progression establish Solution Approach (i.e. ESC, PSC, ISC, ARB, ECM, expectations of the minimum activities phases) that must be conducted to ensure a viable solution is created (i.e. requirements, funding, testing, deployment) At the core of the framework is the solution approach – where the actual work gets done. The framework itself may establish guidelines to aide in choosing a solution approach, but does not dictate any particular approach. The team doing the work is empowered to make this choice! 76 Delivery Framework
  • 76. Agile & Lean Product Development and a Project Delivery Framework ROM estimate of Cost, Schedule, Scope Commit to Cost, Schedule, Scope Copyright © 2008 Russell Pannone. All rights reserved. 77
  • 77. Product Vision What, Who, Why, When, Constraints, Assumptions Releases – Date, Theme/Feature Set, Product Roadmap Objective, Development Approach Iteration, Team Capacity, Stories, Priority, Release Planning Size, Estimates, Definition of Done Stories – Tasks, Definition of Done Iteration Planning Level-of Effort, Commitment 1. What did I do yesterday? Daily Planning 2. What will I do today? 3. What is blocking me?
  • 78. Product Vision  What  Who (Stakeholders)  Why  When  Constraints & Assumptions “If you don't know where you are going, that's where you'll end up.” -Yogi Berra 79
  • 79. Product Vision  What  Summary of the major benefits and features the product will provide  Gives context to the reader  Defines the business context for the product. In which domain is it going to function (for example, telecom or bank) and what market—who are the users? State whether the product is being developed to fulfill a contract or if it is a commercial product.  Who (Stakeholders)  There are a number of stakeholders with an interest in the development and not all of them are end users. Think of this as outside-in-design.  Customer/Consumer  Other vested interests  Provides the background and justification for why the requirements are needed Continued on Next Page 80
  • 80. Continued from Previous Page Why Need and opportunity When  Begins the process of project scheduling by illuminating the stakeholders’ time expectations regarding the product. Also helps you dig into their expectations by defining the circumstances in which the new product would be used. Constraints & Assumptions  Express the constraints under which the project is undertaken. These constraints impact risk and cost. They could be things like external interfaces that the product must adhere to, standards, certifications or a technical approach employed for strategic reasons, such as using a certain database technology or distribution mechanisms.
  • 81. What, Who, Why, When, Constraints, Product Vision Assumptions Releases – Date, Theme/Feature Set, Objective, Product Roadmap Development Approach Iteration, Team Capacity, Stories, Priority, Release Planning Size, Estimates, Definition of Done Stories – Tasks, Definition of Done Iteration Planning Level-of Effort, Commitment 1. What did I do yesterday? Daily Planning 2. What will I do today? 3. What is blocking me?
  • 82. If you don't know where you are going, it's impossible to determine the best way to get there. A product roadmap is an essential tool for product planning and development. Product roadmaps outline when products are scheduled for release and include an overview of their primary and secondary features. 83
  • 83. Tooling Life Cycle Reporting Life Cycle Planning/ Receiving/ Inventory Tool End of Procurement Sourcing Warehousing Management Utilization Life Tool received OEM or tooling Need for a TB submits SC will bin at PIT Tool utilized deems tool tool & quantity PR through or check out USA dock On aircraft unserviceable defined Sceptre For use SC receives and Tool shipped bins the tool Kit back to USA Process Steps TS sources TP generates PO Tool then & gets quote/ that transmits management checked in/out, PIT delivery date to OEM Tool Sup checks calibrated, shipped, for damage & Reported on calibration Tool repeatedly Tool Sup marks Repair tool BER, lost OEM confirms or other price & LT Tool Sup gives stores next steps Theme Tool changed OEM makes Stores stocks To inactive tool part or ships to another location Note: some of these = System Transaction Process steps may Tool held TS = Technical Sourcer vary at non-maintenance In case of TP = Technical Purchaser Tool arrives Future need Tool Sup = Tooling Supervisor at new station stations For it TB = Tooling BA LT = Lead Time USA = US Airways Tool received SC = Stock Clerk in Sceptre 84 BER = Beyond Economical Repair
  • 84. The Product Backlog is Derived from the Product Vision and Roadmap © Scott Ambler, 2004 85
  • 85. Copyright © 2005, Mountain Goat Software 1. Agile puts the Product Owner (aka “the business” or customer representative) in the driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the development process. 2. Agile allows the business to quickly react to changing market conditions and needs – The only thing constant in today‟s economy is change. Businesses need to be able to make quick course corrections in order to survive. 3. Agile provides visibility into the development process – For many customers software development is a dark art. They don‟t have the background in order to understand the technical details and in most cases the development team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development lifecycle, providing enhanced visibility. 4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system- software product Copyright © 2008 Russell Pannone. All rights reserved. 86
  • 86. Tooling Project - Product Backlog 87
  • 87. Characteristics of good stories As a <who/user> I want <what/goal> so that <why/reason>  A good story is negotiable, testable, estimatable, commercially or operationally value-adding, cohesive and loosely-coupled  It is not an explicit contract for features or functionality; rather stories are short descriptions of functionality, the details of which are to be refined in a conversation between the Product Owner (aka, the business or customer) and the development team  The challenge comes in learning to include just enough detail to be able to prioritize and estimate the size of story and minimize ambiguity Story1 Story4 As an eligible user, I want to pay the As an eligible user, I want to access my Story11 onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list that I can access my driver’s record in information to keep it current of assembled answers to questions the future asked most frequently of the DMV Story5 Story2 Story12 As an eligible user, I want to access my As an eligible user, I want to create a As an eligible user, I want to be able record and change any or all of my unique user name and password so find an address for my local DMV information to keep it current that my access is limited to my record office and print the results and to track activity and payment Story6 Story13 Story3 As an eligible user, I want multiple As the application, I want to maintain As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits correct DMV site that require payment Copyright © 2008 Russell Pannone. All rights reserved. 88
  • 88. Acceptance Criteria  Acceptance criteria, represents the details for a story and specifies the desired behavior and functionality the system-software must implement  Acceptance criteria answer the question, “How will I know when I’m done with the story?”  Acceptance criterion is high level tests to verify and validate the completeness of a story or stories implemented during a Sprint/Iteration, expressed in a business domain language  These tests are created ideally through collaboration between business customers, business analysts, testers and developers; however the Product Owner (aka, the business or customer) is the primary owner of these conditions-of-satisfaction  Test cases and acceptance criteria are two different things  Test cases answer the questions, “How do I test and what are the test steps?” Copyright © 2008 Russell Pannone. All rights reserved. 89
  • 89.  Depiction of the user interface or maybe even a report layout, is just as much a part of the details behind a story as acceptance criteria  Wireframes and screen mockups are often attached to stories as a basic visual guide used in interface design by the development team  Low fidelity diagrams depicting a candidate solution may also be attached to stories to visually communicate its design Copyright © 2008 Russell Pannone. All rights reserved. 90
  • 90. What, Who, Why, When, Constraints, Product Vision Assumptions Releases – Date, Theme/Feature Set, Product Roadmap Objective, Development Approach Iteration, Team Capacity, Stories, Priority, Size, Release Planning Estimates, Definition of Done Stories – Tasks, Definition of Done Iteration Planning Level-of Effort, Commitment 1. What did I do yesterday? Daily Planning 2. What will I do today? 3. What is blocking me?
  • 91. Product Vision Product Roadmap Iteration Plan Product Backlog Review and Adapt Develop Release Plan Copyright © 2008 Russell Pannone. All rights reserved. Adapted from “Agile Project Management” Jim Highsmith Copyright 2004 92
  • 92. The Release Plan The Release Plan is determined from the team’s velocity; initially this is an estimate, a best guess until the team’s actual velocity can be determined from historical data We create the Release plan from  The size estimate  The velocity (“size per iteration”) The Release plan shows what will be worked on in each iteration  Each iteration contains approximately the same number of story points and is time boxed by iteration length Copyright © 2008 Russell Pannone. All rights reserved. 93
  • 93. Components of the Release Plan The Release Plan is comprised of: 1. The release theme 2. The release content 3. Business value statement for the release 4. The release timeline Copyright © 2008 Russell Pannone. All rights reserved. 94
  • 94. Content 95
  • 95. Creating the Release Plan (continue from previous slide) Once we have identified the theme and content for each release, we can prepare a brief summary of the Business Value to be delivered at each release Example: Release 1- This release implements ……. and allows users to ……………….. Copyright © 2008 Russell Pannone. All rights reserved. 96
  • 96. Release Timeline  Stories at the right level of detail  Prioritized stories  Sized stories  Deriving/estimating duration and cost to deliver product Copyright © 2008 Russell Pannone. All rights reserved. 97
  • 97. Velocity is a measure of a Deriving estimates team’s rate of  4 iterations based progress per on team velocity Iteration  Each iteration 3 weeks long  12 weeks total duration  Estimated cost of $15,000 per iteration  Estimated total cost of $60,000 Copyright © 2008 Russell Pannone. All rights reserved. 98
  • 98. What, Who, Why, When, Constraints, Product Vision Assumptions Releases – Date, Theme/Feature Set, Product Roadmap Objective, Development Approach Iteration, Team Capacity, Stories, Priority, Release Planning Size, Estimates, Definition of Done Stories – Tasks, Definition of Done Level-of Effort, Iteration Planning Commitment 1. What did I do yesterday? Daily Planning 2. What will I do today? 3. What is blocking me?
  • 99. 1. Selecting Stories from the Product Backlog based on the team’s velocity 2. Identifying the tasks to realize a selected Story 3. Estimating the level-of- effort required to complete the task Copyright © 2008 Russell Pannone. All rights reserved. 100
  • 100. Copyright © 2008 Russell Pannone. All rights reserved. 101
  • 101. Working software & demo Unit test Code review Installer Tests Functional Performance Regression Documentation User docs/Online help Internal design docs Release notes API documents Copyright@2009 SolutionsIQ All rights Reserved 102 Copyright@ 2008 Russell Pannone. All rights reserved.
  • 102. What, Who, Why, When, Constraints, Product Vision Assumptions Releases – Date, Theme/Feature Set, Product Roadmap Objective, Development Approach Iteration, Team Capacity, Stories, Priority, Release Planning Size, Estimates, Definition of Done Stories – Tasks, Definition of Done Iteration Planning Level-of Effort, Commitment 1. What did I do yesterday? Daily Planning 2. What will I do today? 3. What is blocking me?
  • 103. 1. Performing tasks to complete the story 2. Completing the story based on story acceptance criteria and team's definition of done 3. Developing and delivering commercial or operational value incrementally Copyright © 2008 Russell Pannone. All rights reserved. 104
  • 104. Reduce Waste Feedback Loops • Remove what isn’t of • Sprint Review & Planning value to the customer • Sprint Retrospective • Quicker delivery of value • Daily Scrum & ROI 106
  • 105.  What's in it for You  The Business Proposition  Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise  User Stories Applied  5 Levels Agile Planning  Monitoring Progress and Business Value-Added 107
  • 106. Looking at SCRUM from a Different Perspective - Planning - Product Owner - Daily Standup - Scrum Master - Sprint Review - Team - Retrospective Progress Items Copyright © 2008 Russell Pannone. All rights reserved. 108
  • 107. Copyright@ 2008 Russell Pannone. All rights reserved. 109
  • 108. Velocity Chart Example 45 40 35 30 25 Velocity 20 15 10 5 0 1 2 3 4 5 6 7 8 9 10 Sprint 110 Copyright@ 2008 Russell Pannone. All rights reserved.
  • 109. Burndown Chart consists of Story Points | | | | | | | | | | | S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 On a Scrum project, the team tracks its progress against a release plan by updating a release burndown chart at the end of each Sprint. The horizontal axis of the release burndown chart shows the Sprints; the vertical axis shows the amount of work remaining at the start of each Sprint in Story points. Copyright@ 2008 Russell Pannone. All rights reserved. 111
  • 110. Burnup Chart Example 112 Copyright@ 2008 Russell Pannone. All rights reserved.
  • 111. Gain feedback Accept Lower through change project risk iterative without through incremental slowing higher value down visibility delivery Delivering value early and often, giving ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve 113
  • 112. Reduce Waste Feedback Loops • Remove what isn’t of • Sprint Review & Planning value to the customer • Sprint Retrospective • Quicker delivery of value • Daily Scrum & ROI 114
  • 113. Roadmap to “being” agile • Delivery of commercial or operational value early and often, giving ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve Agile • Cross-functional, collaborative and adaptive teams Coaching & developing and delivering value-added product Training (system-software) increments in a continuous flow from requirements to deployment • Avoiding the high cost of discovering defects late in the development cycle by discovering defects early in the Agile development cycle which is accomplished by Scrum Cultural Adoption Coaching & eliminating waste, increasing feedback loops and Renewal Training developing code from the point of view of provability and outside-in design • Emphasis is placed on the need for teams to nurture group cohesion, and paying attention to norms that serve as a guide that strengthens positive practices Organizational Change • Minimizing frustration levels and making the art and Management science of system-software development enjoyable and not a burden or death march • The what, why, and how of agile/lean product (system-software) development and delivery is not one persons vision alone; to become reality it needs to be a "shared" vision through negotiation and compromise between individuals, the team and the Copyright © 2008 Russell Pannone. All rights reserved. organization 115
  • 114. Agile workflow in DPaCE phases DPaCE Project Delivery Framework End End Discover (justify) Discover (justify) Plan (commit) Plan (commit) Control (actualize) Control (actualize) (assess) (assess) BTR TRR CARE KPIs Test Scripts & Results Enterprise Change Production Notification Signature Document Release Initial Product Sprint Backlog Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 ... 10 Groom Product Backlog Mapping Agile to DPacE