Value Stream Manager concept applied to Software Product Development
•
7 likes•5,130 views
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.
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (15)
Similar to Value Stream Manager concept applied to Software Product Development
Similar to Value Stream Manager concept applied to Software Product Development (20)
More from Ken Power
More from Ken Power (9)
Recently uploaded
Recently uploaded (20)
Value Stream Manager concept applied to Software Product Development
- 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
- 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
- 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/
- 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”
- 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!