Jerry Metcalf 102516

From Requirements to the Market
A Lean journey
“Why is it so hard to start at the right place, to correctly define value? Partly because
most producers want to make what they are already making and partly because many
customers only know how to ask for some variant of what they are already getting.”
― James P. Womack, Lean Thinking: Banish Waste And Create Wealth In Your
Corporation
Copyright © 2016
Copyright Allegro
© 2015 Business
Allegro Solutions
Business LLC.LLC.
Solutions All All
Rights Reserved
Rights Reserved
About Allegro Business Solutions
Allegro Business Solutions offers services in four key areas:
Project/Program Management,
Agile & Scrum techniques
Lean 6 Sigma methods,
and the IT Infrastructure Library (ITIL) .
Our principal has years of successful experience with these tools and
techniques that can be engaged to meet your needs whether on-site or virtual.
We know that each solution has to be tailored to the company culture and team
makeup so we focus on working with a variety of stakeholders as part of our
processes.
http://www.allegrobizsolutions.com/
Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 2
Introduction
Mr. Metcalf has developed products and services for over 30 years from the most
advances medical ultrasound equipment to a watch cell phone using various forms of
product and service development processes and lifecycles. He has been part of
fortune 500 companies as well as startups and has employed his entrepreneurial and
customer focus to release many highly successful product and services.
Jerry’s experience includes project/program management, strategic planning, portfolio

management, Lean process improvement, advanced technology, SDLC expertise –
Waterfall to Agile, building relationships, technical partner and alliance development,
acquisitions, business and contract negotiations, licensing, product management and
requirements management, legal acumen, managing though influence and getting
things done.
Jerry holds the following certificates: PMP, ACP, CSP, CSPO, CSM, SPC, LSS and ITIL v3.
Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved
What is an Agile Project?
• Simple answer: A Project that uses Agile Principles and Practices
• But what are those characteristics?
• Being able to measure ROI early and often in the project
• Transparent to the organization – high visibility of project progress and issues
• Continuous involvement of stakeholders (customers) in throughout the
project
• The business owner is empowered to make decisions to meet goals
• Adaptive – able to change to meet needs and requirements as they present
themselves
• Always looking for ways to reduce waste and target the
minimum set of customer value
• Reduce waste of both the product and the process

Specific Agile Methods
• Scrum
• Iteration based and is the most popular
• Extreme Programing – XP
• Most often used for its great Programming discipline
• Feature Driving Development (FDD)
• Lean Workflow
• Dynamic Systems Development Method (DSDM)
• Crystal Family of Methods

• Crystal Clear, Crystal Yellow, Crystal Orange, …

The Iron Triangle – Cost, Time and Scope
Relationship
Waterfall – Modified Waterfall Agile
Scope - Fixed Time Fixed Cost
Agile
Traditional
Time Dynamic Cost Scope - Dynamic

Introduction to Lean
• Lean Manufacturing
• Henry Ford starts manufacturing the Model-T in 1913
• It had interchangeable parts and a process flow – down side one model one color
• Other Automobile manufacturers started making more models and colors
• That required changes in process that slowed down the flow and added slow machinery
• Toyoda and Ohno analyzed the car making process and came up with the
Toyota Production System in the 1930’s and in earnest after WWII
• Lean in general
• Thoroughly described in the book The Machine That Changed the World
(1990) by James P. Womack, Daniel Roos, and Daniel T. Jones
• Lean Thinking(1996), James P. Womack and Daniel T. Jones

Specifics of Lean thinking today
• Specify the value desired by the customer
• Identify the value stream for each product providing that value and challenge all
of the wasted steps (generally nine out of ten) currently necessary to provide it
• Make the product flow continuously through the remaining value-added steps
• Introduce pull between all steps where continuous flow is possible
• Manage toward perfection so that the number of steps and the amount of time
and information needed to serve the customer continually falls
“As lean thinking continues to spread to every country in the world, leaders are also adapting the tools
and principles beyond manufacturing, to logistics and distribution, services, retail, healthcare,
construction, maintenance, and even government. Indeed, lean consciousness and methods are only
beginning to take root among senior managers and leaders in all sectors today."
From the Lean Enterprise Institute
Lean Software Development
Mary and Tom Poppendieck have been the major proponent of Lean
Software development
Lean Software Principles Toyota Production System Principles
Eliminate Waste Reduce Setup waste
Embed Quality Quality at the source
Learn First – Amply learning Small lot production
Deliver Fast – Defer Decisions Pull production
Improve Forever Equipment maintenance
Respect People – Empower the team Employee involvement
Think Systems – Optimize the Whole Supplier involvement
Lean Software Development: An Agile Toolkit, Tom and Mary Poppendieck

The 7 principles of Lean development
• Eliminate Waste
• This becomes the list of 7 on the following slide which we will go into further detail
• Embed Quality
• At evert opportunity add quality to your process from the backlog to demo
• Learn First
• One needs to learn as quickly as possible as part of successive elaboration
• Deliver Fast
• Get working software (product) in front of stakeholders as quickly as you can
• Improve Constantly
• Inspect and Adapt is a major tenant of Scrum and Agile development
• Respect People
• The team are the ones that know the work and know best how to organize to get the best throughput
• Think Systems
• Keep the overall system in mind as you develop success increments of what will eventfully become your product

Lean Software Development – the Wastes
The Seven Software Dev Wastes The Seven Wastes – Taiichi Ohno
Extra Features Overproduction
Partially Done Work Work in Process – WIP
Relearning Overprocessing
Handoffs Transportation
Task Switching* Motion
Delays Waiting
Defects Defects
Task Switching losses as much as 40% efficiency every time there is a switch - Meyer

Delivering Value Assessment
• Based on the 7 wastes in Lean the following are examined as not
adding to value
Lean Waste Description

Extra Features Over specifying the customer need
Partially done work Work that is waiting to move to the next step in the process
Relearning The work is left for a while and has to be taken up again
Handoffs One person starts the work and then another is switched in as a replacement
Task switching Multitasking is not a good thing and studies have show a 20% to 60% loss in efficiency
Delays Items not ready for the next step to proceed affecting throughput
Defects The impact of Techdebt – issues not resolved at the time of development

The Elements of Scrum
https://www.scrumalliance.org/why-scrum

The Scrum Framework
Business Ideas
• Epics and Features for
scrum team Daily Standup
• What was done yesterday?
Sprint Planning Meeting • What will be done today?
• Review Product backlog • Impediments - Blockers?
• Estimate Sprint backlog
• Commit to Sprint timebox Retrospective
• Communicate Sprint Goals • Inspect and Adapt
Sprint Review Meeting

• Demo and Acceptance of
Sprint stories
Iteration Timebox
• 2 to 4 weeks
Product Backlog Sprint Backlog
• Groomed, prioritized • Stories estimated by team
Features in story form • Task breakdown by team Potentially Shippable Items

Lean – Agile/Scrum relationship
• Lean Principles - to
reduce waste without
frustrating customers Scrum Team
• Agile - to reduce cost Lean

to make changes that
reduce time to market
Scrum Team
Lean Principles

Process Combination
Scrum - for the way we
Scrum plan, organize and manage
our work
XP – for Development
discipline
XP Lean Lean – for the overall way
we think
Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved

Keep a keen eye on Business Value
• In a 2006 study, the Standish Group found that in traditional waterfall
software projects 64% of typical system features were rarely or never
used
• Over production of features occurs often in traditional IT because
stakeholders are only given one opportunity to present their system in
a Big Bang fashion
64% Waste

Backlog Grooming – Lean thinking
• MMF
• (MMF) is the smallest piece of functionality that can be delivered that has
value to both the organization delivering it and the people using it.
• MVP
• (MVP) is: "[the] version of a new product which allows a team to collect the
maximum amount of validated learning about customers with the least
effort" — Eric Ries – Lean Startup
• (MVP) is: a product with just enough features to gather validated learning
about the product and its continued development - Wikipedia

Gaining Stakeholder feedback
• Develop wireframes
• Quick mockups on what the team’s requirements understanding
• Personas
• Who is the user and in what environment are they going to use the product?
• Activity Diagrams
• What is the flow of how this product is going to be used?
• Use Cases
• What are scenarios how to use this Product?
• All are methods for attaining requirements for the project.

Backlog grooming implications
• Grooming
• Poor grooming means that there is not enough info for the team to understand
what is being requested
• There may not be info on technology, sequencing, Acceptance Criterion, etc.
• Estimation
• If there is poor grooming then how can the team estimate even relatively what
work is required?
• How can we determine velocity of the team and when they can get to the items
we so want down further in the backlog.
• Dependencies/Risks
• Here we run into a big problem for the teams. If we don’t know the details of
the stories how can we determine if there are dependancies on other team,
technology or risks?
Method for determining an effective Story
Independent • Able to be build in any order
Negotiable • Make tradeoffs with Stakeholders
Valuable • If there is no value, then it is a waste
Estimable • There is enough information to estimate the effort
Small • Small enough to be estimable
• Without testing there is no knowledge of achievement

Testable • Given, When, Then

User Stories and the Backlog
• ROLE – is the user of the element
• GOAL – is what they want to accomplish
• BENEFIT – is the business value it provides
Describes the value from a users perspective of the value of the element to be
developed
The backlog is a collection of Stories that are arranged in priority

order by value
Rqmts
Description – details of the story, technical, logistic, timing, etc.
Epic
Acceptance Criteria” Feature
• Give – initial condition Story
• When – stimulus Task
• Then – Final condition
User Story Examples
• As a consumer, I want shopping cart functionality to easily purchase
items online.
• As an executive, I want to generate a report to understand which
departments need to improve their productivity.
• As a developer, I want to publish the current state of my application
to an update set, so that I can deploy it to a production system.
• As a customer, I want to receive notifications when an incident is
commented, so that I am updated on the status.
• As a change manager, I want to enable the assessment of risk for any
given change by establishing a list of questions with multiple choice
answers.
Given that we have Emerging Requirements what do we do?
• First embrace that new requirements will be coming in as we progress

through the project/program
• Review the business value of each new Feature or Story to ensure the
highest business value
• Ensure that we are not over-specifying or adding extra features that
add to wasted time and effort for which the customer or marketplace
in not willing to pay
• Groom the backlog on a cadence so that new requirements can be
added and the backlog order reprioritized

Relative Priority to achieve a singularity
• Develop a single priority list which has the order of importance visible
in the ranking
• Using this method provided a means for adding, subtracting or

changing order as new information is provided
• It clearly shows the relative priority of one element to another
Risk/Technology adjusting a Backlog
• Perform a risk analysis on the backlog to determine items that need
to be learned early in the development cycle
• Move the most risky element up in priority
• Review the backlog to see what technology items must be completed
before business items
• Backlogs can be adjusted by ROI
or Risk calculations

Creating the Product Backlog and
Uncertainty
• Ziv’s Uncertainty Principle
• Uncertainty is inherent and inevitable in (Software) development processes
and products
• Humphrey’s Requirements Uncertainty Principle
• For a new (Software) system the requirements will not be completely known
until the users have used it
• Wegner’s Lemma
• It is not possible to complete specify an interactive system
Filling the Product Backlog is an ongoing process based on feedback

Building a backlog
• The Backlog is made
up of a hierarchy of
Epics → Features →
Stories
• Decompose an Epic
into Features
• Decompose Features
into Stories in
preparation for Sprint
Planning

A deeper view of the Product Backlog
• Owned and
prioritized by the
Product Owner
• Anyone in the Org
can add to the
backlog
• Discipline: “If it is
not on the backlog
it doesn’t exist

Backlog grooming based on Team velocity

Product Roadmaps
Story map
Release map
Encourage Stakeholder involvement

The Product Backlog Lifecycle
• The Product Backlog has no end – it is never finished unless the
activity is not longer needed
• The Product Backlog should be groomed on a regular cadence
• The Product Backlog evolves to meet the Feedback received from
customers and the marketplace
Released
New Items
Elements

Roles and Responsibilities in Scrum
Deliver Business Objects Develops and maintains the Product
based on Stakeholder needs Backlog and is communication link between
and define sprint goals the team and Stakeholders
Develop and
commit to the Product Owner
Sprint Backlog Feedback Provides product
needs, guidance
and feedback
Commit to
delivering the Stakeholders
Scrum Team
sprint goals
Manages the Scrum Process, Maintains metrics

works Retrospective
actions and removes Scrum Master
impediments
The Product Owner
• Has been referred to as the Single

Project Throat to Choke
• Responsible to deliver a successful
product:
• Vision Product Owner
• Business Objectives
• Priorities
• Minimum Viable Product
• Minimum Marketable Features
• Clearly articulates Stories to team
• Performance expectations
• Release dates

Product Owner Attitude
• Is open to negotiation from the team and Stakeholders

• Team – Sequencing (discussed further in the team section)
• Stakeholders – being able to embrace change in the market or Corporate needs
• Is business focused
• Best value for the least work for customer satisfaction (Lean)
• Comfortable in front of people telling the product or service story and
representing the team
• Can come from the ranks of Product Manager, Marketing Manager,
Project Manager or in a case of Services a Customer

Being Open to Uncertainty
• It is impossible to know all of the requirements in advance
• We tried that with Waterfall and had less that stellar results
• By educated assumption we can add areas of interest to the backlog
for further refinement
Requirements will emerge from customers in specific and the
marketplace in general
• The answer is Rapid Cycles of Learning will provide insight into what is
needed and when
• One of the 7 Lean Principles – Learn First

Product Owner Actions
• Develops the product roadmap
• A roadmap for Stakeholders on
product direction
• Prioritizes Features for the product or
service
• Maintains just enough detail for the
teams to be able to engaging in the
next level of planning
• Provides a longer view for the team
where the they are heading

Methods for visualizing the work
• Determine the flow of work
• Break it into work packages that make sense for the project
• Put in a place for everyone to see
• This transparency will show both the team and management the status of
where the project stands at any one time
• Generally estimates are not accurate so by visualizing the work
everyone can see how long it takes and any issues confronting the
work getting completed
• So how does this work?

Kanban Development
Kanban (Card) comes from minimizing work in process (WIP) in
manufacturing. It is a visual way to see Software development efforts
Kanban workflow principles:
• Visualize the workflow
• Limit WIP – Little’s law
• Manage Flow
• Make Process Policies Explicit
• Improve Collaboratively
(using models & the scientific method)

Little’s Law – WIP (Kanban)
Lead Time = WIP* (units) / ACR** (units per time period)
• To reduce the lead time – to get something completed for a given
units per time requires a reduction in WIP
*WIP – Work in Process

**ACXR – Average Completion Rage
David Anderson is a leader in this methodology

http://www.djaa.com/brief-history-kanban-knowledge-work

Visibility board example with WIP limits
• Littles Law can be applied when analyzing this visibility board

Value Stream Mapping
• What value does VSM bring to a Program?
• It lays out the process from end to end and shows the steps necessary to
complete the objective
• Methods for creating a VSM
• What is it that the program will deliver?
• What is the current process?
• Where are the delays, waste and constraints?
• What is the vision for the future state and create that flow
• Revisit the VSM regularly to see if other improvements can be made
• Identify who is the process owner
• Gather a team that has input to the process for a broad perspective of what
needs to change
• May be part of a Kaizen activity – Kaizen’s definition is positive change

Actual VSM used to improve asset management
Generic Datacenter Asset Management flow
– Current State As-Is Asset Mngt Process – Level 1 VSM
Owner: Asset Management

Suppliers:
Customers:
Business & Product Groups,
Business Groups, Product Groups
HW Vendors W Rework
Queue
8.0
Manual
Process
V V
W W Rework W Rework Migrate
W Rework
W Rework
Pre-Racked vs. Wait Details TBD
Individual servers Time Queue Blocked Queue
Queue
Tickets Queue
1.0 2.0 3.0 4.0 5.0 6.0 7.0
Manual Manual Manual Manual Manual
10.0
Process Process Process Process Process Manual
Update & Share Process
Procure (Asset information Receive & Acquire Stage & Transport Deploy Manage Decom
from HW Vendors) Disposal
W Rework
Queue
9.0
Manual
Process
V
Retire
- 24/7 DC
- New Products - Lights out Facility W Rework
- Networking Equipment - MSFT DC

Queue
V V
Rework V Concurrent Asset Update & Deployment W Rework
V Details TBD
11.0
Rework
- MiV / UPUSHDirect
- iAdmin Updates
W Rework
Manual
PRD Queue Process
Onsite Vendor Schedule Queue
Internal
2.1 3.1 4.1 5.1 Rework
6.1 7.1 Re-Use
Manual Manual Manual Manual Manual
Process Process Process Process Process
AX iAdmin Hard Drive Audit
Order Updates Order Updates Asset Updates Audit
Updates (Security Classification)
Migrate
Total Process Time: xxx days.
Process Time: TBD
Audit Decom Retire
Work Time: TBD
Process Time: 2 d Process Time: TBD Process Time: TBD Process Time: TBD Audit Process Time: 20% DCs over 1Q Process Time: TBD # Rsrcs: TBD Process Time: TBD
Work Time: TBD Work Time: TBD Work Time: TBD Work Time: TBD # Rsrcs: TBD Work Time: TBD SLA: Same DC 36 – Diff DC 51 days
Work Time: TBD
# Rsrcs: 1.0 # Rsrcs: 2-3 # Rsrcs: 1-4 # Rsrcs: 1-10+ SLA: N/A # Rsrcs: TBD ASM Min-Max: 1 – 49.2 Hrs.
# Rsrcs: TBD
SLA: N/A SLA: N/A SLA: N/A SLA: 73 Days (SNEN) ASM Min-Max: N/A SLA: 33 Days ASM Avg: 16.8 Hrs.
SLA: N/A
ASM Min-Max: N/A ASM Min-Max: N/A ASM Min-Max: N/A ASM Min-Max: .1 – 37.6 Hrs. (Process steps 2.0 and 5.0) ASM Avg: N/A ASM Min-Max: .1 – 23.6 Hrs. ASM Min-Max: .1 - 24.2 Hrs.
ASM Avg: N/A ASM Avg: N/A ASM Avg: N/A ASM Avg: 11.5 Hrs. (Process steps 2.0 and 5.0) ASM Avg: 11.3 Hrs. ASM Avg: 11.5

Example CFD – Controlled WIP limits

CFD with out of control WIP
Large WIP

Managing Risk
• Risk Severity = Risk Probability x Risk Impact
• This method is the same for WF or Agile projects
• Scores can be developed and managed as they are resolved
• Can be charted in many ways – one is a Risk burndown chart

Change Management
• Satir Curve of change
• Note the “where scared
people quite” part of the
curve
• Note how deep the Dip can
be
• Reinforce WiiF(Them)

ADKAR Explained

Q&A

Thank you!

Jerry Metcalf 102516

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jerry Metcalf 102516

Uploaded by

Copyright:

Available Formats

From Requirements to the Market

Jerry’s experience includes project/program management, strategic planning, portfolio

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 4

• Dynamic Systems Development Method (DSDM)

• Crystal Family of Methods

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 5

Time Dynamic Cost Scope - Dynamic

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 6

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 7

Lean Software Development: An Agile Toolkit, Tom and Mary Poppendieck

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 10

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 11

Lean Waste Description

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 12

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 13

Sprint Review Meeting

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 14

• Agile - to reduce cost Lean

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 15

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 17

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 18

• All are methods for attaining requirements for the project.

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 19

Negotiable • Make tradeoffs with Stakeholders

Valuable • If there is no value, then it is a waste

Estimable • There is enough information to estimate the effort

Small • Small enough to be estimable

• Without testing there is no knowledge of achievement

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 21

The backlog is a collection of Stories that are arranged in priority

• First embrace that new requirements will be coming in as we progress

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 24

• Using this method provided a means for adding, subtracting or

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 26

Filling the Product Backlog is an ongoing process based on feedback

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 27

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 28

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 29

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 30

Encourage Stakeholder involvement

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 31

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 32

Manages the Scrum Process, Maintains metrics

• Has been referred to as the Single

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 34

• Is open to negotiation from the team and Stakeholders

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 35

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 36

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved 37

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 38

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 39

*WIP – Work in Process

David Anderson is a leader in this methodology

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 40

• Littles Law can be applied when analyzing this visibility board

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 42

Owner: Asset Management

- Networking Equipment - MSFT DC

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 43

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 44

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 45

Copyright © 2016 Allegro Business Solutions LLC. All Rights Reserved 46