One Team Model – Service Teams

One Team Model – Service Teams
Framework for
LEAN SIX SIGMA
in
LEAN SOFTWARE DEVELOPMENT
Vinod Vijayakumaran
SAP Labs India Pvt. Ltd.
 Vinod Vijayakumaran
 SAP Labs India Pvt. Ltd.
Introduction
Creation of a service team composed with ideal proportion of skill sets which
would help in delivery of quality & reliable service to the development teams
/organization with an efficient and effective process paradigm. At the same
time, not disturbing the existing working model of the service teams
Current Scenario
Product
Development
Team
Checks info mentioned; validates the
need for change; probe more info from
the requestor, if required, etc..
Creates a ‘change request’
1
Seeks approval for change
4
3
5
Internal
Service Teams
2
Checks the ticket for
information to adopt steps
to change
6
Checks for approval and performs
actions to bring change
7
Provides ‘extra approval’ and forwards
ticket to external teams. Eg: H/W issue
Ticketing
Mechanism
Technical &
Release
Mgmt.
Consulting
Team
Provides approval if all pre-requsites met
8
Checks for appropriate approval
approval and performs actions to bring
change
External Service
Teams
Problems in Current Scenario
 Lack of flow in value realization
 Realization of value is late (late value is as good as no value)
 Lot of waiting time
 Lack of transparency in the plans and strategies
 Teams getting dissatisfied doing the same job with no value add
 Customer Dissatisfaction
 Non-compliance to the QCD concept -
High in Cost, Late in Delivery and Medium in quality
 No chance to incorporate steps to resolve customer dissatisfaction
THE ONE TEAM MODEL – Info Flow
1
Checks the ticket for
information to adopt steps
to change
Creates a ‘change request’
2
Product
Development
Team
Ticketing
Mechanism
One Team
3
Ticket Completed /Rejected
THE ONE TEAM MODEL
Development Organization raises ticket for change
System Operations Team
24 X 7
Support
team
Prog 1
Prog 2
Program
Management
Team
Prog 3
Prog n
Plug-Ins
External
Interface
(Decides on
cross program
strategies,
i.e.
activities
affecting
more than
one program)
*Eg: Build
Team,
Admin
, HR
etc…
Quick
Reaction
Team
Quick
Reaction
Team
Quick
Reaction
Team
Quick
Reaction
Team
Quick
Reaction
Team
Virtual Team
Virtual
Team
Cross Landscape - Team of Experts ( OS, DB, etc..)
Internal colleagues (virtual team)
Application know
how resides with
the functional
experts, DEV
ONE TEAM – Team Composition
A
B
B
C
A
A
Product 1
B
B
Eg: Flagship Products
Product 3
Product 2
(Large Programs = Large
Customer Base )
(Small Programs = Nominal
Customer Base )
(Medium Programs = Normal
Customer Base )
C
Eg: Other specific products
C
Eg: Plugins, Addons
B
B
B
C
C
COMPLEX
MEDIUM
LOW
Knowledge Matrix for ONE TEAM
Category In
SCRUM
TEAM
Know the VoC
(Voice of Customer)
Program Knowledge
(Release Strategy, Program
Architecture ..)
Technical Knowledge
related to applications
Knowledge of system
components (OS, DB,
etc..)
A
Expert
Expert
Good
Fair
B
Good
Good
Expert
Good
C
Fair
Fair
Good
Expert
A
ONE TEAM – Features
1.
No FIRST LEVEL support or message dispatching
2.
Service groups will be in agile mode; by following SCRUMBAN within each program areas. This helps in faster response to
incidents.
Colleagues stuck with some issues; will pull the “ANDON”.
3.
More chance of shared accountability and less chance of message not being attended
4.
Very low chances of message ping pong between components and colleagues of diff teams
5.
Chance for more dedicated support for customer pain-points
6.
Quick Reaction Team, formed out of the ONE TEAM
7.
More alignment for support on global issues and follow up.
(Eg: If there are central hardware issues which affects ~40-50 systems; this can be easily communicated and followed-up by
individual one teams)
8.
Realize value for the customer as soon as possible
9.
Reliable information from the responsible colleagues within one team. It will be a collective responsibility of the team to
deliver services
10.
Transparency on strategies and customer requests
11.
Requirement gathering in sprint (n) for next sprint will create the ‘TO DO ‘ List
ONE TEAM – SCRUMBAN for Internal Communications
To-Do  Will be filled with user stories that approaches the team on daily manner. Primarily with requests from PO
In-Process  This will be filled after the team ‘Pulls” activities from To-Do and updates on daily basis
Done  Filled by team after completion of activity