Agile Pmi 102108 Final

Lean Agile Scrum Business Value Development and Delivery using Agility Brenden McGlinchey Software Done Right, Inc. [email_address]

High yield software engineering team Active Customer Involvement Emergent Design Built-in Quality Iterative Release We use Lean/Agile/Scrum as our ideology and process to maximize ROI and minimize errors and waste. www.softwaredoneright.net

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.”

Promise of Agility The Basic Promise is that Agility allows you to develop software successfully in the face of: Unknown/Moving Requirements Goal: to produce a product that is useful at the time of delivery Delays analysis and design until “needed’ Reduces waste Constrained Resources Goal: to produce the best product you can with what you’ve got Constant reprioritization Scrum adds the Promise that: The team will adapt its processes to improve their abilities to deliver quality

Wasted Effort The Standish Group [1] (famous for their Chaos Report) surveyed 1000 companies Features Actually Used: 7% Always 13% Often 16% Sometimes 19% Rarely 45% Never Conclusion: 64% wasted effort?

Waterfall is a Powerful Attractor Waterfall Requirements, Analysis, Design, Code, Test, Deploy For Management It is a “defined process” – thus “feels right” It gives the illusion of control Of people Of money Allows for “hands off” management For Developers They’re just “following a recipe” They’re just left alone for long periods

Process-focused Development Legacy IT is organized by process area Systems Analysts Enterprise Data Specialists UI Designer Specialists UI Developers Mid-tier Developers Database Developers Systems Testers Encourages process decomposition and sub-optimization (vs. optimizing the whole) Builds silos of experts with misaligned goals Discourages collaboration Creates Hand-offs & Waterfall phase gates (backed up queues) Creates the “blame game” [2] Quality may improve slightly, but at the cost of speed … is there a better way?

Waterfall Observations Long delivery cycles encourages piling on of poorly prioritized requirements Requirements are not fully understood even after inspection & sign-off Requirements change often during software development Users know what they want only after they see an initial version of the software New tools and technologies make implementation strategies unpredictable Technology changes occur faster than traditional software development projects can complete (12-18 months), so software is obsolete before projects complete

Categorization of complexity in development projects Requirements Technology

Software Done Right Agile Methods Summarized Agile Manifesto for Values [3] Individuals & interactions > over processes & tools Working software > comprehensive documentation Customer collaboration > contract negotiation Responding to change > following a plan Lean Principles for Vision Add value to customer • Empower the team Eliminate waste • Build integrity in Amplify learning • Optimize the whole Decide as late as possible • Deliver Fast Scrum for Process Framework 3 Meetings 3 Artifacts (Documents) 3 Roles XP for Quality and Discipline Paired programming Test driven development

Deming’s 14 points for management [4] 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. 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. 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. 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. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs. Institute training on the job. 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. Drive out fear, so that everyone may work effectively for the company (see Ch. 3). 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. 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. Eliminate work standards (quotas) on the factory floor. Substitute leadership. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership. 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. 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). Institute a vigorous program of education and self-improvement. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job. Origins of Lean Thinking: Deming

Taiichi Ohno, the mastermind of Toyota Production System, identified seven types of manufacturing waste [5] Overproduction = Extra Features Code for today Inventory = Requirements Requirement detail unfolded “just-in-time” Extra Processing Steps = Extra Steps Code directly from stories, get verbal clarification directly from customers Motion = Finding Information Collocation, including customers Defects = Defects Not Caught by Tests Test first; both developer tests and customer tests Waiting = Waiting, Including Customers Deliver in small increments Transportation = Handoffs Highest bandwidth form of communication is 2 people at a whiteboard, not backlogs of documentation (from Poppendieck & Poppendieck [6] ) Software Development Waste

Short Cycle-Time 10-day increments (Sprints) of completed software Ensures Focus on highest priority work Don’t build what you don’t need What do you want to see in 10 days? Builds in change-tolerance What do you want to see in future sprints? Leverages feedback Team reflects every 10 days What are we doing well? What can we do better? Feedback now vs. “post-mortem”

Built-in Quality Test-Driven Development Create automated testing then create code that makes tests pass Make code coverage visible Run suite of tests with every build Frequent (hourly builds) Paired-programming (Real-time code review) Creates an environment that allows architectures and designs to emerge Agile Principle “ The best designs and architectures emerge from self-organized teams”

Agile Methods: Scrum Lightweight Framework that Produces Heavyweight Results 3 Roles Product Owner ScrumMaster Development Team 3 Meetings Sprint Planning (4 hours) Daily Scrum (15 minutes) Sprint Demo & Retrospective (4 hours) 3 Artifacts Product Backlog Sprint Backlog Sprint Burn-down

Complex Adaptive System *Agile Management for Software Engineering, David J. Anderson [7]

Sprint/ Iteration Business Value Engine Daily Standup Sprint 2 weeks Epics Stories Reports Work in Progress Metrics Impediments Meaningful Increment of Product Release 3-4 Sprints Sprint Planning Sprint Product Demo Team Retrospective

Key Meetings Sprint Planning The Product Owner and team agree on the subset of the Product Backlog to work on this sprint. Result is the Sprint Backlog Sprint Review The Team shows their Product to their Product Owner and other Stakeholders. The purpose is to “show off” and get buyoff and feedback Daily Standup (Daily Scrum) The team understands its status every day in order to do a daily “inspect and adapt” cycle Sprint Retrospective The team (or Scrum Team) analyzes their own process and modifies it as necessary

Key Roles and Responsibilities The Scrum Team consists of: Product Owner ScrumMaster Team

Key Roles and Responsibilities Product Owner Product Owner Defines the features of the product, decides on release date and content Is responsible for the profitability of the product (ROI) Constantly Prioritizes the Product Backlog Can change features and priority every sprint Accepts or rejects work results

Key Roles and Responsibilities: ScrumMaster ScrumMaster Helps resolve impediments Ensures that the team is fully functional and productive Enables close cooperation across all roles and functions and removes barriers Shields the team from external interferences Ensures that the process is followed. Invites to daily scrum, iteration review and planning meetings

Key Roles and Responsibilities: Team Team Cross-functional, 7 ± 2 members Negotiates the iteration goal and specifies tasks Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal Organizes itself and its work Demos work results to the Product Owner

Product Backlog Prioritized collection of functionality, technology, issues Can be a list ordered by priority (only one thing in the top slot) Issues are placeholders that are later defined as work Emergent and prioritized More detail on higher priority backlog Product Owner responsible for priority Anyone can contribute Posted Visibly Derived from Requests

Epics, Stories, Tasks Epics (High-level Capability Statements) Contain 1 or more stories Business Value/Business Speak Stories: Fundamental increment of Business Value Business Value/Business Speak Validation-centric: MUST define “DONE”! Tasks: Small chunks of work that must be completed to validate story Team creates and estimates during planning session

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

Roadmap to Business Value (Roles) Roles: Defined to ensure Line-of-sight with System Users (Green Cards) Helps keep focus on: Real business value flows Real users of the system Help reduce waste! Don’t build what you don’t need Role: Jim Advisor 20 years experience Uses a wants/needs/expects approach Uses self-defined allocation models

Roadmap to Business Value (Stories) Stories: Unit of work = “Story”, similar to: 1 or more Use Case Steps 1 or more features Stories are written in business language… “ As a <some role>, I want <some feature>, so that <some business value or functionality>” Card, Conversation, Confirmation 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

Analysis: Product Feature Story Analysis is primarily about Decomposition Our Product decomposes into Features Features are implemented by doing stories But not all stories are feature-driven Our Project’s work can be seen as a collection of Stories But we’re only going to focus on the feature-driven ones Incremental Analysis is (basically): Find the Features, then Find the Stories Then we use the stories to drive development… Made up of Implemented by Product Features Story

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 Short Cycle-time Collocated, collaborative team w/clear line-of-sight to business value Focus on validation of completed product, not process Built-in Quality

References Jim Johnson, Standish Group (http://ciclamino.dibe.unige.it/xp2002/talksinfo/johnson.pdf) See Ron Pereira, “Stop the Finger Pointing” (http://lssacademy.com/2007/02/07/stop-finger-pointing/ ) See ( http://AgileManifesto.org ) W. Edwards Deming, Out of the Crisis , (1986), MIT Press. Taiichi Ohno, The Toyota Production System: Beyond Large-Scale Production , (1988), Productivity Press. M. Poppendieck & T. Poppendieck, Lean Software Development: An Agile Toolkit , (2003), Addison-Wesley David J. Anderson, Agile Management for Software Engineering , (2004), Prentice Hall

Contact Information Brenden McGlinchey [email_address]

Agile Pmi 102108 Final

More Related Content

What's hot (20)

Similar to Agile Pmi 102108 Final (20)

Agile Pmi 102108 Final