Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

SCGMIS Agile Business Analysis Workshop July 2014

Próximo SlideShare
The agile pmo v2
The agile pmo v2
Cargando en…3

Eche un vistazo a continuación

1 de 104 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)


Similares a SCGMIS Agile Business Analysis Workshop July 2014 (20)

Más reciente (20)


SCGMIS Agile Business Analysis Workshop July 2014

  1. 1. 1© Life Cycle Engineering 2014© Life Cycle Engineering 2014 The Business Analyst in an Agile Environment Presented by Justin Petite for SCGMIS
  2. 2. 2© Life Cycle Engineering 2014 • 12 years in a number of roles supporting software and the SDLC • Past 4+ years adapting and applying Agile and Scrum to SPAWAR projects • PMI – Agile Certified Practitioner • Scrum Alliance Certified Scrum Master • Scrum Alliance Certified Scrum Professional @JustinPetite JUSTIN PETITE
  3. 3. 3© Life Cycle Engineering 2014 STARTING LINEUP • 5 minutes • Confidence in your understanding of Agile • Without talking
  4. 4. 4© Life Cycle Engineering 2014 AFFINITY ESTIMATION • Visualize and create groups by relative scale • Comparison by subjective measure • Good for large groups, and large quantities • Intended to be fast, and just precise enough to get started More on this later…
  5. 5. 5© Life Cycle Engineering 2014 OBJECTIVES • Explore Agility, the Agile Manifesto, and Agile principles • Understand how business analysis fits into the Agile environment • Introduce personas and user stories • Experience a variety of analysis tools and techniques used on Agile projects
  6. 6. 6© Life Cycle Engineering 2014 System Requirements Software Requirements Analysis Design Code Test Operations “WATERFALL”
  7. 7. 7© Life Cycle Engineering 2014 MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT 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 documentation 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.
  8. 8. 8© Life Cycle Engineering 2014 AGILE An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders. Scott Ambler
  9. 9. 9© Life Cycle Engineering 2014 AGILITY Agility is the ability to both create and respond to change in order to profit in a turbulent business environment Agility is the ability to balance flexibility and stability Jim Highsmith Agile Project Management (2nd Edition, 2010)
  10. 10. 10© Life Cycle Engineering 2014 WHY AGILITY • Need to more effectively respond to change – Organizational needs – Market demands – Threats and opportunities • Manage evolutionary change to products, processes, and culture • Frequently and incrementally deliver value to reach a desired goal or outcome
  11. 11. 11© Life Cycle Engineering 2014 BENEFITS • Greater responsiveness to changing priorities • Measured increase in productivity • Lower costs • Managed risk through greater visibility • Increased customer satisfaction • Better overall quality • Improved team morale
  12. 12. 12© Life Cycle Engineering 2014 VALUE IN “WATERFALL” cumulativebusinessvalue time
  13. 13. 13© Life Cycle Engineering 2014 AGILE VALUE PROPOSITION A cumulativebusinessvalue time
  14. 14. 14© Life Cycle Engineering 2014 AGILE VALUE PROPOSITION B cumulativebusinessvalue time
  15. 15. 15© Life Cycle Engineering 2014 AGILITY
  16. 16. 16© Life Cycle Engineering 2014 AGILE PRINCIPLES 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  17. 17. 17© Life Cycle Engineering 2014 AGILE PRINCIPLES 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self- organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  18. 18. 18© Life Cycle Engineering 2014 AGILE METHODOLOGIES • Extreme Programming (XP) • Scrum • Kanban • Scrum-ban • Disciplined Agile Delivery (DAD) • Scaled Agile Framework (SAFe) • Dynamic Systems Development Method (DSDM) • Feature Driven Development (FDD) • Lean software development
  19. 19. 19© Life Cycle Engineering 2014 AGILE PRACTICES • Cross-functional teams • Timeboxed iterations • Story-driven modelling • Backlogs (product, release, sprint) • Acceptance Test Driven Development (ATDD) • Test Driven Development (TDD) • Continuous integration and deployment • Pair programming • Information radiators • And many, many others
  20. 20. 20© Life Cycle Engineering 2014 Accredited to Michael Sahota & Olaf Lewitz
  21. 21. 21© Life Cycle Engineering 2014 ETHOS
  22. 22. 22© Life Cycle Engineering 2014 Value (Releasable Product) Quality (Reliable, Adaptable Product) Constraints (Scope, Cost, Schedule) AGILE TRIANGLE Jim Highsmith
  23. 23. 23© Life Cycle Engineering 2014 AGILE METHODS DO: • Position us to be more responsive to changing priorities • Allow better predictability of output for the foreseeable time horizon • Improve accountability • Make priorities and risk calculations more transparent
  24. 24. 24© Life Cycle Engineering 2014 AGILE METHODS DON'T • Make engineers write more lines of code per day or designers create output faster • Preclude the need to make good organizational decisions about product, priorities, and customer needs • Allow the rest of the organization to assume they think they know what lies months ahead
  25. 25. 25© Life Cycle Engineering 2014 AGILE MYTHS • “Agile is the silver bullet for our organization!” • “Agile doesn’t scale, so it can’t work for our organization!” • “No more documentation or deadlines!” • “Since we don’t do things upfront, we have no design and poor architecture!” • “With so much rework going on, nothing new, and innovative gets worked on!” • “Agile makes us faster!”
  26. 26. 26© Life Cycle Engineering 2014 ORGANIZATIONAL AGILITY • More than just “doing Agile” • Discipline of managed change through continuous inspection, evaluation, and adaptation • Tailored to the organization • Leverages Agile methods appropriately at each level: – Individual – Team – Project – Program/Portfolio – Executive
  27. 27. 27© Life Cycle Engineering 2014 THE AGILE BUSINESS ANALYST • Analysis still essential to software development, regardless of project size, complexity, or methodology • Analysis is still about asking the right questions • Vital to the agile requirements decomposition paradigm • Has an immediate impact on development • Plays an integral role on the development team
  28. 28. 28© Life Cycle Engineering 2014 ITERATIVE & INCREMENTAL
  29. 29. 29© Life Cycle Engineering 2014 ITERATIVE & INCREMENTAL “Incrementing” builds a finished piece Assumes the customer has a fully formed idea of what they need Jeff Patton - 2008 know_what_i_want.html
  30. 30. 30© Life Cycle Engineering 2014 ITERATIVE & INCREMENTAL Jeff Patton - 2008 know_what_i_want.html “Iterating” builds something imperfect to validate and refine Iterating allows for less developed ideas to evolve and be refined
  31. 31. 31© Life Cycle Engineering 2014
  32. 32. 32© Life Cycle Engineering 2014 SCRUM • Framework: – Defined Roles – Ritual Meetings – Artifacts – Terminology • Emphasis: – Value – Delivery – Open communication – Team self-organization – Stakeholder Participation
  33. 33. 33© Life Cycle Engineering 2014 SCRUM TIMEBOXES • Release Planning • Sprint Planning • The Sprint • Daily Scrum • Sprint Review & Demo • Sprint Retrospective
  34. 34. 34© Life Cycle Engineering 2014 SCRUM ROLES • Scrum Master – Lead, promote, facilitate, organize, and coach Scrum – Remove impediments for the team • Product Owner – Own, manage, and communicate the Product Backlog – Advocate for the customer • Scrum Team – Turn work from the backlog into a “potentially shippable” increment of working software
  35. 35. 35© Life Cycle Engineering 2014 ANALYST PATTERNS
  36. 36. 36© Life Cycle Engineering 2014 ANALYST PATTERNS
  37. 37. 37© Life Cycle Engineering 2014 ANALYST ANTI-PATTERN
  38. 38. 38© Life Cycle Engineering 2014 RESPONSIBILITIES Product Vision Product Backlog Guidance to Scrum Team Stakeholder Expectations PRODUCT OWNER
  39. 39. 39© Life Cycle Engineering 2014 5 LEVELS OF AGILE PLANNING Vision Roadmap Release Sprint Daily Suggested Time box* Outcome Annual Vision Semi-Annual Roadmap Quarterly Release Backlog 2-4 weeks Sprint Backlog 15 mins daily “3 Questions”
  40. 40. 40© Life Cycle Engineering 2014 PRODUCT VISION The product vision is a high level statement that provides the team with a shared understanding of the what the end product will look like.
  41. 41. 41© Life Cycle Engineering 2014 PRODUCT VISION Bill Shakelford: ‘Design the box’ Front of the box • Product Name • Graphic/logo • 3-4 key selling points Back of box • Description of key features • Screens/mockups Spine • System requirements
  42. 42. 42© Life Cycle Engineering 2014 ELEVATOR PITCH FOR (target customer) WHO (statement of need) THE (product name) is a (product category) THAT (product key benefit, compelling reason to buy, problem being solved, etc.) UNLIKE (primary competing alternative) OUR PRODUCT (final statement of key differentiation) Geoffrey Moore’s “Elevator Pitch”, Crossing the Chasm (1991)
  43. 43. 43© Life Cycle Engineering 2014 AGILE PRODUCT CHARTER • Mission: The “Why”, higher purpose, or the reason for the project’s existence. • Vision: the “What” of the project stating what will be done in the project to achieve its higher purpose. • Success Criteria: The success criteria are management tests that describe effects outside of the solution itself – Defines “Done”
  44. 44. 44© Life Cycle Engineering 2014 AGILE PROJECT CHARTER • 1 page (A3) • High level, but specific • Eliminate boilerplate • Aligned with stakeholder Shared understanding of the charter is critical to enabling team members to collaborate effectively on large, enterprise projects
  45. 45. 45© Life Cycle Engineering 2014 TARGET PRACTICE • 5 Minutes • Pick a product • Try a method – Product Box – Elevator Statement – Charter (A3) – What else works for you? Successful vision defines at a high level: User – Opportunity – Critical features Other context specific objectives and success factors
  46. 46. 46© Life Cycle Engineering 2014 ROADMAP • Connects the Product Vision to the execution plan • Provides the team with visibility, incentive, and focus • Not a commitment … a visualization of the plan July Aug Sep Oct Nov Security User Admin Payments User Admin Product Admin Fulfillment Security
  47. 47. 47© Life Cycle Engineering 2014 BIG ROCKS Grouping like features can be helpful for planning These are often referred to as Themes or Epics Security Login with username/password Password Reset SSL 3.0 User Admin User account DB Update user info Register User Payment Credit Card Auto draft PayPal Integration
  48. 48. 48© Life Cycle Engineering 2014 ROADMAP
  49. 49. 49© Life Cycle Engineering 2014 CHART YOUR COURSE • 10 minutes • Brainstorm how to deliver value early • Come up with some high level themes • Roughly prioritize • 6 – 9 month horizon
  50. 50. 50© Life Cycle Engineering 2014 PERSONAS • A fictional character based on role, and real qualitative understanding of your user base • Emphasize the user-centric approach and promote empathy for the user and customer Picture and Name Details Goals or Solution Choose a picture and a name that are representative, and that allow you to develop sympathy for the persona Relevant characteristics and behaviors: Demographics, job, lifestyle, spare time activities, attitudes, common tasks, etc. Why would this specific persona want to buy or use this product? What problems are solved for this persona? What benefits are this persona seeking?
  51. 51. 51© Life Cycle Engineering 2014
  52. 52. 52© Life Cycle Engineering 2014 TIPS FOR USING PERSONAS • Start with quick and good enough - adapt over time • Distinguish user personas from customer personas • Choose a primary persona • Make personas believable • Stay focused and precise – problems and benefits • Keep the personas visible • Connect personas to user stories
  53. 53. 53© Life Cycle Engineering 2014 INTRODUCE YOUR USERS • 5 minutes • Come up with 2-3 user personas for your product • Tie user’s problem to your product’s solution • Ensure each user has a role
  54. 54. 54© Life Cycle Engineering 2014 TELL A STORY
  55. 55. 55© Life Cycle Engineering 2014 USER STORY • Simple and concise statement of requirement from a user perspective • Originated in Extreme Programming (XP) • Ron Jeffries: 3 C’s – Card – Conversation – Confirmation
  56. 56. 56© Life Cycle Engineering 2014 THOUGHT TEMPLATE A conversation with the stakeholder: – “As a” specific user or persona – “I want” need, feature, or functionality – “So (that)” purpose and value of delivery
  57. 57. 57© Life Cycle Engineering 2014 ACCEPTANCE CRITERIA • Flip the card over to record expectations: – User – Customer – Product Owner – Team How has the customer defined success for this story?
  58. 58. 58© Life Cycle Engineering 2014 INVEST Independent • Can ideally stand alone as a working product increment • Avoids dependencies with other stories whenever possible
  59. 59. 59© Life Cycle Engineering 2014 INVEST Negotiable • Stories are concepts not contracts • Can and should be revised or rewritten up until they are planned in a sprint
  60. 60. 60© Life Cycle Engineering 2014 INVEST Valuable • Should deliver value to the end user, customers, and/or stakeholders • Why else would a story matter?
  61. 61. 61© Life Cycle Engineering 2014 INVEST Estimable • The story provides the Team with enough information to approximate size • By understanding size, we can then plan
  62. 62. 62© Life Cycle Engineering 2014 INVEST Sized appropriately (Small) • Ideally can be completed in one iteration • Small for near-term work • Larger for work further out is ok, realizing further decomposition will be needed later
  63. 63. 63© Life Cycle Engineering 2014 INVEST Testable • Acceptance criteria establishes common expectations across team members and stakeholders • Critical to understand not just what will be tested, but also how it will be tested
  64. 64. 64© Life Cycle Engineering 2014 OTHER KINDS OF STORIES Technical Foundation: “As a developer, I need to upgrade the database software so we are running on the correct supported version” Research (Spike): “As lead architect, I need to research and evaluate COTS products that are compatible with our current system’s architecture so we can reduce the risk of future issues with integration”
  65. 65. 65© Life Cycle Engineering 2014 OTHER KINDS OF STORIES Design: “As a UI/UX engineer, I need to create the initial design for the account management screens so that I can begin to gather customer feedback” Other possible types of work items: Defects, maintenance, training, documentation, development infrastructure, automation, etc.
  66. 66. 66© Life Cycle Engineering 2014 STORY WRITING • 15 minutes • Write stories – From the perspective of your personas – Leverage/adjust your roadmap for value – Remember the template: As a <user>, I need to <do something>, so that I can <accomplish some goal>
  67. 67. 67© Life Cycle Engineering 2014 PRODUCT BACKLOG • An ordered list of work items needed to deliver the desired product, features, or system • The Product Owner decides the order with input from the development team and stakeholders • Always ready, never done, ever evolving • Modelled in greater detail and smaller size at the top • Maximizing value to the customer is the objective
  68. 68. 68© Life Cycle Engineering 2014 PRODUCT BACKLOG (FLAT)
  69. 69. 69© Life Cycle Engineering 2014 PRODUCT BACKLOG (ICEBERG)
  70. 70. 70© Life Cycle Engineering 2014 USER STORY MAPPING • Organizes and prioritizes user stories in two dimensions • Provides a useful tool for the entire team to understand the big picture • Can be useful when building a feature-rich product based on business processes, workflow, or tasking • Attributed to Jeff Patton -
  71. 71. 71© Life Cycle Engineering 2014
  72. 72. 72© Life Cycle Engineering 2014 STORY MAPPING time necessity Activities Tasks
  73. 73. 73© Life Cycle Engineering 2014 STORY MAPPING
  74. 74. 74© Life Cycle Engineering 2014 STORY MAPPING
  75. 75. 75© Life Cycle Engineering 2014 PRIORITIZING What is value to the customer? –Financial –Business –Reduced cost to develop and support –Innovation –Risk reduction –Market factors –Compliance –Deadline
  76. 76. 76© Life Cycle Engineering 2014 SIMPLE VALUE EFFORT MATRIX
  77. 77. 77© Life Cycle Engineering 2014 PRIORITIZING Business Value Cost Impact Risk Removed Total Story A 7 4 8 9 7 Story B 10 2 5 6 5.75 Story C 2 6 3 5 4 Story D 4 10 6 2 5.5 Decision Matrix - Good for teams supporting disparate customers - Incorporates multiple factors - Scored as a group
  78. 78. 78© Life Cycle Engineering 2014 KANO ANALYSIS
  79. 79. 79© Life Cycle Engineering 2014 PRODUCT EVOLUTION
  80. 80. 80© Life Cycle Engineering 2014 EVALUATE YOUR STORIES • 5 minutes • Kano Analysis –Must have –Satisfier –Delighter • Label your story cards • Ask around
  81. 81. 81© Life Cycle Engineering 2014 FACTORS TO CONSIDER • Minimally Marketable Feature (MMF) • Minimum viable product (MVP) • Earned Business Value (EBV) • Risk • Architecture and infrastructure • Dependencies and integrations • Constraints: Schedule & Costs
  82. 82. 82© Life Cycle Engineering 2014 DEFINITION OF DONE • What do we mean by “potentially shippable” • When is the team finished with a story? A feature? A release? • Evolves over time • Suited to the team’s unique environment • Incremental maturity • Helps to ensure quality is “built in”
  83. 83. 83© Life Cycle Engineering 2014 ESTIMATION How long is this going to take?
  84. 84. 84© Life Cycle Engineering 2014 ESTIMATION “Estimation is the process of finding an approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable” • Too many variables • Too much unknown • Too far in the future • Individual biases
  85. 85. 85© Life Cycle Engineering 2014 ESTIMATES BECOME PROMISES • Estimates drive expectations –Customers –Stakeholders –Business • Estimation may add value … But, is only valuable within a threshold of risk and cone of uncertainty
  86. 86. 86© Life Cycle Engineering 2014 REMEMBER THE TRIANGLES
  87. 87. 87© Life Cycle Engineering 2014 AGILE ESTIMATION • Story estimates are abstract - not time based • Derived from other “known” factors: – Effort – Complexity – Uncertainty • Informed by past performance • Originate from those who will do the work • Best to be roughly right than precisely wrong!
  88. 88. 88© Life Cycle Engineering 2014 RELATIVE SIZING: DOG POINTS • Golden Retriever • Great Dane • Border Collie • Chihuahua • Cocker Spaniel • English Bulldog • 2 minutes • Order from smallest to largest • Compare your list with your neighbor
  89. 89. 89© Life Cycle Engineering 2014 RELATIVE SIZE T-Shirt XS S M L XL XXL Fibonacci 1 2, 3 5, 8 13, 20 40 100
  90. 90. 90© Life Cycle Engineering 2014 SIZING TECHNIQUES • Affinity Estimation – group stories of similar size and then assign points 2 5 8 13 20 40
  91. 91. 91© Life Cycle Engineering 2014 PLANNING POKER • Product Owner tells the story • Team briefly discusses • Team members reveal their estimates all at once • Discuss outliers • Repeat until estimates converge
  92. 92. 92© Life Cycle Engineering 2014 ESTIMATING WITH POINTS • Don’t spend too much time on each story • Estimate only as much as is needed for planning • Large stories should be set aside to be broken down • Estimates come from the team – resist individual “anchoring” • Only re-estimate when relative size of a story has changed
  93. 93. 93© Life Cycle Engineering 2014 VELOCITY AND CAPACITY • Velocity – The demonstrated average number of points completed in an iteration • Capacity – The maximum amount a team can get done in an iteration
  94. 94. 94© Life Cycle Engineering 2014 ITERATION PLANNING • Start at the top • Identify specific tasks for each story • Estimate tasks in ideal hours for each task • Stop when capacity is reached Hours In Sprint Planned Absent Allocation Buffer Capacity Jim 80 16 100% 25% 48 Joe 80 0 100% 25% 60 Jane 80 0 50% 25% 30 Jenny 80 8 100% 25% 54 Jack 80 0 50% 25% 30 400 24 100% 25% 222
  95. 95. 95© Life Cycle Engineering 2014 BACKLOG GROOMING • At least once a sprint • Consult with the customer • Break down or split large stories – Many ways to do this • Give the team a preview, but not too far ahead • Refine acceptance criteria and design tests • Estimate size
  96. 96. 96© Life Cycle Engineering 2014 SPRINT CADENCE • Rhythm and ritual
  97. 97. 97© Life Cycle Engineering 2014 BURNDOWN CHARTS • Represent work remaining – By Release (points) or iteration (hours)
  98. 98. 98© Life Cycle Engineering 2014 LOTS OF OTHER METRICS • Goal: Measure and communicate progress through meaningful and highly visible means • Force the right conversations early • Help teams recognize their cadence • Uncover risk and areas of opportunity • Inform conversations… not replace them
  99. 99. 99© Life Cycle Engineering 2014 RETROSPECTIVES • The most powerful tool available to an Agile team • Observe, inspect, and adapt: – What worked well? – What didn’t work well? – What will we improve? • Focus on the team, not the product • Avoid dwelling on external factors
  100. 100. 10 0 © Life Cycle Engineering 2014 PROJECT INITIATION Decompose project requirements (scope) to create the first iteration of the project schedule, roadmap, and backlog Form the cross-functional agile team(s) of individuals with the roles and skills necessary to deliver on the project’s requirements Train the team, educate the customer, and communicate expectations Get started sprinting following the standard practices to learn how to best adapt in the future · Incorporate feedback from retrospectives · Build “muscle memory” around good practices · Establish common understanding of Agile fundamentals · Agree to a cadence · Decide on initial technologies · Identify and negotiate stakeholder roles and responsibilities · Agree to the metrics by which project performance will be measured · Establish the definition of done · Set up visible progress indicators Work Breakdown Structure IMS / Roadmap Agile PM Tool User StoriesUser Stories Systems Requirements Document (SRD) Systems Requirements Document (SRD) PWS/CDRLPWS/CDRL Product OwnerProduct Owner TestersTestersDevelopersDevelopers Scrum MasterScrum Master
  101. 101. 10 1 © Life Cycle Engineering 2014 KEEP THE AGILE CONVERSATION GOING • Software engineering practices • Agile team dynamics • Scaling up • Contracting and government • Metrics • Planning • User story writing • Testing/Quality • Retrospectives • Configuration management • Release management • Information assurance • Fostering culture • Organizational transition • Change management • Industry certifications • Management and executive sponsorship • More than software
  102. 102. 10 2 © Life Cycle Engineering 2014 CONTINUOUS LEARNING • Take a class • Attend a conference • Get certified • Engage online
  103. 103. 10 3 © Life Cycle Engineering 2014 HELP FOR THE TRANSITION Agile Coach • Supports the successful introduction of Agile to your organization and team • Shares subject matter expertise and experience • Helps avoid common mistakes and pitfalls that hinder adoption and delay value • Acts as a neutral and objective third party • Is a supportive partner and mentor across the organization
  104. 104. 10 4 © Life Cycle Engineering 2014 THANK YOU! Please let me know how I can do better next time! @JustinPetite

Notas del editor

  • Affinity: a similarity of characteristics suggesting a relationship, especially a resemblance in structure
  • Waterfall – 1970 – Winston Royce – “Managing the Development of Large Software Systems”
    “Personal views about managing large software developments” mainly spacecraft mission planning, commanding, and post flight analysis
    “Waterfall” coined by the DOD in their standards for developing military computer systems.

    Clearly stated that this model fails without iteration
  • February 2001: 17 leaders in the software development industry seeking an alternative to documentation driven, heavyweight software development processes.

  • Highlight:
    Iterative and Incremental - Evolutionary
    Highly collaborative
    Self-organizing teams
    effective governance framework just enough ceremony – cultural discipline & best practices
    High quality, cost effective, and timely – project triangle
    Meeting changing needs of the stakeholder within the project triangle – value
  • Highlight:
    Responding to change
  • Rooted in values
    Bounded by principles
    Enacted through practices

    Many people may think that Agile is just another software development process. There is a lot more to Agile than just a process or just a set of practices. Agile (or agility) is a mindset—a cultural way of thinking about software development.
  • The agile methods are focused on different aspects of the Software development life cycle. Some focus on the practices (e.g. XP, Pragmatic Programming, Agile Modeling), while others focus on managing the software projects (e.g. Scrum). Yet, there are approaches providing full coverage over the development life cycle (e.g. DSDM, IBM RUP), while most of them are suitable from the requirements specification phase on (FDD, for example). Thus, there is a clear difference between the various agile methods in this regard.

    DSDM = Iterative Waterfall
  • Embedded in those methodologies are practices such as…

    Requirements Practices
    Development Practices
    Testing Practices
    Release Management Practices
    Configuration Management Practices
  • Iterating – Not intended to be perfect
    Generates feedback

  • Takes a keen understanding of the purpose/solution what is being built
  • A true Scrum Team consists of a ScrumMaster, a Product Owner, and a Team. These three roles are collectively responsible for the delivery of the finished software. Each role also carries distinct responsibilities to optimize the Scrum Team’s flexibility and productivity.
    ScrumMaster – Responsible for ensuring that the Scrum Team adheres to the values, practices, and rules of Scrum. The ScrumMaster role is that of facilitator, organizer, and coach. Most importantly, the ScrumMaster is responsible for removing impediments – anything that may be preventing the team from making progress towards delivery.
    Product Owner –Solely responsible for managing the Product Backlog and ensuring it is visible to the Scrum Team. The prioritization of the backlog represents the voice of the customer, and illustrates the top business needs and their alignment with the overall vision of the project.
    Scrum Team – Turns work from the backlog into increments of potentially shippable functionality every iteration. The true Scrum Team is cross-functional; meaning, the members of the Team have all the skills required to create an increment of working software. True Scrum Teams are also self-organizing. While the Product Owner defines what the Team will work on, the Team itself decides how the work will get done in an iteration. The optimal size for a Scrum Team is seven people, plus or minus two. For projects with larger teams, Scrum can be scaled up to support better coordination and productivity across multiple teams working from the same backlog.

  • PO Proxy can make things complicated and confusing
  • The Product Owner is:
    the singular voice of the customer that a Scrum Team must satisfy
    the central business point of contact for defining product requirements & direction

    The Product Owner must have:
    deep understanding of the business drivers for the organization/program
    authority to make decisions/prioritize work
    commitment to follow the Scrum framework

    The Product Owner is responsible for:
    Communicating the Product vision at all levels
    To teams, stakeholders
    Ensuring that Program stays aligned with Product Vision
    Identifying the desired features/functionality and the value each should produce (Product Backlog)
    Ordering the desired features/functionality
    Providing Continual Guidance/Information to the Scrum Team
    Acceptance Criteria
    Agreement on Design Approach
    Be available to the Team
    Establish proxies & an interaction model if needed
    Managing Stakeholder expectations
    Release Planning – level of confidence on estimates
    Scope Management
    Participation at Sprint Reviews
  • Product Management – Strategy towards vision

    *at least
  • Bill Shakelford’s ‘Design the box’ exercise
    Front of the box
    Product Name
    3-4 key selling points
    Back of box
    Description of key features
    System requirements
  • Bill Shakelford’s ‘Design the box’ exercise
    Front of the box
    Product Name
    3-4 key selling points
    Back of box
    Description of key features
    System requirements
  • 1. What does success look like to each of the participants? The mission needs to identify what
    the people who charter the team value. Consider too the goals of each of the contributors.
    2. What is the product of the team expected to look like? What features? What are the
    architectural constraints? What interactions will the system have with it’s environment?
    3. What attributes will the project be constrained by? What are the resource and schedule
    constraints? What issues are known to be significant?
    A shared understanding of these dimensions is critical to enabling the team members to collaborate
  • 1998 and 2001
  • As a <stakeholder>, I would like to improve <some quality dimension> from <current level> to <desired level>, so that I can <achieve some goal>
  • One trick I learned to keep my user stories small is to only allow enough scope so that all of my acceptance stories can be written using a ball point pen on the backside of the user story index card. Another physical constraint!
    If your user story has more than 3-4 acceptance tests, really analyze the story and see if it makes sense to break it down even further so you can fit all its acceptance tests on the back of the card. Doing so might help you break down those larger stories into more digestible pieces.
  • Typical attributes to help with order:
  • “Flat”
  • Visualize the story!
  • Product goals describe what outcome or benefit received by the organization after the product is in use
  • Ideal time vs actual time
  • No longer a question of Time when the schedule is fixed. Better question is how much, not how long.
  • Empirical process control
    support the successful introduction of Agile to your organization and team
    improve teamwork and increase productivity
    mentor and up-skill executives and managers.

    Knowledgeable: They have a deep understanding of Agile practices and processes.
    Experienced: They have worked on Agile projects.
    Communicators: They can listen and talk with people from across an organization.
    Collaborators: They work with teams and organization to find answers.
    Leaders: They can motivate and inspire teams.