1

MS TMS
FEATURE VS. COMPONENT TEAMS
 AGENDA
 EXECUTIVE SUMMARY
 HIGH LEVEL ARCHITECTURE 2

 CURRENT TEAM STRUCTURE

 HIGH LEVEL PRINCIPLES
 TEAM STRUCTURE OPTIONS
 RUNNING A TEAM SHAPING EVENT
 RESULTS

2
 EXECUTIVE SUMMARY

PROBLEM TO SOLVE
Working in large programmes or value streams presents some challenges when
it comes to continuously delivering working software. The areas where the most
of the pain is: WHAT’S WHAT
• Synchronizing the teams to make sure their deliveries are aligned. Having Component team is a team that focuses on the
an integrated Programme Increment at the end of a sprint, especially creation of one or more components of a larger
when different components are delivered by different teams requires product that a customer would purchase.
coordination.
3 Component teams create assets or components
• Integrating work and end-to-end testing is concentrated towards the end that are then reused by other teams to assemble
of the release. The true effort in this phase is almost always customer-valuable solutions.
underestimated because we have no idea how long it will take. Feature team is a cross-functional and cross-
• When not working on a single product backlog, the chances to generate component team that can pull end-
waste (by not building the most important thing for the whole programme) customer features from the product backlog and
are high. And the level of transparency that is not optimum, at the end of turn the into Increments of working software.
the sprint the teams might have completed their backlog but there might
be work to be done to have an integrated system.

These challenges can be partly solved by reorganizing the teams into

feature teams. Not as a cost-free solution, though.

3
 POINT OF SALES – SYSTEM LANDSCAPE

4
 MS TMS HIGH LEVEL ARCHITECTURE
• Technology stack
• Development: C/C++
• Testing: Robot Framework
• Team structure: 2 Scrum Teams *
(3-4Dev 3-4 Test)
• Delivery approach: Scrum
5

• Technology stack
• Development: Java,
Spring • Technology stack
• Testing: SOAPUI • Development: Java, Spring
& AngularJS
• Testing: Robot Framework
• Team structure: 2 Scrum Teams *
(4Dev 3 Test)
• Delivery approach: Scrum

5
 CUSTOMER CENTRIC FEATURES & SPREAD ACROSS
COMPONENTS

When implementing a customer centric feature,

how coupled are the components of the system?

• Do we need to write code in all layers?

• How much code do we need to write is any of

the components?
6
• Do we see any patterns? E.g: 40% of the
features touch OnePA and Parameters
Management, 20% touch MS UI and
Merchants Management, etc.

• What is the most affected component? What

is the most stable?

Tight vs. Loose

Coupling

6
 CURRENT TEAM STRUCTURE
TMS OnePA*
- Chief Product Owner
- Product Owner
- Product Owner
Product Owner

- Architect Dev Lead Architect - Lead Architect

- Data Architect Scrum

7 Scrum -
Scrum Master
Same /Senior Dev
Scrum Master Master person? Master
- /QA Lead - -
2 * Senior Dev. 3 * Senior Dev.
3 * Senior Dev.
Senior UI Dev. -

UI Dev. 2 * Dev. - Test Lead

Test Lead
- Senior Tester 3 * Sen. Man.
1 * Sen. Aut. - -
Senior Tester Tester Tester
Senior Dev. -
Tester Tester 2 * Manual Tester 1 * Sen. Aut. Tester

7
*Endava ramp-up in progress
 HIGH LEVEL PRINCIPLES (1)
WHY WE NEED THIS?
Creating feature teams is not a goal itself. But it is a critical tool to deliver potentially shippable increments at the end of the sprints (for scaled
agile projects, this translates into integration being done!). This ensures transparency on the undone work and the unknowns that integration
work bring.

ORGANIZING DEVELOPMENT TEAM

How teams are organized will have to correlate to the number and type of dependencies. Along this process we need to consider the range of
technologies used, people already in the account, different components & ownership/ external dependencies.
8
CRITICAL MASS
Create teams as big as needed and as small as possible. Even though we aim for a cross functional team, of a proper size, that can turn a
product backlog item into increments of working software, we need to make sure that we have a critical mass for all the technologies in use in a
team such as unpredictable leaves do not block the whole system.

ORGANISE FOR LARGER PURPOSE

Maximise the velocity by minimising dependencies and hands-off between the teams, while sustaining architectural robustness and system
quality.

WORKLOAD
Team structure will have to reflect the way the effort for implementing a feature is distributed across the components/ technologies. Is not going
to be always the same, for every single feature, but historical data can give a good indication about the ratio needed. Sometimes it can be that
the load during a sprint is not evenly distributed, but the aim is to use that opportunity for technical improvements.

8
 HIGH LEVEL PRINCIPLES (2)
HOW IS THE QUALITY ENSURED?
One of the challenges with featured teams is to ensure that components are still at a high quality standard – consistent architecture and design, no
duplicated code, optimum solutions and consolidated technical knowledge. This is where the Technical Leadership Scrum (TLS) comes into play, focusing on
technical solution alignment, quality and technical excellence.

CONTINUOUS INTEGRATION
For the teams to be able to integrate their work as early as possible, it is needed to have a strong CI setup. Manual effort required for integrating different
components should be reduced to zero for the teams to be efficient, so before applying any changes we need to understand what is already in place, what is
still to be done and who will pick it up by when. 9
LOOK AT COMPONENT COUPLING
Depending on the size of the technology stack and the number of components involved, it might not be possible to create fully cross-functional teams. In
such environments, alternative options would be to check how coupled are the components involved and what are the most frequently updates when
implementing a customer centric feature. If not possible to cover end to end, then what are the pieces that make sense to go together for an increased
collaboration?

9
 TEAM STRUCTURE – OPTION 1
Advantages
TLS (Virtual) Blue Aqua Yellow
Truly cross functional teams
Architect (Java) C++ 3 C++ 2 C++ 2
Lead Architect (C++) Java 3 Java 3 Java 2
Data Architect Testing 5 Testing 5 Testing 4
QA Lead

10
Disadvantages
Size more than recommended in
Scrum

10
 TEAM STRUCTURE – OPTION 2

TLS (Virtual) Blue Aqua Yellow Purple

Architect (Java) C++ 2 C++ 2 C++ 2 C++ 1
Lead Architect (C++) Java 2 Java 2 Java 2 Java 2
Data Architect Testing 4 Testing 4 Testing 3 Testing 3
QA Lead

11

Advantages Disadvantages
Small sized teams Critical mass principle broken

11
 THE EVENT

• Leads invited to
the session
• Select the preferred Run iterations on
option. allocating skills
• Read and Options review • Each lead allocates • Review final
• If the change would totoaeach
teamof the team
discussed the 12
be disruptive, think results - with the
context, the need an equal number of entire team -
of options to split
and the principles • Review the team skills he/ she was from a Principles
into smaller steps.
• Facilitators – AT structures previously and feasibility
• Think of responsible for
champions proposed point of view
prerequisites for the (Java, C, Testing)
Context & • Discussed merits selected option to
Cross-check
principles for each one and work in practice
• Run the process principles with
the complexity it several times, until result
brings
Option selection team compositions
are ok

12
 THE RESULT

13

13
 CONCLUSIONS

14

14
 THANK YOU!
15