Lean Agile Scrum Business Value  Development and Delivery using Agility Brenden McGlinchey Software Done Right, Inc. [emai...
<ul><li>High yield software engineering team </li></ul><ul><ul><ul><ul><li>Active Customer Involvement </li></ul></ul></ul...
Projects can be… challenging “ Fast - cheap - good - you can have any two.” “ A user will tell you anything you ask, but n...
Promise of Agility <ul><li>The Basic Promise is that Agility allows you to develop software successfully in the face of: <...
Wasted Effort <ul><li>The Standish Group  [1]   (famous for their Chaos Report) surveyed 1000 companies </li></ul><ul><li>...
Waterfall is a Powerful Attractor <ul><li>Waterfall </li></ul><ul><ul><li>Requirements, Analysis, Design, Code, Test, Depl...
Process-focused Development <ul><li>Legacy IT is organized by process area </li></ul><ul><ul><li>Systems Analysts </li></u...
Waterfall Observations <ul><li>Long delivery cycles encourages piling on of poorly prioritized requirements </li></ul><ul>...
Categorization of complexity in development projects Requirements Technology
Software Done Right Agile Methods Summarized <ul><li>Agile Manifesto for Values  [3] </li></ul><ul><ul><li>Individuals & i...
<ul><li>Deming’s 14 points for management  [4]   </li></ul><ul><li>Create constancy of purpose toward improvement of produ...
<ul><ul><li>Taiichi Ohno, the mastermind of Toyota Production System, identified seven types of manufacturing waste  [5] <...
Short Cycle-Time <ul><li>10-day increments (Sprints) of completed software </li></ul><ul><ul><li>Ensures Focus on highest ...
Built-in Quality  <ul><li>Test-Driven Development  </li></ul><ul><ul><li>Create automated testing  then  create code that ...
Agile Methods: Scrum  <ul><li>Lightweight Framework that Produces Heavyweight Results </li></ul><ul><li>3 Roles </li></ul>...
Complex Adaptive System *Agile Management for Software Engineering, David J. Anderson  [7]
Sprint/ Iteration Business Value Engine Daily Standup Sprint 2 weeks Epics Stories <ul><li>Reports </li></ul><ul><li>Work ...
Key Meetings <ul><li>Sprint Planning </li></ul><ul><ul><li>The Product Owner and team agree on the subset of the Product B...
Key Roles and Responsibilities <ul><li>The Scrum Team consists of: </li></ul><ul><li>Product Owner </li></ul><ul><li>Scrum...
Key Roles and Responsibilities Product Owner <ul><li>Product Owner </li></ul><ul><li>Defines the features of the product, ...
Key Roles and Responsibilities: ScrumMaster <ul><li>ScrumMaster </li></ul><ul><li>Helps resolve impediments </li></ul><ul>...
Key Roles and Responsibilities: Team <ul><li>Team </li></ul><ul><li>Cross-functional, 7  ±  2 members </li></ul><ul><li>Ne...
Product Backlog <ul><li>Prioritized collection of functionality, technology, issues </li></ul><ul><li>Can be a list ordere...
Product Manager Board
Epics, Stories, Tasks <ul><li>Epics (High-level Capability Statements) </li></ul><ul><ul><li>Contain 1 or more stories </l...
Roadmap to Business Value (Epics) Epics: High-level capability statements  (White Cards) Prioritized by Business Value (wh...
Roadmap to Business Value (Roles) <ul><li>Roles: </li></ul><ul><li>Defined to ensure Line-of-sight with System Users </li>...
Roadmap to Business Value (Stories) <ul><li>Stories: </li></ul><ul><li>Unit of work = “Story”, similar to: </li></ul><ul><...
Analysis: Product  Feature  Story <ul><li>Analysis is primarily about Decomposition </li></ul><ul><ul><li>Our Product deco...
Agile Requirements Frontburner - Work committed to in current iteration (Sprint)
Real-time View of Business Value Delivery Stories Tasks
Agile-V Provides Real-time View of Sprint
Critical to Success <ul><li>Short Cycle-time </li></ul><ul><li>Collocated, collaborative team w/clear line-of-sight to bus...
References <ul><li>Jim Johnson, Standish Group (http://ciclamino.dibe.unige.it/xp2002/talksinfo/johnson.pdf) </li></ul><ul...
Contact Information Brenden McGlinchey [email_address]
Upcoming SlideShare
Loading in...5
×

Agile Pmi 102108 Final

453

Published on

This is a presentation that was given to the Project Management Institute of Metrolina. The goal is exposure to the fundamental ideas of Lean/Agile/Scrum software development.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
453
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile Pmi 102108 Final

  1. 1. Lean Agile Scrum Business Value Development and Delivery using Agility Brenden McGlinchey Software Done Right, Inc. [email_address]
  2. 2. <ul><li>High yield software engineering team </li></ul><ul><ul><ul><ul><li>Active Customer Involvement </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Emergent Design </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Built-in Quality </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Iterative Release </li></ul></ul></ul></ul><ul><li>We use Lean/Agile/Scrum as our ideology and process to maximize ROI and minimize errors and waste. </li></ul><ul><li>www.softwaredoneright.net </li></ul>
  3. 3. Projects can be… challenging “ Fast - cheap - good - you can have any two.” “ A user will tell you anything you ask, but nothing more.” “ The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.” “ Anything that can be changed will be changed until there is no time left to change anything.” “ The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.”
  4. 4. Promise of Agility <ul><li>The Basic Promise is that Agility allows you to develop software successfully in the face of: </li></ul><ul><ul><li>Unknown/Moving Requirements </li></ul></ul><ul><ul><ul><li>Goal: to produce a product that is useful at the time of delivery </li></ul></ul></ul><ul><ul><ul><li>Delays analysis and design until “needed’ </li></ul></ul></ul><ul><ul><ul><li>Reduces waste </li></ul></ul></ul><ul><ul><li>Constrained Resources </li></ul></ul><ul><ul><ul><li>Goal: to produce the best product you can with what you’ve got </li></ul></ul></ul><ul><ul><ul><li>Constant reprioritization </li></ul></ul></ul><ul><li>Scrum adds the Promise that: </li></ul><ul><ul><li>The team will adapt its processes to improve their abilities to deliver quality </li></ul></ul>
  5. 5. Wasted Effort <ul><li>The Standish Group [1] (famous for their Chaos Report) surveyed 1000 companies </li></ul><ul><li>Features Actually Used: </li></ul><ul><ul><li>7% Always </li></ul></ul><ul><ul><li>13% Often </li></ul></ul><ul><ul><li>16% Sometimes </li></ul></ul><ul><ul><li>19% Rarely </li></ul></ul><ul><ul><li>45% Never </li></ul></ul><ul><li>Conclusion: 64% wasted effort? </li></ul>
  6. 6. Waterfall is a Powerful Attractor <ul><li>Waterfall </li></ul><ul><ul><li>Requirements, Analysis, Design, Code, Test, Deploy </li></ul></ul><ul><li>For Management </li></ul><ul><ul><li>It is a “defined process” – thus “feels right” </li></ul></ul><ul><ul><li>It gives the illusion of control </li></ul></ul><ul><ul><ul><li>Of people </li></ul></ul></ul><ul><ul><ul><li>Of money </li></ul></ul></ul><ul><ul><li>Allows for “hands off” management </li></ul></ul><ul><li>For Developers </li></ul><ul><ul><li>They’re just “following a recipe” </li></ul></ul><ul><ul><li>They’re just left alone for long periods </li></ul></ul>
  7. 7. Process-focused Development <ul><li>Legacy IT is organized by process area </li></ul><ul><ul><li>Systems Analysts </li></ul></ul><ul><ul><li>Enterprise Data Specialists </li></ul></ul><ul><ul><li>UI Designer Specialists </li></ul></ul><ul><ul><li>UI Developers </li></ul></ul><ul><ul><li>Mid-tier Developers </li></ul></ul><ul><ul><li>Database Developers </li></ul></ul><ul><ul><li>Systems Testers </li></ul></ul><ul><li>Encourages process decomposition and sub-optimization (vs. optimizing the whole) </li></ul><ul><ul><li>Builds silos of experts with misaligned goals </li></ul></ul><ul><ul><li>Discourages collaboration </li></ul></ul><ul><ul><li>Creates Hand-offs & Waterfall phase gates (backed up queues) </li></ul></ul><ul><ul><li>Creates the “blame game” [2] </li></ul></ul><ul><ul><li>Quality may improve slightly, but at the cost of speed </li></ul></ul><ul><ul><li>… is there a better way? </li></ul></ul>
  8. 8. Waterfall Observations <ul><li>Long delivery cycles encourages piling on of poorly prioritized requirements </li></ul><ul><li>Requirements are not fully understood even after inspection & sign-off </li></ul><ul><li>Requirements change often during software development </li></ul><ul><li>Users know what they want only after they see an initial version of the software </li></ul><ul><li>New tools and technologies make implementation strategies unpredictable </li></ul><ul><ul><li>Technology changes occur faster than traditional software development projects can complete (12-18 months), so software is obsolete before projects complete </li></ul></ul>
  9. 9. Categorization of complexity in development projects Requirements Technology
  10. 10. Software Done Right Agile Methods Summarized <ul><li>Agile Manifesto for Values [3] </li></ul><ul><ul><li>Individuals & interactions > over processes & tools </li></ul></ul><ul><ul><li>Working software > comprehensive documentation </li></ul></ul><ul><ul><li>Customer collaboration > contract negotiation </li></ul></ul><ul><ul><li>Responding to change > following a plan </li></ul></ul><ul><li>Lean Principles for Vision </li></ul><ul><ul><li>Add value to customer • Empower the team </li></ul></ul><ul><ul><li>Eliminate waste • Build integrity in </li></ul></ul><ul><ul><li>Amplify learning • Optimize the whole </li></ul></ul><ul><ul><li>Decide as late as possible • Deliver Fast </li></ul></ul><ul><li>Scrum for Process Framework </li></ul><ul><ul><li>3 Meetings </li></ul></ul><ul><ul><li>3 Artifacts (Documents) </li></ul></ul><ul><ul><li>3 Roles </li></ul></ul><ul><li>XP for Quality and Discipline </li></ul><ul><ul><li>Paired programming </li></ul></ul><ul><ul><li>Test driven development </li></ul></ul>
  11. 11. <ul><li>Deming’s 14 points for management [4] </li></ul><ul><li>Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs. </li></ul><ul><li>Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change. </li></ul><ul><li>Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place. </li></ul><ul><li>End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust. </li></ul><ul><li>Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs. </li></ul><ul><li>Institute training on the job. </li></ul><ul><li>Institute leadership (see Point 12 and Ch. 8). The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers. </li></ul><ul><li>Drive out fear, so that everyone may work effectively for the company (see Ch. 3). </li></ul><ul><li>Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service. </li></ul><ul><li>Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force. </li></ul><ul><ul><li>Eliminate work standards (quotas) on the factory floor. Substitute leadership. </li></ul></ul><ul><ul><li>Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership. </li></ul></ul><ul><li>Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality. </li></ul><ul><li>Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective (see Ch. 3). </li></ul><ul><li>Institute a vigorous program of education and self-improvement. </li></ul><ul><li>Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job. </li></ul>Origins of Lean Thinking: Deming
  12. 12. <ul><ul><li>Taiichi Ohno, the mastermind of Toyota Production System, identified seven types of manufacturing waste [5] </li></ul></ul><ul><ul><li>Overproduction = Extra Features </li></ul></ul><ul><ul><ul><li>Code for today </li></ul></ul></ul><ul><ul><li>Inventory = Requirements </li></ul></ul><ul><ul><ul><li>Requirement detail unfolded “just-in-time” </li></ul></ul></ul><ul><ul><li>Extra Processing Steps = Extra Steps </li></ul></ul><ul><ul><ul><li>Code directly from stories, get verbal clarification directly from customers </li></ul></ul></ul><ul><ul><li>Motion = Finding Information </li></ul></ul><ul><ul><ul><li>Collocation, including customers </li></ul></ul></ul><ul><ul><li>Defects = Defects Not Caught by Tests </li></ul></ul><ul><ul><ul><li>Test first; both developer tests and customer tests </li></ul></ul></ul><ul><ul><li>Waiting = Waiting, Including Customers </li></ul></ul><ul><ul><ul><li>Deliver in small increments </li></ul></ul></ul><ul><ul><li>Transportation = Handoffs </li></ul></ul><ul><ul><ul><li>Highest bandwidth form of communication is 2 people at a whiteboard, not backlogs of documentation </li></ul></ul></ul><ul><ul><li>(from Poppendieck & Poppendieck [6] ) </li></ul></ul>Software Development Waste
  13. 13. Short Cycle-Time <ul><li>10-day increments (Sprints) of completed software </li></ul><ul><ul><li>Ensures Focus on highest priority work </li></ul></ul><ul><ul><ul><li>Don’t build what you don’t need </li></ul></ul></ul><ul><ul><ul><li>What do you want to see in 10 days? </li></ul></ul></ul><ul><ul><li>Builds in change-tolerance </li></ul></ul><ul><ul><ul><li>What do you want to see in future sprints? </li></ul></ul></ul><ul><ul><ul><li>Leverages feedback </li></ul></ul></ul><ul><ul><li>Team reflects every 10 days </li></ul></ul><ul><ul><ul><li>What are we doing well? </li></ul></ul></ul><ul><ul><ul><li>What can we do better? </li></ul></ul></ul><ul><ul><ul><li>Feedback now vs. “post-mortem” </li></ul></ul></ul>
  14. 14. Built-in Quality <ul><li>Test-Driven Development </li></ul><ul><ul><li>Create automated testing then create code that makes tests pass </li></ul></ul><ul><ul><li>Make code coverage visible </li></ul></ul><ul><ul><li>Run suite of tests with every build </li></ul></ul><ul><li>Frequent (hourly builds) </li></ul><ul><li>Paired-programming (Real-time code review) </li></ul><ul><li>Creates an environment that allows architectures and designs to emerge </li></ul><ul><ul><li>Agile Principle “ The best designs and architectures emerge from self-organized teams” </li></ul></ul>
  15. 15. Agile Methods: Scrum <ul><li>Lightweight Framework that Produces Heavyweight Results </li></ul><ul><li>3 Roles </li></ul><ul><ul><li>Product Owner </li></ul></ul><ul><ul><li>ScrumMaster </li></ul></ul><ul><ul><li>Development Team </li></ul></ul><ul><li>3 Meetings </li></ul><ul><ul><li>Sprint Planning (4 hours) </li></ul></ul><ul><ul><li>Daily Scrum (15 minutes) </li></ul></ul><ul><ul><li>Sprint Demo & Retrospective (4 hours) </li></ul></ul><ul><li>3 Artifacts </li></ul><ul><ul><li>Product Backlog </li></ul></ul><ul><ul><li>Sprint Backlog </li></ul></ul><ul><ul><li>Sprint Burn-down </li></ul></ul>
  16. 16. Complex Adaptive System *Agile Management for Software Engineering, David J. Anderson [7]
  17. 17. Sprint/ Iteration Business Value Engine Daily Standup Sprint 2 weeks Epics Stories <ul><li>Reports </li></ul><ul><li>Work in Progress </li></ul><ul><li>Metrics </li></ul><ul><li>Impediments </li></ul>Meaningful Increment of Product Release 3-4 Sprints Sprint Planning <ul><li>Sprint </li></ul><ul><li>Product Demo </li></ul><ul><li>Team Retrospective </li></ul>
  18. 18. Key Meetings <ul><li>Sprint Planning </li></ul><ul><ul><li>The Product Owner and team agree on the subset of the Product Backlog to work on this sprint. Result is the Sprint Backlog </li></ul></ul><ul><li>Sprint Review </li></ul><ul><ul><li>The Team shows their Product to their Product Owner and other Stakeholders. The purpose is to “show off” and get buyoff and feedback </li></ul></ul><ul><li>Daily Standup (Daily Scrum) </li></ul><ul><ul><li>The team understands its status every day in order to do a daily “inspect and adapt” cycle </li></ul></ul><ul><li>Sprint Retrospective </li></ul><ul><ul><li>The team (or Scrum Team) analyzes their own process and modifies it as necessary </li></ul></ul>
  19. 19. Key Roles and Responsibilities <ul><li>The Scrum Team consists of: </li></ul><ul><li>Product Owner </li></ul><ul><li>ScrumMaster </li></ul><ul><li>Team </li></ul>
  20. 20. Key Roles and Responsibilities Product Owner <ul><li>Product Owner </li></ul><ul><li>Defines the features of the product, decides on release date and content </li></ul><ul><li>Is responsible for the profitability of the product (ROI) </li></ul><ul><li>Constantly Prioritizes the Product Backlog </li></ul><ul><li>Can change features and priority every sprint </li></ul><ul><li>Accepts or rejects work results </li></ul>
  21. 21. Key Roles and Responsibilities: ScrumMaster <ul><li>ScrumMaster </li></ul><ul><li>Helps resolve impediments </li></ul><ul><li>Ensures that the team is fully functional and productive </li></ul><ul><li>Enables close cooperation across all roles and functions and removes barriers </li></ul><ul><li>Shields the team from external interferences </li></ul><ul><li>Ensures that the process is followed. Invites to daily scrum, iteration review and planning meetings </li></ul>
  22. 22. Key Roles and Responsibilities: Team <ul><li>Team </li></ul><ul><li>Cross-functional, 7 ± 2 members </li></ul><ul><li>Negotiates the iteration goal and specifies tasks </li></ul><ul><li>Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal </li></ul><ul><li>Organizes itself and its work </li></ul><ul><li>Demos work results to the Product Owner </li></ul>
  23. 23. Product Backlog <ul><li>Prioritized collection of functionality, technology, issues </li></ul><ul><li>Can be a list ordered by priority (only one thing in the top slot) </li></ul><ul><li>Issues are placeholders that are later defined as work </li></ul><ul><li>Emergent and prioritized </li></ul><ul><li>More detail on higher priority backlog </li></ul><ul><li>Product Owner responsible for priority </li></ul><ul><li>Anyone can contribute </li></ul><ul><li>Posted Visibly </li></ul><ul><li>Derived from Requests </li></ul>
  24. 24. Product Manager Board
  25. 25. Epics, Stories, Tasks <ul><li>Epics (High-level Capability Statements) </li></ul><ul><ul><li>Contain 1 or more stories </li></ul></ul><ul><ul><li>Business Value/Business Speak </li></ul></ul><ul><li>Stories: </li></ul><ul><ul><li>Fundamental increment of Business Value </li></ul></ul><ul><ul><li>Business Value/Business Speak </li></ul></ul><ul><ul><li>Validation-centric: MUST define “DONE”! </li></ul></ul><ul><li>Tasks: </li></ul><ul><ul><li>Small chunks of work that must be completed to validate story </li></ul></ul><ul><ul><li>Team creates and estimates during planning session </li></ul></ul>
  26. 26. Roadmap to Business Value (Epics) Epics: High-level capability statements (White Cards) Prioritized by Business Value (which can change!) Tightly Coupled w/ Vision Unfold into 1 or more stories Epic: Jim Advisor can create a new financial scenario for Joe Customer that will allow for clarity in investment decisions
  27. 27. Roadmap to Business Value (Roles) <ul><li>Roles: </li></ul><ul><li>Defined to ensure Line-of-sight with System Users </li></ul><ul><li>(Green Cards) </li></ul><ul><li>Helps keep focus on: </li></ul><ul><ul><li>Real business value flows </li></ul></ul><ul><ul><li>Real users of the system </li></ul></ul><ul><ul><li>Help reduce waste! </li></ul></ul><ul><ul><li>Don’t build what you don’t need </li></ul></ul><ul><li>Role: Jim Advisor </li></ul><ul><li>20 years experience </li></ul><ul><li>Uses a wants/needs/expects approach </li></ul><ul><li>Uses self-defined allocation models </li></ul>
  28. 28. Roadmap to Business Value (Stories) <ul><li>Stories: </li></ul><ul><li>Unit of work = “Story”, similar to: </li></ul><ul><ul><li>1 or more Use Case Steps </li></ul></ul><ul><ul><li>1 or more features </li></ul></ul><ul><li>Stories are written in business language… </li></ul><ul><li>“ As a <some role>, </li></ul><ul><li>I want <some feature>, </li></ul><ul><li>so that <some business value or functionality>” </li></ul><ul><li>Card, Conversation, Confirmation </li></ul>Story: Jim wants to track graphically the rate at which money managers are changing over time so that an advisor can make appropriate decisions. Done: Jim can see a representation of money manager changes over time
  29. 29. Analysis: Product Feature Story <ul><li>Analysis is primarily about Decomposition </li></ul><ul><ul><li>Our Product decomposes into Features </li></ul></ul><ul><ul><li>Features are implemented by doing stories </li></ul></ul><ul><ul><ul><li>But not all stories are feature-driven </li></ul></ul></ul><ul><ul><li>Our Project’s work can be seen as a collection of Stories </li></ul></ul><ul><ul><ul><li>But we’re only going to focus on the feature-driven ones </li></ul></ul></ul><ul><li>Incremental Analysis is (basically): </li></ul><ul><ul><li>Find the Features, then </li></ul></ul><ul><ul><li>Find the Stories </li></ul></ul><ul><li>Then we use the stories to drive development… </li></ul>Made up of Implemented by Product Features Story
  30. 30. Agile Requirements Frontburner - Work committed to in current iteration (Sprint)
  31. 31. Real-time View of Business Value Delivery Stories Tasks
  32. 32. Agile-V Provides Real-time View of Sprint
  33. 33. Critical to Success <ul><li>Short Cycle-time </li></ul><ul><li>Collocated, collaborative team w/clear line-of-sight to business value </li></ul><ul><li>Focus on validation of completed product, not process </li></ul><ul><li>Built-in Quality </li></ul>
  34. 34. References <ul><li>Jim Johnson, Standish Group (http://ciclamino.dibe.unige.it/xp2002/talksinfo/johnson.pdf) </li></ul><ul><li>See Ron Pereira, “Stop the Finger Pointing” (http://lssacademy.com/2007/02/07/stop-finger-pointing/ ) </li></ul><ul><li>See ( http://AgileManifesto.org ) </li></ul><ul><li>W. Edwards Deming, Out of the Crisis , (1986), MIT Press. </li></ul><ul><li>Taiichi Ohno, The Toyota Production System: Beyond Large-Scale Production , (1988), Productivity Press. </li></ul><ul><li>M. Poppendieck & T. Poppendieck, Lean Software Development: An Agile Toolkit , (2003), Addison-Wesley </li></ul><ul><li>David J. Anderson, Agile Management for Software Engineering , (2004), Prentice Hall </li></ul>
  35. 35. Contact Information Brenden McGlinchey [email_address]

×