Value Stream Manager concept applied to Software Product Development

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

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

DIFFERENT PERSPECTIVES ON ORGANIZATION STRUCTURE

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

functional areas?

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

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

All are true to some degree Remember: (1) All models

are wrong, but some are useful

(2) More than one thing can be true

Value Stream Map

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

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

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

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

Quadrants of Responsibility

•  Process Owner •  Stakeholder Engagement •  Dependency Management •  Objectivity •  Continuous Inspection &

Adaption

•  Engineering Investment (People)

•  Quality Direction •  Quality Strategy •  Quality Requirements

•  Technical Requirements •  Technology Direction •  Technology Strategy •  Engineering Investment

(People) •  Dependencies

•  Prioritization •  Customer

Requirements •  Revenue

Product (Strategic)

Development (Tactical,

Operational)

Program (Organization)

Quality (Product Quality,

Continuity, Customer

Focus)

The Firm

Primary Stakeholders

Secondary Stakeholders

Communities

Financiers

Suppliers

Employees

Customers

Customer Advocate Groups

Special Interest Groups

Media

Government

Competitors

Freeman’s Basic 2-tier model

Cross-Functional Delivery

Team

Scrum Master

Product Owner

Scrum Team

Product Manager

QA Manager

Development

Manager

Program Manager

Alpha

Beta TME

Early Access

Program

User Experience

Team

Product Marketing

Channel Ramp

Other Business

Units

GB

Tech Support Team

Product Owner Team

Extended Delivery Team

Product

System Portfolio Council

Sales Support

Engineers

Customer Engagement

Team

UE Lead

Architect

Stakeholder Management Principles 1.  Stakeholder interests need to

go together over time. 2.  We need a philosophy of

volunteerism – to engage stakeholders and manage relationships ourselves rather than leave it to government.

3.  We need to find solutions to issues that satisfy multiple stakeholders simultaneously.

4.  Everything that we do serves stakeholders. We never trade off the interests of one versus the other continuously over time.

5.  We act with purpose that fulfills our commitment to stakeholders. We act with aspiration towards fulfilling our dreams and theirs.

6.  We need intensive communication and dialogue with stakeholders – not just those who are friendly.

7.  Stakeholders consist of real people with names and faces and children. They are complex.

8.  We need to generalize the marketing approach.

9.  We engage with both primary and secondary stakeholders.

10.  We constantly monitor and redesign processes to make them better serve our stakeholders.

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

nexus of contracts. Managers are the only groups of stakeholders who enter into a contractual relationship with all other stakeholders. Managers are also the only group of

stakeholders with direct control over the decision-making apparatus of the firm.”

(Hill & Jones, 1992: 134)

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)

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

Product Architecture

Primary Stakeholders

Secondary Stakeholders

Architecture Teams

Client Development Teams: ‘Early Integrators’

API Development Team

API QA Teams

Product Management

Test Automation Team

Special Interest Groups

Media

3rd Party Developers

Customers

User Experience Teams

System Test Team

Client Development Teams: ‘Late integrators’

Other Business

Units Client

Application QA

Teams

Tech Support

Team

Stakeholder Mapping for Product Architecture

Basic Flow Request

Portfolio Team

Review

Product/ Component PO Team

Delivery Team(s)

Architecture Team

Evaluation

Assign VS

Manager

“I have an idea or a

problem to solve”

•  Priioritize this request

•  Align with Portfolio

•  Technical evaluation

•  Decide the appropriate place for implementation

•  Architecture consistency

•  Detailed Technical evaluation

•  End-to-end consistency

•  Work across entire VS

•  Prioritize work within a Product or Component

•  Consider all sources of input

•  Design, develop, deliver

Release Products

Low-Level Story

Acceptance Criteria Acceptance Criteria Low-Level Story


Acceptance Criteria Acceptance Criteria

User Story

Acceptance Criteria Acceptance Criteria User Story


User Story


User Story


Low-Level Story




Planned Ready In Progress Done This is our Ready policy. Thanks for

reading.

From here, go to Team backlogs;

Deliverables include

whitepaper, prototype, user stories, detailed

requirements, etc.

We always have visibility

on work in progress by

the Architecture

team

Technical Steering

Team Backlog

Request Queue (Backlog)

This is our Planned policy. We will plan something when ….

We will start work on something when ….

Work Items are declared ‘Done’ when ….

Portfolio Backlog

Example: Cross-Portfolio Architecture

Items are

Ready to begin

Portfolio

Feature Stack

Product

Product

Product

Product

Product

Product

Framework

C1

C2

C3

Pro

duct

Pro

duct

Pro

duct

Pro

duct

Pro

duct

Pro

duct

Framework

C1

C2

C3

Ext. Dep. 1

Ext. Dep 2

Teams

Product Line 1

Component 1

Feature

Product Line 2

Component 2

Low-Level Story




Low-Level Story




Low-Level Story




Low-Level Story




Low-Level Story




Low-Level Story


Low-Level Story




Low-Level Story


Low-Level Story




Low-Level Story


Low-Level Story




Low-Level Story


Low-Level Story


Low-Level Story


Task Task Task Task Task Task Task

Task Task Task

Task Task Task Task Task Task Task Task Task Task



Ext. Dep 3

Portfolio Team

Review

Product/ Component PO Team

Delivery Team(s)

Architecture Team

Evaluation

Assign VS

Manager Release Products

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

Understanding Lead Time and Cycle Time

http://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/

Cumulative Flow Diagrams

Value Stream Managers as Change Enablers

http://stevenmsmith.com/ar-satir-change-model/

A3 Management Focus Problem Solving Proposal Writing Project Status Review

Thematic content or focus

Improvements related to quality, cost, delivery, safety, productivity, etc.

Policies, decisions, or projects with significant investment or implementation

Summary of changes and results as an outcome of either problem solving or proposal implementation

Tenure of person conducting the work

Novice, but continuing throughout career

Experienced personnel; managers

Both novice and more experienced managers

Analysis Strong root-cause emphasis; quantitative/analytical

Improvement based on considering current state; mix of quantitative and qualitative

Less analysis and more focus on verification of hypothesis and action items

PDCA cycle Document full PDCA cycle involved in making an improvement and verifying the result

Heavy focus on the Plan step, with Check and Act steps embedded in the implementation plan

Heavy focus on the Check and Act steps, including confirmation of results and follow-up to complete the learning loop

From Table 5.1 from “Understanding A3 Thinking”

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

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

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

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

Thank You!

Value Stream Manager concept applied to Software Product Development

Business

Transcript of Value Stream Manager concept applied to Software Product Development