product development using agile and lean principles

Welcome J

Agenda

Schedule Topics 09:30 – 11:00 Agile and Lean 11:00 – 11:30 Tea break 11:30 – 13:00 Scrum Framework 13:00 – 13:45 Lunch 13:45 – 14:45 Scrum-based Product Development 14:45 – 15:00 Tea break 15:00 – 17:00 Scrum Simulation 17:00 – 17:30 Wrap-up / Q&A / Feedback

Waterfall Software Development

http://damonpoole.blogspot.in/2009/07/traditional-development-game-of.html

What are the key challenges with waterfall?

Waterfall challenges: Poor Visibility

http://www.agilenutshell.com/agile_vs_waterfall

Waterfall challenges: Poor Risk Management


Waterfall challenges: Poor Quality


Waterfall challenges: Poor Change Management


Late learning sequence of product development

http://alistair.cockburn.us/Disciplined+Learning

As a result, software is…

Late

Buggy

Costly

and the costs…?

http://leadinganswers.typepad.com/leading_answers/estimating/ http://www.agileforall.com/dyk/

But we want software to be…

The Myth of Faster, Better, Cheaper

The Myth of Faster, Better, Cheaper

Good

Fast Cheap Bad

?

Let’s paint…

Incremental vs. Iterative

http://www.infoq.com/resource/news/2008/01/iterating-and-incrementing/en/resources/Patton_Incremental_Iterative_MnaLisa.jpg

Incremental and Iterative

Incremental Iterative Scheduling and staging strategy

Rework scheduling strategy

Parts of system are developed at different times and integrated as they are completed

Review and improve part of the systems

Doesn’t imply or require iterative development

Doesn't presuppose incremental development

Output is not necessarily subject to further refinement

Output is examined for modifications in successive iterations

http://itsadeliverything.com/wordpress/images//iterative-incremental-mona-lisa.png

Incremental and Iterative

Incremental vs. Iterative

http://www.planetgeek.ch/wp-content/uploads/2011/01/Slide7.png

What is the most important part in these two machines?

“The Brakes!!!” They let you go faster…

Agility vs. Discipline?

http://www.ibm.com/developerworks/rational/library/edge/08/feb08/lines_barnes_holmes_ambler/

Agile Manifesto 2001

12 Agile Principles

Our highest priority is to satisfy the customer�

through early and continuous delivery�of valuable software.

Welcome changing requirements, even late in �

development. Agile processes harness

change for �the customer's competitive

advantage.

Deliver working software frequently, from a �

couple of weeks to a couple of months, with a �preference to the shorter

timescale.

Business people and developers must work �

together daily throughout the project.

Build projects around motivated individuals. �

Give them the environment and support they need, �and trust them to get the

job done.

The most efficient and effective method of �

conveying information to and within a development �

team is face-to-face conversation.

Working software is the primary measure of

progress.

Agile processes promote sustainable development. �The sponsors, developers, and users should be able �

to maintain a constant pace indefinitely.

Continuous attention to technical excellence �

and good design enhances agility.

Simplicity--the art of maximizing the amount �of work not done--is

essential.

The best architectures, requirements, and designs �

emerge from self-organizing teams.

At regular intervals, the team reflects on how �

to become more effective, then tunes and adjusts �its behavior accordingly.

Waterfall vs. Agile

http://www.isixsigma.com/new-to-six-sigma/design-for-six-sigma-dfss/doing-some-software-six-sigma-and-agile-%E2%90%98mythbusting%E2%90%99/

Waterfall vs. Agile


By doing them continuously: •   Quality improves

because testing starts from day one.

•   Visibility improves because you are 1/2 way through the project when you have built 1/2 the features.

•   Risk is reduced because you are getting feedback early, and

•   Customers are happy because they can make changes without paying exorbitant costs.

http://www.targetprocess.com/blog/wp-content/uploads/2009/06/agile_waterfall-792810.png

Waterfall vs. Agile

https://en.wikipedia.org/wiki/File:Agile-vs-iterative-flow.jpg

Waterfall vs. Agile: Constraints

Waterfall vs. Agile: Risk vs. Value Delivered

http://www.testingthefuture.net/wp-content/uploads/2011/12/waterfall_versus_agile_development.png

Predictive vs. Adaptive

Agile Development Value Proposition

http://www.versionone.com/Agile101/Agile_Benefits.asp

Agile ROI

http://www.agileload.com/agileload//blog/2012/10/22/agile-performance-testing-process---whitepaper

Lean

×   maximize customer value while minimizing waste.

×   A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.

Lean Thinking

×   Lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services through entire value streams that flow horizontally across technologies, assets, and departments to customers.

×   Eliminating waste along entire value streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. Companies are able to respond to changing customer desires with high variety, high quality, low cost, and with very fast throughput times. Also, information management becomes much simpler and more accurate.

Pillars of Lean Thinking 1. Identify

Value

2. Map the Value Stream

3. Create Flow

4. Establish Pull

5. Seek Perfection

Pillars of Lean Thinking

1. Identify Value

Specify value from the

standpoint of the end

customer by product family.

2. Map the Value

Stream

Identify all the steps in the

value stream for each product family,

eliminating whenever

possible those steps that do

not create value.

3. Create Flow

Make the value-creating steps occur in tight sequence so the product

will flow smoothly

toward the customer.

4. Establish

Pull

As flow is introduced, let customers pull value from the next upstream

activity.

5. Seek Perfection

As value is specified,

value streams are identified, wasted steps are removed, and flow and

pull are introduced,

begin the process again and continue it until a state

of perfection is reached in

which perfect value is

created with no waste.

What is Value?

http://mikehohnen.com/2008/04/19/oplevelse/

Perceived Value?

http://blogs.forrester.com/norbert_kriebel/13-06-04-use_the_value_equation_to_drive_successful_meetings

Value Equation of a Smartphone

http://www.jtklepp.com/2009/12/03/a-value-based-framework-for-the-smartphone-os-war/

Value Stream Map (VSM)

×   Special type of flow chart that uses symbols known as "the language of Lean" to depict and improve the flow of inventory and information

×   Purpose is to provide optimum value to the customer through a complete value creation process with minimum waste in ×   Design (concept to customer) ×   Build (order to delivery) ×   Sustain (in-use through life cycle to service)

Value Stream for Cola Cans

Lean Thinking – Womack and Jones

Software Development Value Stream

http://softwarecreation.org/2009/reliable-software-development-process-the-toyota-way/

Kent Beck’s Value Stream Map

Agile Value Stream Map

Lean Software Development, An Agile Toolkit – Mary Poppendeick

Lean Principles in Software Development

Eliminate waste

Amplify Learning

Decide as late as

possible

Deliver as fast as

possible Empower

Team Build

integrity in

See the Whole

Types of Waste

https://deejaygraham.github.io/img/posts/muda-muri-mura-so-what/muda-muri-mura-so-what-hifi.png

Muda, Mura, Muri

https://leanandkanban.files.wordpress.com/2011/03/mura-muri-muda.png

Wastes in Software Development

Lean Software

Defects Defects in Software, (Requirements, Design, Code) Overproduction Extra features that remain unused Waiting Delays in getting information, reviews, approvals Talent Talent (motivation, engagement, relearning) Transportation Distributed teams, Component Teams Inventory Work in Progress, Partially done work, Motion Chasing information, Task switching Extra-processing Over-engineering, Over-documentation, Over-

process steps, Relearning legacy code, Handoffs in production systems,

5S in Software Development

×   Sort (Seiri): Sort through the stuff on the team workstations and servers, and find the old versions of software and old files and reports that will never be used any more. Back them up if you must, then delete them.

×   Systematize (Seiton): Desktop layouts and file structures are important. They should be crafted so that things are logically organized and easy to find. Any workspace that is used by more than one person should conform to a common team layout so people can find what they need every place they log in.

×   Shine (Seiso): Whew, that was a lot of work. Time to throw out the pop cans and coffee cups, clean the fingerprints off the monitor screens, and pick up all that paper. Clean up the whiteboards after taking pictures of the important designs that are sketched there.

×   Standardize (Seiketsu): Put some automation and standards in place to make sure that every workstation always has the latest version of the tools, backups occur regularly, and miscellaneous junk doesn't accumulate.

×   Sustain (Shitsuke): Now you just have to keep up the discipline.

Implementing Lean Software Development from Concept to Cash – Mary Poppendeick

5S in Java

×   Sort (Seiri): Reduce the size of the code base. Throw away all unneeded items immediately. Remove: ×   Dead code, Unused imports Unused variables, Unused methods, Unused

classes, Refactor redundant code

×   Systematize (Seiton): Organize the projects and packages. Have a place for everything and everything in its place. ×   Resolve package dependency cycles, Minimize dependencies

×   Shine (Seiso): Clean up. Problems are more visible when everything is neat and clean. ×   Resolve unit test failures and errors ( passed == 100%), Improve unit test

coverage ( > 80%), Improve unit test performance, Check AllTests performance, Resolve checkstyle warnings, Resolve PMD warnings, Resolve javadoc warnings, Resolve TODO’s

×   Standardize (Seiketsu): Once you get to a clean state, keep it that way. Reduce complexity over time to improve ease of maintenance.

×   Sustain (Shitsuke): Use and follow standard procedures.

Implementing Lean Software Development from Concept to Cash – Mary Poppendeick

Time for break!

Untangle Game

http://blog.officience.com/en/des-jeux-pour-apprendre-lagilite/

Scrum Framework

http://www.flickr.com/photos/magia3e/6233729753/

So, what happens in each increment?

Increment

≠ Mini-waterfall

XP Feedback Loops

http://www.ssa-outsourcing.com/services/project-management/

Feedback Loops in Traditional Techniques vs. Agile Techniques

feedback loop in agile lifecycles

test-code-refactor loop

Scrum Values

Focus

Courage

Openness

Commitment

Respect

Roles, Ceremonies and Artifacts

•   Scrum Team is small (5-9), cross-functional team members from Dev, UX, QA (excluding Product Owner) to ship complete feature(s) end to end

•   Scrum Master is the servant leader responsible for supporting team

•   Product Owner owns Product Backlog and sets appropriate priority for team to act upon

Roles

Product Owner

Scrum Master

Scrum Team

Ceremonies

Sprint Planning Meeting

Daily Stand-ups

Backlog Grooming

Product Demo

Sprint Retrospective

Artifacts

Product Backlog

Sprint Backlog

Increment

Release Burn-down Chart

Sprint Burn-down Chart

Scrum Roles

So, how do we start?

What’s wrong?

http://headrush.typepad.com/creating_passionate_users/2005/06/featuritis_vs_t.html

How Apple does it?

Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?". Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.”

http://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html

Kano Model

MoSCoW

• Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. MUST

• Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

SHOULD

• Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. COULD

• Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. WON'T

Minimal Marketable Feature

A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.

An MMF is different than a typical User Story in Scrum or Extreme Programming. Where multiple User Stories might be coalesced to form a single marketable feature, MMFs are a little bit bigger. Often, there is a release after each MMF is complete.

An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to launch on its own.

A MMF can be represented as a User Story — a short, one-sentence description.

MVP, MMF, Stories

MVP

MMFs

Stories

Product Backlog

×   The Product Backlog is a prioritized list of everything that might be included in a product.

×   The Product Owner creates, maintains, and regularly re-orders the Product Backlog.

×   The Product Owner uses the Product Backlog to adapt to emerging requirements, customer feedback, and market changes.

https://felixgrayson.files.wordpress.com/2015/08/image4.png

Product Backlog Iceberg

“D.E.E.P.”

https://leanpub.com/site_images/MasteringBacklogs/DeepSlide.jpg

Prioritization -> Roadmap

http://agilelucero.com/wp-content/uploads/2014/09/product-backlog.jpg

Roadmap -> Release -> Sprint

https://www.scrumalliance.org/scrum/files/42/421788e7-1ebb-468f-8404-ca4cb9d0be6d.jpg

From Product Backlog to Sprint Backlog

https://kienlamcs100w.files.wordpress.com/2014/09/sprint-planning-meeting-outcome.jpg

Sprint Backlog

×   User Stories selected by The Team

×   Will be built in current Sprint

×   Fully Estimated

×   Divided into Tasks

User Stories

×   User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

×   As a <type of user>, I want <some goal> so that <some reason>.

×   User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Epics and User Stories

Themes, Epics and Stories

“I.N.V.E.S.T.”

• Independent I

• Negotiable N

• Valuable V

• Estimable E

• Small S

• Testable T

Acceptance Criteria

Definition of Done

Acceptance Criteria vs. Definition of Done

Technical Debt

Tech Debt

Potentially Shippable Increment

×   A Potentially Shippable Product is the sum of the Product Backlog Items delivered each Sprint.

×   Delivering Potentially Shippable Product each Sprint is fundamental to the Scrum because when work is divided into simple pieces it can be finished in a short iterations.

×   By accelerating the creative process and putting a functioning product in the hands of the user, the Team can gather feedback more quickly than it otherwise would have. To achieve this feedback loop on a Sprint-by-Sprint basis, Scrum Teams deliver Potentially Shippable Product at each Sprint Review.

×   The keys to creating working product at the end of each Sprint are: ×   A cross-functional Team with all the skills necessary to complete the Sprint

Backlog. ×   Quality User Stories with explicit definitions of Ready and Done. ×   A Product Owner with the ability to prioritize backlog into vertical slices of

functionality.

Sprint Planning

×   Happens on Day 1 of every Sprint. ×   Decide what user stories will be attempted based on

dependencies, priority, resources, time ×   Define what Done means for this iteration. Checked in

software, tested, documented and demonstrable. ×   Team plans iteration by decomposing user stories into

estimated tasks describing the work that needs to be done to complete the story.

×   Task should be in the order of 1-16 Hrs ×   Everyone agrees on what to do and commits to

completing the work. ×   Team signs up for tasks on Sprint backlog.

Estimation

×   “The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.” – Steve McConell

×   Are any two projects same?

Cone of Uncertainty

Estimation

http://www.agilenutshell.com/episodes/3-estimation

Use any measure…consistently

Literally…just about anything!

Story Points

×   Agile teams generally prefer to express estimates in units other than the time-honored "man-day" or "man-hour". Possibly the most widespread unit is "story points".

×   One of the chief reasons is the use of velocity for planning purposes. "Velocity", in the sense Agile teams use the term, has no preferred unit of measurement, it is a dimensionless quantity. Velocity allows teams to compute the expected remaining duration of the project, as a number of iterations, each iteration delivering some amount of features.

×   Another important reason has to do with the social and psychological aspects of estimation: using units such as story points, emphasizing relative difficulty over absolute duration, relieves some of the tensions that often arise between developers and managers around estimation: for instance, asking developers for an estimate then holding them accountable as if it had been a firm commitment.

http://guide.agilealliance.org/guide/nuts.html

Estimation Mainly two forms of estimation ×   Analogous Estimation [T-Shirt Sizing - S,M,L,XL]

×   This Story is like another Story (maybe a little more difficult, maybe a little less)

×   Give this Story a comparable estimated value. ×   Estimate against multiple Stories of the same effort. ×   Analogous estimation is successful due to our inherent ability to better

measure relative size than absolute size. ×   Planning Poker

×   Each estimator is given a deck of cards, each card contains a valid estimate.

×   Fib ––1,2,3,5,8,13,20,301,2,3,5,8,13,20,30 ×   Story is read and discussed briefly ×   Each estimator selects a card that reflects their estimate. ×   Cards are turned over for all to see. ×   Discussion takes place ×   Re-estimate to try to get convergence.

Planning Poker

Daily Scrum

http://www.xqa.com.ar/visualmanagement/2009/04/daily-scrum-against-the-board/

Daily Standup ×  Daily meeting, 15 mins, team members answer

3 questions. ×   What did you do yesterday? Informs team on

completed tasks, dependencies. ×   What will you do today? Informs team on possible

upcoming dependencies, requests. ×   What is blocking you? Helps identify resources to

help unblock tasks after the meeting. ×   Sprint backlog should be updated with

yesterdays tasks prior to meeting ×  Not intended for problem solving, or as a status

meeting. ×   Everyone is invited, but only team members

talk.

Scrum Task Board

Sprint Burndown Chart

http://www.infoq.com/resource/articles/agile-kanban-boards/en/resources/Fig4_DailyBurndown.jpg

Sprint Review

×   Held on the final day of every sprint ×   Team presents what it accomplished during the

sprint in the form of a demo of new features or underlying architecture.

×   Team also explains what remains undone and why.

×   Should be a very informal meeting where non team members can see what has been accomplished and comment.

×   Demo should foster collaboration about what can and should be done next, providing valuable input into the subsequent sprint planning meeting.

×   Learning's should be taken into retrospective

Sprint Retrospective

×   Held on the final day of every sprint. ×   Scrum Team ONLY revises, their development process

to make it more effective and enjoyable for the next Sprint

×   Inspect how the last Sprint went in regards to people, relationships, process and tools.

×   Identify and prioritize the major items that went well and those items that-if done differently-could make things even better.

×   Team takes 2-3 items and brainstorms solutions to most important issues

×   Team should agree on actionable improvement measures that it implements for next Sprint.

Time for break!

Scrum-based Product Development

Planning a Family Vacation

Holiday Plan

Map

GPS

Odometer

Speedometer

Eyes

Str

ateg

ic

Dir

ectio

n

Exec

utio

n A

lignm

ent

Vision

Execution Feedback

Goals

Planning in Agile

Mission

Vision

Portfolio

Product

Release

Sprint

Daily

Organizational Strategy

Agile / Scrum-based Product Development

Product Runways

Strategic Vision

Set by the CEO / Board and consists of Strategic Direction, Solution Strategy, Technology Initiatives and Themes Reviewed annually as part of annual strategic planning and revised as needed Serves as a strategic input for product vision

Product Vision

High-level overview of product requirements owned by respective POs Acts as true north for the product in long term (3-5 years) Serves as the input for overall product roadmap in medium term (1-3 years)

Product Roadmap

Calls out the high-level themes and release timeline in next 1-3 years Consists of swimlanes (strategic priorities vs. lights on, client requests,vs. competitive intel, technical debt vs innovation ideas,, etc.) Reviewed each quarter by Product Council

Product Backlog

Prioritized list of features identified for the next 1-3 releases Owned and maintained by respective POs based on relative prioritization of each feature request Revised constantly based on evolving inputs and refined weekly in grooming sessions with scrum team

Sprint Backlog

Consists of highest-priority / highest-value features agreed upon for development in the current sprint (1-4 weeks) Product Owner responsible to prioritize the features, while scrum team responsible for planning, estimation, planning, execution and completion of those features in a sprint Once the sprint has started, any new requirements or change request must wait until the next sprint planning

Adaptive Planning

Pro

du

ct B

ack

log

Pro

du

ct R

oad

map

Sp

rin

t Bac

klo

g

Pro

du

ct V

isio

n Futuristic

picture of the product Based on technology evolution, market development, industry trends, etc. Reviewed annually, and revised as needed

High-level wish list of themes and epics for a long-term Reviewed by Product Council on a quarterly basis Typically revised annually

Prioritized list of Themes, Epics and User Stories Gets constantly revised and groomed on a weekly basis

Well-groomed User Stories Can’t be changed once the sprint is underway

Current Sprint 3-6 months 12-24 months 1-3 years

Sm

all S

tori

es,

Firm

Req

uir

emen

ts,

Lar

ge S

tori

es /

Ep

ics

/ Th

emes

, Fu

zzy

/ Evo

lvin

g R

equ

irem

ents

Product Management Artifacts

Initi

ativ

es

Epic

s

Them

es

Spri

nt B

ackl

og

Prod

uct B

ackl

og

Prod

uct R

oadm

ap

Prod

uct V

isio

n

Task

s…

Stor

ies

Scen

ario

s

Product Vision

Shared by All

Desirable and Inspirational

Clear and Tangible

Broad and Engaging

Short and Sweet

Product Vision – Elevator Pitch

For (target customer)

Who (statement of the need or opportunity)

The (product name) is a (product category)

That (key benefit, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)

http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html

Product Vision Box

×  As the name suggests…

×  Describes the top 2-3 features of product

Press Release

×  Amazon’s “working backwards”

×  Write the launch press release!

http://blogs.salesforce.com/company/2012/06/agile-approach-to-talent-management.html

Agile lifecycle – small picture

Backlog Grooming

×   Upto 5-10% of sprint time

×   Creating or refining new PBIs

×   Estimating PBIs

×   Prioritizing PBIs

Affinity Estimating Guidelines

• If team is already Sprinting, find a small-ish one already completed that was a really good estimate; use that estimate

• Or find a fully understandable story and fully task it out; call it either a 2 or a 3

• Smallest at the right and largest on the left compared to initial story • Anyone can move anyone else’s story position

Affinity Estimating

127

Release Planning

Release Burndown Chart

https://agilewarrior.files.wordpress.com/2013/06/burndown-3-details.png?w=540

Release Replanning

http://agiledictionary.com/wp-content/uploads/2010/06/releaseburndown.jpg

Time for break!

Scrum Simulation

Objective

Deliver a tourist brochure for martians visiting earth

Activity Time

Sprint Planning 10 min Sprint – Day 1 7 min Daily Scrum 3 min Sprint – Day 2 7 min Daily Scrum 3 min Sprint – Day 3 7 min Sprint Demo 5 min Sprint Retro 20 min

Product Backlog Product Backlog Item Order

Create cover art, brand, and/or logo

Define major topics for Martian tourism

Describe “Art Interests in Europe” tour

Describe a tour based on photosynthesis

Outline a “7 Wonders of the World” expedition

Set prices for the tours

Outline warning messages (gravity, oxygen, fungi, etc.)

Suggest clothing options

Explain travel options to/from Mars Describe a “Human Sports” tour

Outline refund policy

Suggest related services

Define advertisers

Define a 12-month campaign

Set-up how to get more information

Feedback