This document discusses applying the concept of a value stream manager to software development organizations. It defines a value stream manager as someone assigned responsibility for the success of a value stream, who focuses the organization on value creation through influence rather than authority. The value stream manager role is modeled after the Toyota chief engineer role. The document also provides examples of using Lean tools like A3 reports, stakeholder maps, and cumulative flow diagrams to help value stream managers improve processes and reduce lead times.

1. APPLYING THE VALUE STREAM
MANAGER CONCEPT TO
SOFTWARE DEVELOPMENT
ORGANIZATIONS
Ken Power

2. About me
• My day job
§ Co-Founder, Agile Office at Cisco
§ Internal Agile & Lean Consultant
• Extra-curricular activities
§ Fellow of the Lean Systems Society (http://LeanSystemsSociety.org/)
§ Award-winning publications in Agile and Lean product development
§ Frequent speaker at major international Agile and Lean conferences
§ Involved in organizing international Agile and Lean conferences
§ Industry/academic collaborative research on Agile and Lean software
development
§ Blog: http://SystemAgility.com/
§ Twitter: @ken_power

3. DIFFERENT PERSPECTIVES
ON ORGANIZATION
STRUCTURE

4. The Hierarchical Perspective
• Is your organization is
a reflection of what it
says in the
Organization Chart?
• A collection of titles and
functional areas?

5. The Social Network Perspective
• Is your organization
the set of diverse
relationships that cross
functional boundaries?

6. The Information Flow Perspective
• Is your organization
represented by the
currents of information
that flow through the
network?

7. All are true to some degree
Remember:
(1) All models
are wrong,
but some are
useful
(2) More than
one thing can
be true

8. Value Stream Map

10. Value Streams
• Whole products or systems
• Product lines
• Portfolios
• Cross-cutting portfolio or product line elements

11. Filling the Role
• TPS and the Chief Engineer Role
• Scrum Product Owner
• Product Champion
• Leads the development team in discovering what the customer
really needs
• Responsible for the quality of the product

13. Value Stream Manager
• An individual assigned clear responsibility for the
success of a value stream.
• The value stream may be defined on
• the product or business level (including product development), or
• the plant or operations level (from raw materials to delivery).
• The value-stream manager is the architect of the value
stream, identifying value as defined from the customer’s
perspective and leading the effort to achieve an ever-
shortening value-creating flow.
• The value-stream manager focuses the organization on
aligning activities and resources around value creation,
though none of the people or resources (money, assets)
may actually “belong to” the value stream manager.
http://www.lean.org/Common/LexiconTerm.aspx?termid=362

14. Leading Through Influence
• Value stream management distinguishes between
responsibility, which resides with the value-stream manager,
and authority, which may reside inside functions and
departments holding the resources.
• The role of the functions is to provide the people and resources
needed to achieve the value-stream vision, as defined by the
value-stream manager.
• The value-stream manager leads through influence, not
position, and thus can be equally effective in a traditional
functional organization or in a matrix organization, avoiding the
common failure of matrix organizations, which is the loss of
clear responsibility, accountability, and effective decision-
making.
• The archetype for the role of the value-stream manager is the
Toyota chief engineer, who has only minimal staff and
resources under his direct control.
http://www.lean.org/Common/LexiconTerm.aspx?termid=362

15. Quadrants of Responsibility
• Prioritization • Technical Requirements
• Customer • Technology Direction
Requirements • Technology Strategy
• Revenue • Engineering Investment
(People)
• Dependencies
Development
Product
(Tactical,
(Strategic)
Operational)
Quality
(Product
Quality, Program
Continuity, (Organization)
Customer
Focus)
• Engineering • Process Owner
Investment (People) • Stakeholder Engagement
• Quality Direction • Dependency Management
• Quality Strategy • Objectivity
• Quality Requirements • Continuous Inspection &
Adaption

17. Freeman’s Basic 2-tier model The Firm
Government Primary
Stakeholders
Competitors
Media Communities Secondary
Customers
Stakeholders
Financiers
Employees
Suppliers
Special
Interest Customer
Groups Advocate
Groups

18. Scrum Master
Product
Owner
Cross-Functional
Delivery
Team
Scrum
Team
Product Owner Team
System User
Portfolio Experience Extended Delivery Team
Council Team
Other
Business
Units Product Developme Beta
TME nt
Manager GB
Manager
Channel UE
Program Product Alpha
Ramp Lead
Manager
Early Sales
Access Architect Support
QA
Program Manager Engineers
Tech Customer
Support Engagement
Team Product Team
Marketing

19. Stakeholder Management Principles
1. Stakeholder interests need to 6. We need intensive
go together over time. communication and dialogue
2. We need a philosophy of with stakeholders – not just
volunteerism – to engage those who are friendly.
stakeholders and manage 7. Stakeholders consist of real
relationships ourselves rather people with names and faces
than leave it to government. and children. They are complex.
3. We need to find solutions to 8. We need to generalize the
issues that satisfy multiple marketing approach.
stakeholders simultaneously. 9. We engage with both primary
4. Everything that we do serves and secondary stakeholders.
stakeholders. We never trade 10. We constantly monitor and
off the interests of one versus redesign processes to make
the other continuously over time. them better serve our
5. We act with purpose that fulfills stakeholders.
our commitment to stakeholders.
We act with aspiration towards
fulfilling our dreams and theirs.

20. The Role of Manager
“Whatever the magnitude of their stake, each stakeholder is a part of the nexus of
implicit and explicit contracts that constitutes the firm. However, as a group,
managers are unique in this respect because of their position at the centre of the
Managers are the only
nexus of contracts.
groups of stakeholders who
enter into a contractual
relationship with all other
stakeholders. Managers are also the only group of
direct control over the
stakeholders with
decision-making apparatus of the firm.”
(Hill & Jones, 1992: 134)

21. Who can play the role?
• Someone who can understand the complexities of your
product lines, your customers and your organization.
• Good candidates:
• Program Managers
• Engineers
• Technical Leaders
• Architects
• Good, but often too busy:
• Product Managers
• Engineering Managers (can be good coaches or mentors for
Value Stream Managers)

22. Use Lean Management Thinking
• Use A3 Problem Solving reports to help people develop
as Value Stream Managers
• Improve their Problem Solving skills
• Help people learn how to navigate the organization

23. Stakeholder Mapping for Product
Architecture Product Architecture
Client Development
Teams: ‘Late integrators’ Primary Stakeholders
3rd Party
Developers
Customers
Client Development
Media Teams: ‘Early Integrators’
Architecture
Teams
Secondary
User Stakeholders
Experience
Teams Other
Product Business
Management Units
API QA
Client Teams
Application Tech
QA API Development Support
Teams Team Team
Special
Interest Test Automation
Groups Team
System Test
Team

25. Basic Flow
Portfolio Architecture Assign Product/
Request Delivery Release
Team Team VS Component Team(s) Products
Review Evaluation Manager PO Team
“I have an • Priioritize • Technical • Detailed • Prioritize • Design, develop,
idea or a this request evaluation Technical work within deliver
problem to • Align with • Decide the evaluation a Product
solve” Portfolio appropriate • End-to-end or
place for consistency Component
implementa • Work across • Consider all
tion entire VS sources of
• Architecture input
consistency
User Story
Acceptance Criteria
Acceptance Criteria
User Story
Acceptance Criteria
User Story
Acceptance Criteria
Acceptance Criteria
User Story
Acceptance Criteria
Acceptance Criteria
Acceptance Criteria
Low-Level Story
Low-Level StoryAcceptance Criteria
Low-Level Story
Acceptance Criteria
Acceptance Criteria
Low-Level Story
Acceptance Criteria Acceptance Criteria
Low-Level Story
Acceptance Criteria
Acceptance Criteria
Low-Level Story
Acceptance Criteria Acceptance Criteria
Acceptance Criteria
Acceptance Criteria
Acceptance Criteria

26. Example: Cross-Portfolio Architecture
Planned Ready In Progress Done
This is our Planned policy. We This is our Ready We will start work on something Work Items are declared
will plan something when …. policy. Thanks for when …. ‘Done’ when ….
reading.
Request Queue
(Backlog)
Portfolio Technical Items We always From here, go to
Backlog Steering are have visibility Team backlogs;
Team Ready on work in
Backlog to begin progress by Deliverables include
the whitepaper,
Architecture prototype, user
team stories, detailed
requirements, etc.

27. Portfolio Architecture Assign Product/ Delivery Release
Team Team VS Component Team(s) Products
Review Evaluation Manager PO Team
Portfolio
Product
Product
Product
Product
Product
Product
Feature
Stack Teams
Task
Task
Task
Task
Task
Low-Level Story Task
Acceptance Criteria Task
Low-Level Story Criteria
Acceptance Task
Task
Task
Low-Level Story Criteria
Product
Acceptance
Acceptance Criteria Criteria Story
Acceptance
Low-Level
Acceptance Criteria
Acceptance Criteria
Low-Level Story Criteria
Acceptance
Feature
Acceptance Criteria
Product Line 1
Acceptance Criteria
Product
Low-Level Story
Acceptance Criteria
Acceptance Criteria
Low-Level Story
Product Framework
Acceptance Criteria
Low-Level Story Criteria
Acceptance
Acceptance Criteria
Acceptance Criteria
Product Line 2 Product
Low-Level Story
Task
C1 C3
Acceptance Criteria Task
Task
Acceptance Criteria
Low-Level Story Task
Task
Product
Acceptance Criteria
Task
Low-Level Story Criteria
Acceptance Low-Level Story Task
Task
Task
Task
Acceptance Criteria Acceptance Criteria
Acceptance Criteria Low-Level Story Criteria
Acceptance
Low-Level Story Criteria
Acceptance
Acceptance Criteria Criteria Story
Acceptance
Low-Level
Acceptance Criteria
Acceptance Criteria
Acceptance Criteria
Product
Component 1
Low-Level Story
Acceptance Criteria
Acceptance Criteria
Low-Level Story
Acceptance Criteria
Low-Level Story Criteria
Acceptance
Framework C2
Acceptance Criteria
Acceptance Criteria
Task
Task
Task
Low-Level Story Task
Task
Component 2
Task
Acceptance Criteria Task
C1
Task
Task
Low-Level Story Criteria
Acceptance
Task
Low-Level Story Criteria
Acceptance
Acceptance Criteria Criteria Story
Acceptance
Low-Level
Acceptance Criteria
Acceptance Criteria
Acceptance Criteria
Low-Level Story Task
Task
Task
Acceptance Criteria
Task
Task
Low-Level Story Task
Acceptance Criteria
Low-Level Story Task
C2
Task
Task
Acceptance Criteria Acceptance Criteria Task
Low-Level Story Criteria
Acceptance Low-Level Story Criteria
Acceptance
Low-Level Story
Low-Level Story CriteriaAcceptance Criteria
Acceptance
Acceptance Criteria
Acceptance Criteria Acceptance Criteria CriteriaAcceptance Criteria
Acceptance
Low-Level Story
Acceptance Criteria
Acceptance Criteria
Acceptance Criteria
Ext. Ext. Ext.
C3
Dep. 1 Dep 2 Dep 3

28. Some challenges
• Multiple sources of requirements
• Multi-Faceted Role, Requiring a Broad Skill Set
• Balance decision making
• Manage conflicts
• Deal with multiple reporting lines
• Navigate complicated org structures
• Organization politics
• Danger of Isolation

29. Understanding Lead Time and Cycle Time
http://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/

30. Cumulative Flow Diagrams

31. Value Stream Managers as Change
Enablers
http://stevenmsmith.com/ar-satir-change-model/

32. A3 Management
Focus Problem Solving Proposal Writing Project Status Review
Thematic content or Improvements related to Policies, decisions, or Summary of changes
focus quality, cost, delivery, projects with significant and results as an
safety, productivity, etc. investment or outcome of either
implementation problem solving or
proposal implementation
Tenure of person Novice, but continuing Experienced personnel; Both novice and more
conducting the work throughout career managers experienced managers
Analysis Strong root-cause Improvement based on Less analysis and more
emphasis; quantitative/ considering current focus on verification of
analytical state; mix of quantitative hypothesis and action
and qualitative items
PDCA cycle Document full PDCA Heavy focus on the Plan Heavy focus on the
cycle involved in making step, with Check and Act Check and Act steps,
an improvement and steps embedded in the including confirmation of
verifying the result implementation plan results and follow-up to
complete the learning
loop
From Table 5.1 from “Understanding A3 Thinking”

33. John Clifford, Construx
http://forums.construx.com/blogs/johnclif/archive/2009/09/30/if-you-want-to-improve-stop-managing-your-problems.aspx

35. Applications of A3 Proposal Writing
• Create a Value Stream Manager role to help with Portfolio
Backlog Management
• Align all products and components on a quarterly commit
cadence
• Ensure architecture consistency across multiple product
lines

36. Applications of A3 Problem Solving
• Reduce Cycle Time for Portfolio Architecture Analysis
• Reduce Product delivery cadence from 6+ months to 3
months
• Reduce the Lead Time for high priority customer requests

37. Summary
• Empower people to be Value Stream Managers
• Develop their skills as Problem Solvers
• Help them navigate the organization
• Develop them as enablers of change
• Use Stakeholder Maps to show who is affected
• Use Value Stream Maps to show the flow
• Use CFDs, Cycle Time and Lead Time to show delays
(waste) and opportunities for improvement
• Use A3 Problem Solving and Proposal Writing to enable
Lean thinking and to optimize your Value Streams

38. Thank You!