jerry.metcalf.102516.pptx

Copyright © 2015 Allegro Business Solutions LLC. All Rights Reserved
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

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/
About Allegro Business Solutions
2

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

• 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
What is an Agile Project?
4

• 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, …
Specific Agile Methods
5

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

• 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
Introduction to Lean
7

• 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
Specifics of Lean thinking today
8
From the Lean Enterprise Institute
“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."

Mary and Tom Poppendieck have been the major proponent of Lean
Software development
Lean Software Development
9
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

• 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
The 7 principles of Lean development
10

Lean Software Development – the Wastes
11
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

• Based on the 7 wastes in Lean the following are examined as not
adding to value
Delivering Value Assessment
12
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
13
https://www.scrumalliance.org/why-scrum

The Scrum Framework
14
Product Backlog
• Groomed, prioritized
Features in story form
Sprint Planning Meeting
• Review Product backlog
• Estimate Sprint backlog
• Commit to Sprint timebox
• Communicate Sprint Goals
Sprint Backlog
• Stories estimated by team
• Task breakdown by team
Daily Standup
• What was done yesterday?
• What will be done today?
• Impediments - Blockers?
Business Ideas
• Epics and Features for
scrum team
Iteration Timebox
• 2 to 4 weeks
Potentially Shippable Items
Sprint Review Meeting
• Demo and Acceptance of
Sprint stories
Retrospective
• Inspect and Adapt

Lean – Agile/Scrum relationship
15
Lean
Scrum Team
Scrum Team
Lean Principles
• Lean Principles - to
reduce waste without
frustrating customers
• Agile - to reduce cost
to make changes that
reduce time to market

Process Combination
Scrum
Lean
XP
Scrum - for the way we
plan, organize and manage
our work
XP – for Development
discipline
Lean – for the overall way
we think

• 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
Keep a keen eye on Business Value
17

• 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
Backlog Grooming – Lean thinking
18

• 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.
Gaining Stakeholder feedback
19

• 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?
Backlog grooming implications
20

Method for determining an effective Story
21
• Able to be build in any order
Independent
• Make tradeoffs with Stakeholders
Negotiable
• If there is no value, then it is a waste
Valuable
• There is enough information to estimate the effort
Estimable
• Small enough to be estimable
Small
• Without testing there is no knowledge of achievement
• Given, When, Then
Testable

User Stories and the Backlog
22
• 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
Description – details of the story, technical, logistic, timing, etc.
Acceptance Criteria”
• Give – initial condition
• When – stimulus
• Then – Final condition
Rqmts
Epic
Feature
Story
Task

• 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.
User Story Examples
23

• 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
Given that we have Emerging Requirements what
do we do?
24

• 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
Relative Priority to achieve a singularity
25

• 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
Risk/Technology adjusting a Backlog
26

• 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
Creating the Product Backlog and Uncertainty
27

Building a backlog
28
• 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
29
• 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
30

Product Roadmaps
31
Story map
Release map
Encourage Stakeholder involvement

• 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
The Product Backlog Lifecycle
32
New Items
Released
Elements

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

The Product Owner
34
• Has been referred to as the
Single Project Throat to Choke
• Responsible to deliver a
successful product:
• Vision
• Business Objectives
• Priorities
• Minimum Viable Product
• Minimum Marketable Features
• Clearly articulates Stories to team
• Performance expectations
• Release dates
Product Owner

• 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
Product Owner Attitude
35

• 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
Being Open to Uncertainty
36

Product Owner Actions
37
• 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

• 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?
Methods for visualizing the work
38

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)
Kanban Development
39

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
Little’s Law – WIP (Kanban)
40
David Anderson is a leader in this methodology
http://www.djaa.com/brief-history-kanban-knowledge-work
*WIP – Work in Process
**ACXR – Average Completion Rage

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

• 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
Value Stream Mapping
42

Actual VSM used to improve asset management
43
Generic Datacenter Asset Management flow
– Current State As-Is
Suppliers:
Business & Product Groups,
HW Vendors
Receive & Acquire
3.0
Procure
1.0
Update & Share
(Asset information
from HW Vendors)
2.0
Customers:
Business Groups, Product Groups
Manage
6.0
Rework
Process Time: TBD
Work Time: TBD
# Rsrcs: 2-3
SLA: N/A
ASM Min-Max: N/A
ASM Avg: N/A
Process Time: TBD
Work Time: TBD
# Rsrcs: 1-4
SLA: N/A
ASM Min-Max: N/A
ASM Avg: N/A
Process Time: TBD
Work Time: TBD
# Rsrcs: 1-10+
SLA: 73 Days (SNEN)
ASM Min-Max: .1 – 37.6 Hrs. (Process steps 2.0 and 5.0)
ASM Avg: 11.5 Hrs. (Process steps 2.0 and 5.0)
Process Time: TBD
Work Time: TBD
# Rsrcs: TBD
SLA: 33 Days
ASM Min-Max: .1 – 23.6 Hrs.
ASM Avg: 11.3 Hrs.
Decom
7.0
Owner: Asset Management
Asset Mngt Process – Level 1 VSM
Stage & Transport
4.0
AX iAdmin
Updates
3.1
Manual
Process
Manual
Process
V
V
Pre-Racked vs.
Individual servers
Manual
Process
Order Updates
2.1
Manual
Process
Rework
Order Updates
4.1
Manual
Process
Rework
V
PRD
Onsite Vendor Schedule
Queue
Wait
Time
W
Deploy
5.0
Manual
Process
Asset Updates
5.1
Manual
Process
W
Blocked
Tickets
Queue
V Concurrent Asset Update & Deployment
- MiV / UPUSHDirect
- iAdmin Updates
Rework
Rework
W
Queue
Audit
6.1
Manual
Process
Rework
V
- 24/7 DC
- Lights out Facility
- MSFT DC
W
Hard Drive Audit
(Security Classification)
7.1
Manual
Process
W
Rework
W
Queue
Migrate
8.0
Retire
9.0
Manual
Process
Manual
Process
Manual
Process
Rework
W
Queue
Rework
W
Queue
Disposal
10.0
Manual
Process
Rework
W
Queue
Internal
Re-Use
11.0
Manual
Process
Rework
W
Queue
Process Time: TBD
Work Time: TBD
# Rsrcs: TBD
SLA: Same DC 36 – Diff DC 51 days
ASM Min-Max: 1 – 49.2 Hrs.
ASM Avg: 16.8 Hrs.
V Details TBD
Process Time: 2 d
Work Time: TBD
# Rsrcs: 1.0
SLA: N/A
ASM Min-Max: N/A
ASM Avg: N/A
Details TBD
Rework
Queue
V
- New Products
- Networking Equipment
Total Process Time: xxx days.
Migrate
Decom
Process Time: TBD
Work Time: TBD
# Rsrcs: TBD
SLA: N/A
ASM Min-Max: .1 - 24.2 Hrs.
ASM Avg: 11.5
Retire
Audit Process Time: 20% DCs over 1Q
# Rsrcs: TBD
SLA: N/A
ASM Min-Max: N/A
ASM Avg: N/A
Audit

Example CFD – Controlled WIP limits
44

CFD with out of control WIP
45
Large WIP

• 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
Managing Risk
46

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

ADKAR Explained
48

Q & A
49

Thank you!
50

jerry.metcalf.102516.pptx

More Related Content

Similar to jerry.metcalf.102516.pptx

Recently uploaded

jerry.metcalf.102516.pptx