Lean Agile Scrum Business Value

Development and Delivery using Agility

Brenden McGlinchey Software Done Right, Inc.

brenden@softwaredoneright.net

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

Re

qu

ire

me

nts

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] 1. 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.

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

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

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

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.

6. Institute training on the job.

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

8. Drive out fear, so that everyone may work effectively for the company (see Ch. 3).

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

10. 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. 11. 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.

12. 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).

13. Institute a vigorous program of education and self-improvement. 14. 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]

Input Plan Do

Something Compare Output

Feedback

Sprint/ Iteration

Business Value Engine

Daily Standup

Sprint 2 weeks

Meaningful Increment of Product

Release 3-4 Sprints

Sprint Planning

Sprint • Product Demo • Team Retrospective

Epics

Stories

Reports •Work in Progress •Metrics •Impediments

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

Product Manager Board

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…

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

1. Jim Johnson, Standish Group (http://ciclamino.dibe.unige.it/xp2002/talksinfo/johnson.pdf)

2. See Ron Pereira, “Stop the Finger Pointing” (http://lssacademy.com/2007/02/07/stop-finger-pointing/ )

3. See (http://AgileManifesto.org) 4. W. Edwards Deming, Out of the Crisis, (1986), MIT Press. 5. Taiichi Ohno, The Toyota Production System: Beyond Large-Scale Production,

(1988), Productivity Press. 6. M. Poppendieck & T. Poppendieck, Lean Software Development: An Agile Toolkit,

(2003), Addison-Wesley 7. David J. Anderson, Agile Management for Software Engineering, (2004), Prentice

Hall

Contact Information

Brenden McGlinchey

brenden@softwaredoneright.net