agile and lean business proposition

20
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 Business Proposition

Upload: russell-pannone

Post on 22-Jan-2015

1.106 views

Category:

Technology


1 download

DESCRIPTION

 

TRANSCRIPT

  • 1. Delivering value early and often, givingourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve The Business Proposition

2. Roadmap to being agile 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 improveTraining Cross-functional, collaborative and adaptive teams developing and delivering value-added product (system- software) increments in a continuous flow from requirements to deployment Agile Scrum Avoiding the high cost of discovering defects late in the CulturalAdoption Coaching & Renewal Training development cycle by discovering defects early in the development cycle which is accomplished by eliminating waste, increasing feedback loops and developing code from the point of view of provability and outside-in designOrganizational Emphasis is placed on the need for teams to nurture Change Management group cohesion, and paying attention to norms that serve as a guide that strengthens positive practices Minimizing frustration levels and making the art and science of system-software development enjoyable andDelivering value early and not a burden or death marchoften, giving ourselves thebest opportunity to beat the The what, why, and how of agile/lean product (system-competition to market, software) development and delivery is not one personsrealize revenue and vision alone; to become reality it needs to be a "shared" discover insights that we vision through negotiation and compromise betweencan use to help us improve individuals, the team and the organization 2 3. RecentData Points Russell Pannone (805) 910-6481 3 4. 4 5. 5 6. Gain feedback AcceptLowerthrough changeproject riskiterative withoutthrough incrementalslowing highervaluedownvisibilitydeliveryDeliveringvalue early and often,givingourselves the bestopportunity to beat thecompetition to market,realize revenueanddiscover insightsthat we canuse to helpus improve 6 7. Four Spheres of InfluenceCMU/SEI-2002-TR-009, ESC-TR-2002-009, July 2002 1. Sphere 1 - Stakeholder Needs and Business Processes: This sphere denotes requirements (includingquality attributes such as performance, security and reliability), end-user business processes, businessdrivers and operational environment. 2. Sphere 2 - Architecture and Design: This sphere denotes the essential elements of the system, therelationships between them, and how they fit with the enterprise system. The elements includestructure, behavior, usage, functionality, performance, resilience, reuse, comprehensibility, economicand technologic constraints and tradeoffs. 3. Sphere 3 - Marketplace: 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 theproject. These aspects consider the cost, schedule and risk of building, fielding and supporting thesolution. Key to these management aspects are the cost, schedule and risk of changing the necessarybusiness processes. 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 decisionsthat can be made in another sphere7 8. 8 9. Copyright 2005, Mountain Goat Software1. Agile puts the Product Owner (aka the business or customer representative) in the drivers 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 todays 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 dont 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 drivers 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 productCopyright 2008 Russell Pannone. All rights reserved. 9 10. Tooling Project - Product Backlog 10 11. Characteristics of good stories As a I want so that 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 ambiguityStory1 Story4As an eligible user, I want to pay the As an eligible user, I want to access my Story11onetime registration fee of $10, sorecord and delete any or all of my As an eligible user, I want to view a listthat I can access my drivers record ininformation to keep it current of assembled answers to questionsthe futureasked most frequently of the DMVStory5Story2Story12 As an eligible user, I want to access myAs an eligible user, I want to create a As an eligible user, I want to be able record and change any or all of myunique user name and password sofind an address for my local DMV information to keep it currentthat my access is limited to my recordoffice and print the resultsand to track activity and payment Story6 Story13Story3 As an eligible user, I want multiple As the application, I want to maintainAs an eligible user, I want to access my payment options to pay fees so that Ian audit trail of changes for eachrecord, so that I can verify that it isam able to access the features of theeligible user record indicating all editscorrectDMV site that require paymentCopyright 2008 Russell Pannone. All rights reserved. 11 12. 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 Im 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 businesscustomers, business analysts, testers and developers; however the ProductOwner (aka, the business or customer) is the primary owner of theseconditions-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.12 13. 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. 13 14. Where do Optional Stories come fromOptional OptionalBusStrategyUse Cases BusinessModelSystem RequirementsCustomerFunctional Business Partner&Non-Functional Product OwnerTeam Solution/IT-ServicesCopyright 2008 Russell Pannone. All rights reserved. 14 15. 5 levels of Agile PlanningWhat, Who, Why, When, Constraints,Product VisionAssumptionsReleases Date, Theme/Feature Set, Product RoadmapObjective, Development ApproachIteration, Team Capacity, Stories, Priority, Release Planning Size, Estimates, Definition of Done Stories Tasks, Definition of Done Iteration Planning Level-of Effort, Commitment1. What did I do yesterday?Daily Planning2. What will I do today?3. What is blocking me?15 16. A Paradigm ShiftFixed Variable Source: www.dsdm.org How is Agile Planning Different from Traditional Approaches?16 17. 1. Selecting Stories from the Product Backlog based on the teams velocity2. Identifying the tasks to realize a selected Story3. Estimating the level-of- effort required to complete the task Copyright 2008 Russell Pannone. All rights reserved.17 18. 1. Performing tasks to complete the story2. Completing the story based on story acceptance criteria and team's definition of done3. Developing and delivering commercial or operational value incrementally Copyright 2008 Russell Pannone. All rights reserved. 18 19. 19 20. Reduce WasteFeedback Loops Remove what isnt of Sprint Review & Planning value to the customer Sprint Retrospective Quicker delivery of value Daily Scrum & ROI20