How to shift from a project based software delivery to product based software delivery

1. Moving from Project to Product
Based Software Delivery
Kawaldeep Chadha
Enterprise Agile Coach
May 30, 2019

2. Project Based Approach
• Too many small projects being executed in parallel
• Lack of relative project priorities
• Small teams of 1 or 2 developers created for the project
• Developers supporting multiple projects
• Too many meetings
• Lack of predictability
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 28/16/2019

3. Product Based Approach
• Whole Product Focus
• Define the Product
• Product Roadmap / Value Stream
• Stable cross-functional feature teams
• Better prioritization and alignment with organizational goals
• Eliminate/Reduce dependencies
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 38/16/2019

4. Project Y
Project X
FunctionalTeamA
FunctionalTeamB
FunctionalTeamC
Team 1 Team 2 Team 3 Team 4
Product
Customer
Focus from Internal Structure to Customer
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 48/16/2019

5. Roles
• Finding the right Product Owner
• Product development for external users
• Product Manager
• Product development for internal users
• Someone from the group that will use the system
• Curator/Indexer
• Finding the right Scrum Master
• Project Manager
• Functional Manager / Supervisor
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 58/16/2019

6. Conway’s Law
• “….organizations which design systems….are constrained to produce
designs which are copies of the communication structures of these
organizations”
Melvin E. Conway, April 1968
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 68/16/2019

7. Team Based Organization
• Dedicated – Each team member dedicated 100% to one team
• Cross-Functional: Contains all functional skills within the team.
Reduces dependencies
• Co-located: Promotes team learning and trust
• Long-Lived: Stable teams work better together
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 78/16/2019

8. Organizational Structure
• Stable teams as a basic organizational building block
• Most teams are customer-focused feature teams
• Scrum Master is a dedicated full-time role.
• Scrum Master can serve 1-3 teams
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 88/16/2019

9. Product
• One Product Owner and one Product Backlog for the complete
shippable product
• All prioritization goes through the Product Owner
• Definition of product should be as broad and end-user/customer
centric as possible
• One Definition of Done for the whole product common for all teams
• Each team can expand the Definition of Done for their need
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 98/16/2019

10. Defining the Product
• Who are the actual end-customers and what do they consider the
product to be?
• What is the problem the product is solving?
• Can you state a clear vision of the product?
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 108/16/2019

11. Program (Sequence Submission)
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 118/16/2019
Program Backlog
Item1
Item2
Item3
Item4
Product Backlog
Item3
Item4
Product Backlog
Item1
Item2
Sequence
Submission
Submission
Portal
SMART
Product Backlog
Item
Item
Shared
Services
Product Backlog
Item
Item
SRA
Product
Manager
(PrdMgr)
Product
Owner
(PO)
Feature
Team(s)
Feature
Team(s)
Feature
Team(s)
Feature
Team(s)
Product
Owner
(PO)
Product
Owner
(PO)
Product
Owner
(PO)
Product Team
PO
POPO
PO
Prd
Mgr
• Product Manager manages priorities
at Program Level
• Product Team consisting of Product
Manager and Product Owners
 Vision
 Program and Product
Roadmaps
 Plan Releases
 Inter-Product dependencies
• Products
 Submission Portal
 SMART
 SRA
 Shared Services
 …….
 ……..

12. Program / Product Artifacts
• Program Backlog
• Prioritized list of all product features for the program
• Product Roadmap
• Product Plan / Strategic Plan for 12 months
• Contains Release Dates, Goals, Features, Metrics to determine if goal has been met
• Product Backlog
• Prioritized list of Epics (large user stories), User Stories, Enhancements, Bugs,
Technical Debt
• Release Plan (for each Product)
• Timeframe is Variable (no more than 3 to 6 months)
• Contains Team Velocity (actual or estimate), # of Sprints, Prioritized Product Backlog
• Release Burndown
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 128/16/2019

13. Team Artifacts
• Sprint Backlog
• Prioritized list of user stories and detailed tasks that can be completed within
a sprint
• Software Increment
• Sum of all backlog items completed during the sprint, in a useable condition
and meets the team’s Definition of Done
• Sprint Burndown
• Measured in story points or hours and updated on a daily basis
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 138/16/2019

14. Framework
• SPRINT
• One Product-Level sprint (If possible, one program level sprint)
• Each team starts and ends sprint at the same time
• Each team has their own sprint backlog
• Each Sprint results in an integrated whole product
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 148/16/2019

15. Framework
• Sprint Planning
• Consists of two parts
• Sprint Planning One is common for all teams
• Attended by PO and Teams or Team representative
• Tentatively select items that each team will work on that sprint
• Teams identify opportunities to work together
• Sprint Planning Two is done separately for each team
• Decide how they will do the selected items (involves design and tasking of the sprint
backlog)
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 158/16/2019

16. Framework
• Daily Scrum
• Each Team has their own Daily Scrum
• Cross-team coordination is decided by the teams (maybe Scrum of Scrums,
twice a week)
• Product Backlog Refinement
• Preferably done with multiple teams to increase shared learning
• Exploit coordination opportunities
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 168/16/2019

17. Framework
• Sprint Review
• One sprint review common for all teams
• Insure all suitable stakeholders are invited
• Sprint Retrospective
• Each team has its own sprint retrospective
• An overall retrospective is held after team retrospective to discuss cross-team
and system-wide issues and create improvement experiments. This is
attended by PO, Scrum Masters, Team representatives, and managers (if any)
Prepared by Kawaldeep Chadha, Enterprise Agile Coach 178/16/2019