5 developers for 7 applications & 5 technologies: how can we manage it?

1. Case
Build 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)

2. Project Charter
Build 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

3. Define the Skill Matrix
Define 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 expert
1 medium
Appli 2 PHP Live Project 3 experts
Appli 3 PHP Live Maintenance 2 experts
1 medium
Appli 4 Talend Live Maintenance 2 experts
1 medium
Appli 5 Java/Jira Live Maintenance 1 expert
1 medium
Appli 6 Java Phase out Support IT Production team
Appli 7 Java Live Project 2 experts
1 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

4. Define the Skill Matrix
Define the SLA and translate it into the minimal required staffing
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
Appli
1
Appli
2
Appli
3
Appli
4
Appli
5
Appli
6
Appli
7
Team
Member
1 expert
1 medium
3 experts 2 experts
1 medium
2 experts
1 medium
1 expert
1 medium
IT Prod.
Team
2 experts
1 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:
How?:
• Workshop: 1 to 2h
• Attendees:
• Team Leader
• IT senior (future IT Tech Lead)
• Lean/Agile coach
Legend
4: autonomous & expert able to coach the other
3: autonomous (senior)
2: partially autonomous (medium)
1: not autonomous (junior)
0: doesn’t know

5. Define the Skill Matrix
Define the SLA and translate it into the minimal required staffing
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
Appli
1
Appli
2
Appli
3
Appli
4
Appli
5
Appli
6
Appli
7
Team
Member
1 expert
1 medium
3 experts 2 experts
1 medium
2 experts
1 medium
1 expert
1 medium
IT Prod.
Team
2 experts
1 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:
How?:
• Workshop: 1 to 2h
• Attendees:
• Team Leader
• IT senior (future IT Tech Lead)
• Lean/Agile coach
• 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

6. 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

7. 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 production
Often 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 management
If many developers develop on the same code, a specific role of ‘Integrator’ might be useful to manage the complexity of
branches
• Module management
If 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 management
If 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