Case: build an IT pool

CaseBuild an IT pool

the Goal:

• Share limited capacity on several projects, application maintenance …

• Basis for a ‘Shared Service Center’

Key points: application of Lean & Agile principles on a real case

Build an IT Pool

7 applications with 3 new for the team

secure the business roadmap

Unbalanced life style for the Team Leader

5 IT & 60% renewed

Manage operational risk

(backup)

Project CharterBuild an IT Pool

the Goal:

• IT team (5 IT) is managing 7 applications (3 are new for the team) with 5 technologies

• Help the team succeed to deliver his roadmap without major problems

Context:• IT team (5 IT) is managing 7 applications with 5 technologies

Problem:• Among the 7 applications, 3 are totally new for the team

• 60% of the team has been renewed (1 internal but senior)

• The team Leader is over burned as he’s doing too many things on

his own (e.g. playing the role of IT expert which in reality he’s not)

Success criteria:• The team succeeds to deliver his roadmap without major problems

• The IT pool is nearly transparent for the Sponsor/Customers

Benefits:• The team structure supports the strategic technology shift and secure

the perimeter, defining a backup for the main IT applications

• The team Leader, delegating the technical expertise part to the IT

Tech Lead should free some time and be more focused on team

management

The Lean Project:• Help the Domain manager and the team leader to build an IT pool

• Help the team Leader to delegate

• Duration: 15 weeks

• Average workload: 1 day per week for Lean Agile coach

How?:• Do a small diagnosis of the situation

• As the project is about technology expertise, create an internal

role of IT Tech Lead

• Encourage the team leader to delegate more to focus himself on

team management i.e. organisation, control, support & make the

team more autonomous

• Define & communicate RACI on the code factory and key

development steps i.e. accountability per application, modules of

application, technology, Release building, environments, etc …

Main steps:Build the SLA and the according Skill Matrix:

• Build a skill matrix with the 7 applications, the 5 technologies

• For each application, according to the life cycle and the importance of

the application, define the ideal SLA (i.e. fully alive with project, alive

with maintenance or in phasing out with just some support)

• Translate this SLA in the minimum required staffing (number of expert,

medium or low skilled team member)

• Conduct the team member interview: try to match their wills and the

minimum required staffing mentioned above

Coached by the Team Leader, the Tech Lead defines and manages the

action plan to effectively build the IT pool:

• The pairs (assignee + backup) per application

• The Referent per technology

• The training/coaching plan to reach the Target skill level

• The team structure in the daily life (do they do pair programming?

How? What is exactly the role of the expert on each application?...)

• The global governance: which subject is discussed in the meetings

cascade (e.g. daily, weekly, specific )

the key points: the A3 format. Give all the key elements of your projects on a single A3 page so that the

Sponsor can take the right decision

Define the Skill MatrixDefine the SLA and translate it into the minimal required staffing

the Goal:

• For each application in the portfolio, define the current status: fully alive with project, alive

with maintenance, in phasing out with just support

the key points: keep in mind the coach has 2 goals: coach the Team Leader to improve his leadership and

to make his team as autonomous as possible

Application Technology Life cycle Minimal Target Staffing

Appli 1 Tibco Live Project 1 expert1 medium

Appli 2 PHP Live Project 3 experts

Appli 3 PHP Live Maintenance 2 experts1 medium

Appli 4 Talend Live Maintenance 2 experts1 medium

Appli 5 Java/Jira Live Maintenance 1 expert1 medium

Appli 6 Java Phase out Support IT Production team

Appli 7 Java Live Project 2 experts1 medium

Output:

How?:• Workshop: 1 to 2h

• Attendees:

• Team Leader

• IT senior (future IT Tech Lead)

• Lean/Agile coach

• Preparation: all this action plan has to be discussed with the team leader

• Warning & Advise:

• Work first with the current roles

• The team has to see the team leader act as the team leader

• The team should not see the coach as the new team leader


the Goal:

• For each application in the portfolio, according to the skill level & team members’ desire

build the Target staffing with the current skill level

the key points: the skill matrix is focused on autonomy and expertise

Appli1

Appli2

Appli3

Appli4

Appli5

Appli6

Appli7

TeamMember

1 expert1 medium

3 experts 2 experts1 medium

2 experts1 medium

1 expert1 medium

IT Prod.Team

2 experts1 medium

TM 1 0 3 1 1 4 4 3

TM 2 0 3 1 2 0 0 0

TM 3 0 3 2 1 0 0 0

TM 4 4 0 0 0 0 0 0

TM 5 (until August) 3 0 0 0 0 0 0

TM 6 (until June) 0 0 0 0 0 0 3

TM 7 (TBA) 0 0 0 0 0 0 0

Output:


• Attendees:

• Team Leader



Legend

4: autonomous & expert able to coach the other

3: autonomous (senior)

2: partially autonomous (medium)

1: not autonomous (junior)

0: doesn’t know


the Goal:

• For each application in the portfolio, according to the skill level & team members’ desire

assess the gap between current & target skill level

the key points: in one-to-one, the Tech Lead discuss with each team member his wills and the team

constraints

Appli1

Appli2

Appli3

Appli4

Appli5

Appli6

Appli7

TeamMember

1 expert1 medium

3 experts 2 experts1 medium

2 experts1 medium

1 expert1 medium

IT Prod.Team

2 experts1 medium

TM 1 0 3 -> 4 1 -> 3 1 -> 3 4 4 3 -> 4

TM 2 0 3 -> 4 1 -> 4 2 -> 4 0 0 0 -> 2

TM 3 0 -> 3 3 -> 4 2 -> 4 1 -> 4 0 0 0

TM 4 4 0 0 0 0 0 0

TM 5 (until August) 3 0 0 0 0 0 0

TM 6 (until June) 0 0 0 0 0 0 3

TM 7 (TBA) 0 0 0 0 0 -> 2 0 0 -> 4

Output:


• Attendees:

• Team Leader



• Attention points:

• Presented to all the team (in team meeting)

• Supported by all the team

• Follow-up done by the Tech Lead coached by the Team Leader

Internal organisation with a Tech Lead

the Goal:

• Governance to build the quality in the code

the key points: empower the Tech Lead and Senior people. Even more junior if you can. Show people they

can have perspectives in terms of professional development creates motivation

Daily Weekly Fortnightlty

Team role Daily stand-up Weekly team meeting Sprint planning

Team Leader

Technical Lead

Team Member

Output:

• Governance of the IT pool project

• Several tools to build the IT pool• Pair programming

• Best Practice sharing

• Training (theoritical & academic session)

• Standard documentation

The Tech Lead has to define when and how to use them. For instance

• Pair programming:

• During the sprint planning, select the User Stories and define the ‘pair’ to work on them

• During the daily & weekly: monitor and adjust the ‘pair programming sessions

• Best Practice sharing

• The last 15mn of the weekly team meeting might be used to present a specific Best Practice validated by the Tech

Lead

A B A

A

B

Build the quality in the code

the Goal:

• Ensure the consistency in many key topics

• Build the map of key topics and ensure they are managed by someone in the team

the key points: ask the team where is complexity, create ad-hoc roles and find in the team who could play

those roles

Key topics to cover to have a good code factory

• Release package including the setup in productionOften the end of the development process involves many stakeholders (the sponsor, the End-User, the Business Analyst, the

developer, the architecture, the production team, …) which implies complexity in terms of coordination

• Code managementIf many developers develop on the same code, a specific role of ‘Integrator’ might be useful to manage the complexity of

branches

• Module managementIf the code is structured following a specific architecture by module (e.g. 3 tiers), one manager per module (e.g. per tier) can

ensure the consistency of other developers’ contribution, validating the architecture principles defined internally

• Environment managementIf people (BA, IT, testers, …) are sharing the same environments (e.g. dev, test, etc …), internal conflicts will appear. To ensure

a good use of those shared envirnoments, you can define one manager per environment. People wanting to use this

environment should ask the agreement of ‘its manager’ to see When and How to use it

• And many others might be useful depending of the team context