Agile and Lean Business Proposition

1,613 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,613
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
48
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile and Lean Business Proposition

  1. 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 Business Proposition
  2. 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 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 Agile Scrum • Avoiding the high cost of discovering defects late in the Cultural Adoption 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 design Organizational • 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 and Delivering value early and not a burden or death march often, giving ourselves the best opportunity to beat the • The what, why, and how of agile/lean product (system- competition to market, software) development and delivery is not one persons realize revenue and vision alone; to become reality it needs to be a "shared" discover insights that we vision through negotiation and compromise between can use to help us improve individuals, the team and the organization 2
  3. 3. Recent Data Points Russell Pannone (805) 910-6481 3
  4. 4. 4
  5. 5. 5
  6. 6. 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 6
  7. 7. Four Spheres of Influence CMU/SEI-2002-TR-009, ESC-TR-2002-009, July 2002 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 - 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 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. 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 7
  8. 8. 8
  9. 9. 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. 9
  10. 10. Tooling Project - Product Backlog 10
  11. 11. 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. 11
  12. 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 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. 12
  13. 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. 14. 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. 14
  15. 15. 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? 15
  16. 16. A Paradigm Shift Fixed Variable Source: www.dsdm.org How is Agile Planning Different from Traditional Approaches? 16
  17. 17. 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. 17
  18. 18. 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. 18
  19. 19. 19
  20. 20. 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 20

×