8/18/2019 Lucru Munca in Echipa
1/82
8/18/2019 Lucru Munca in Echipa
2/82
1
Abstract
This thesis adapts an existing Teamwork Model, that uses self-improvement, to fit the
Department of Applications at Ericsson Mobile Communications AB in Lund. The Teamwork
Model uses an add-on for handling metrics, to improve the analysis of the team process. The
adapted process is evaluated through a case study. The evaluation puts an emphasis on how
metric collection is handled, the usability of Proxy Based Estimations in teams, the cost of
process steps, and how the users perceive the Teamwork Model. Based on the evaluation the
Teamwork Model is improved. The model is also changed to fit new circumstances at the
Department of Applications, such as the use of the Critical Chain and Buffer Managementmethod.
8/18/2019 Lucru Munca in Echipa
3/82
2
Acknowledgement
This work was carried out at the Department of Applications at Ericsson Mobile
Communications AB in Lund. I want to thank Christer Sandahl and all those at Ericsson that
made this work a possible, an interesting, and an instructive journey. I would like to thank
Professor Claes Wohlin, at the Department of Communication System, for both reviewing this
report and guiding me through the process of creating it. I would also like to thank Dr. Per
Runeson for reviewing this report. In addition, I would like to thank Bengt Nilsson at
Janzon & Nilsson Management for supporting me and proofreading the part about CriticalChain and Buffer Management. I would especially like to thank Mikael Andersson, Henric
Blomqvist, Henrik Borg, Fredrik Hederstierna, Thomas Hermansson, Anders Karlsson,
Joakim Mårtensson, and Emil Särnstrand for the excellent work you performed when takingpart in the case study, giving me the opportunity to study the Teamwork Process, and forreviewing parts of this thesis.
8/18/2019 Lucru Munca in Echipa
4/82
3
Table of Contents
ABSTRACT............................................................................................................................................ 1
ACKNOWLEDGEMENT..................................................................................................................... 2
TABLE OF CONTENTS....................................................................................................................... 3
1 INTRODUCTION......................................................................................................................... 5
2 OBJECTIVES................................................................................................................................ 6
2.1 OUTLINE ...................................................................................................................................... 7
3 THE PERSONAL SOFTWARE PROCESS............................................................................... 8
3.1 PSP, THE COURSE ........................................................................................................................ 9
3.2 PSP, IN GENERAL ....................................................................................................................... 12
3.3 PROBE - PROXY BASED ESTIMATING METHOD ........................................................................ 13
4 THE TEAMWORK MODEL..................................................................................................... 15
4.1 TEAMWORK ............................................................................................................................... 154.2 THE THREE PLAYERS .................................................................................................................. 16
4.3 THE TEAM.................................................................................................................................. 16
4.4 THE TEAM ASSIGNMENT LIFE CYCLE ........................................................................................ 18
4.5 TEAM MEMBER TOOLS ............................................................................................................... 21
4.6 MANAGEMENT TOOLS ................................................................................................................ 22
5 TEAM METRIC MODEL.......................................................................................................... 23
5.1 MEASUREMENT PLANNING ........................................................................................................ 24
5.2 MEASUREMENT EXECUTION ...................................................................................................... 27
5.3 INTRODUCING PROBE IN TEAMS .............................................................................................. 28
6 ERICSSON MOBILE COMMUNICATIONS AB................................................................... 30
6.1 ORGANIZATION.......................................................................................................................... 30
6.2 PROCESSES................................................................................................................................. 31
6.3 SOFTWARE GOALS FOR ERICSSON MOBILE COMMUNICATIONS AB........................................... 32
7 THE TEAMWORK MODEL FOR ERICSSON MOBILE COMMUNICATIONS AB ...... 33
7.1 DOCUMENTS .............................................................................................................................. 33
7.2 ORGANIZATION.......................................................................................................................... 36
7.3 MEETINGS.................................................................................................................................. 38
7.4 THE PROCESS............................................................................................................................. 40
8 OBJECTIVES OF EVALUATION ........................................................................................... 43
9 METHOD OF EVALUATION .................................................................................................. 44
9.1 ADDITIONAL REQUIREMENTS TO THE TEAMWORK MODEL........................................................ 45
9.2 THE CASE .................................................................................................................................. 46
9.3 DATA COLLECTION.................................................................................................................... 48
9.4 VALIDITY................................................................................................................................... 49
9.5 EXPECTED RESULT .................................................................................................................... 50
8/18/2019 Lucru Munca in Echipa
5/82
4
10 EVALUATION............................................................................................................................ 51
10.1 INFORMATION-FLOW-CHANNELS ........................................................................................... 52
10.2 PRODUCT DOCUMENTATION.................................................................................................. 54
10.3 METRIC COLLECTION............................................................................................................. 54
10.4 ESTIMATES AND THE PROBE................................................................................................ 58
10.5 COST ..................................................................................................................................... 61
10.6 THE PROCESS IN GENERAL ..................................................................................................... 63
11 SUGGESTIONS FOR IMPROVEMENT................................................................................. 65
11.1 INTRODUCTION OF THE TEAMWORK MODEL ......................................................................... 65
11.2 CHANGES AT THE DEPARTMENT OF APPLICATIONS AT ECS.................................................. 65
11.3 ELIMINATION OF SHORTCOMINGS.......................................................................................... 65
11.4 THE NEW AND IMPROVED TEAMWORK MODEL..................................................................... 67
11.5 SUGGESTION FOR FURTHER STUDIES.....................................................................................69
12 REFERENCES ............................................................................................................................ 70
APPENDIX A ....................................................................................................................................... 71
CRITICAL CHAIN SCHEDULING AND BUFFER MANAGEMENT.............................................................. 71
APPENDIX B ....................................................................................................................................... 81
ABBREVIATIONS AND ACRONYMS ...................................................................................................... 81
8/18/2019 Lucru Munca in Echipa
6/82
5
1 Introduction
The organizational structure at Ericsson Mobile Communications AB in Lund (ECS), consists
of three main layers. They are, ordered in decreasing order, departments, sub-departments,
and personnel. To render the ongoing work more effective, and to ease the communication
between the different departments and sub-departments, a work cycle, i.e. a process, is used.
This work cycle, or process, is meant to aid the different departments and sub-departments in
terms of what documents they should produce, setting up project deadlines, identifying what
department and sub-department dependencies exist, etc. However, the process used affectsalmost only the two top layers in the organization. The Department of Applications at ECS
expressed an urge to investigate how a teamwork process model, affecting the bottom layer of
the organization, could be used. The department also wanted the new process to continuously
improve itself, as the people using it would make new discoveries regarding the development
cycle. Hence, a self-improving teamwork process model had to be investigated.
In 1995 Watts S. Humphrey came out with his book “A discipline for software engineering”.In it, he suggests a method for refining a person’s personal software process (PSP), i.e. how aperson can improve his own work cycle.
In January 1999 Sebastian Courel wrote his thesis “Introducing PSP ideas on the team level inTeamwork-based organizations”. In the thesis, he expanded a teamwork process model,developed by L M Ericsson AB and Q-Labs, with ideas from Humphrey’s PSP. He did this by
creating an add-on to the existing Teamwork Model. He called the add-on, the Team MetricModel (TMM). Doing this, Courel had in much, developed a process desired by theDepartment of Applications at ECS.
This thesis investigates how the Teamwork Model with the TMM add-on created by Courel,can be changed to fit, the organizational structure, the company meeting culture, anddocumentation standard at ECS. This thesis also investigates how the developed Teamwork
Model works in practice, and gives suggestions to how the model can be improved.
8/18/2019 Lucru Munca in Echipa
7/82
6
2 Objectives
The objective of this thesis is to develop a self-improving teamwork process model to fit the
Department of Applications at ECS, regarding organizational structure, meeting culture,
documentation standard, and short project lead-times. This thesis should also evaluate the
model developed, through a number of evaluation projects. Based on the evaluation,
suggestions to how the model can be improved, should be given.
8/18/2019 Lucru Munca in Echipa
8/82
7
2.1 Outline
To meet the objectives, this thesis provides a background for creating a new Teamwork
Model. The background consists of four chapters:
• Chapter 3 describes the Personal Software Process (PSP). The PSP brings down, largescale software development methods, to a personal level. The PSP idea, is to help the
software developer improve his/her software development process [Humphrey95].
• Chapter 4 explains the Teamwork Model created by L M Ericsson AB and Q-Labs. Themodel describes how the different players in an organization relate to each other. It alsoidentifies what and when documents should be produced. The chapter, furthermore,
provides a description of the workflow, or the life cycle, of the model [Courel].
• Chapter 5 describes the Team Metric Model (TMM). The TMM brings up the PSP ideasto a team level. The TMM functions as an add-on to the Teamwork Model [Courel].
• Chapter 6 provides a description of the situation at ECS, as it was when this thesis wasinitiated. The description concerns the organization, the meeting culture, and the
processes used at ECS and the Department of Applications at ECS.
This thesis creates an adapted Teamwork Model based on the former described Teamwork
Model, with the TMM add-on. The new and adapted model, also had to be evaluated and, if
necessary, improved. This thesis provides a description of this work in the following five
chapters:
• Chapter 7 describes how the Teamwork Model, with the TMM add-on, was adapted to fitthe ECS situation. A new version of the Teamwork Model, with the TMM add-on, was
created.
• Chapter 8 describes the objectives of the evaluation, i.e. what will be studied in comingchapters.
• Chapter 9 presents a method of evaluation for the developed Teamwork Model. Themethod includes a description of the evaluation projects that were run at ECS; i.e. a
description of in what way the evaluation projects differed from the general Teamwork
Model, general project description, and how the teams were composed. It also includes adescription of what will be handled in the evaluation and expected values.
• Chapter 10 provides a description of the evaluation of the developed Teamwork Model.The evaluation is based on collected data from the evaluation projects and the opinion of
involved parties of the project model.
• Chapter 11 introduces suggestions of improvements to the developed Teamwork Model.The suggestions are based on the evaluation and on late process- and organization-
changes at the Department of Applications.
All abbreviations and acronyms used in this thesis are listed in Appendix B.
8/18/2019 Lucru Munca in Echipa
9/82
8
3 The Personal Software Process
Watts S. Humphrey defined in his book “A Discipline for Software Engineering”[Humphrey95] a strategy for improving the personal software process (PSP). Humphreyillustrates this strategy by forming a course, that software programmers can take. He suggeststhat a number of steps are taken to reach a more mature personal development process.Humphrey identifies four major PSP steps, i.e. improvements of the personal process. Thesesteps and their differences are described in chapter 3.1. Although [Humphrey95] can be read
as a course to take, or as a book describing the PSP in general, some important features aboutPSP can be identified. The general features of the PSP are described in chapter 3.2.
In PSP1, Personal Software Process 1, the Proxy Based Estimation method (PROBE) isintroduced to help estimate the code size and the development time. Since the PROBE is aself-improving estimation method, it was chosen to be used in the evaluation projectsdescribed in chapter 9, to see if data collected from one team could be used by other teams.
The PROBE is described in chapter 3.3.
8/18/2019 Lucru Munca in Echipa
10/82
9
3.1 PSP, the course
In the course, Humphrey develops a strategy for improving the Personal Software Process.
The strategy contains three steps. They are:
• Identify large-system software methods that can be used by individuals in their process.
• Define a subset of these methods, so that they can be used when developing smallprograms.
• Structure the methods, so that they can be introduced into the process gradually.
Four major PSP steps are developed, shown below, each with a more mature structure than its
predecessor. A new improved process is formed based on what has been learned. The
different processes can be described as follows.
The PSP Evolution- [Humphrey]
8/18/2019 Lucru Munca in Echipa
11/82
10
The Baseline Process; PSP0 and PSP0.1
A person’s basic process is called “The Baseline Process” (PSP0). It contains whateverprocess the individual is using at the moment, plus some measurement and reporting forms.The intention of PSP0 is to form a foundation to be able to compare and analyze the ongoingprocess improvement work. Some minor enhancements are made to the existing personalprocess, so that measurements can be made. Every PSP starts of with a planning-phase andends with a postmortem-phase. Thus, the process has a natural beginning and end and is
therefore suitable for analyzing. Additional phases that the PSP0 should contain are a design-,code-, compile-, and test-phase. In PSP0, Humphrey also introduces a structured way of handling process problems and process improvement suggestions.
By enhancing PSP0 with a coding standard and size measurement, PSP0.1 is formed.
A measurement system
How do you create a good measurement system? A measurement system should be such thatit can generate a number of values such as development time and the size of the developedproduct. For our purposes, Humphrey chooses to base estimates on the number of logical linesof code. The meaning of logical lines of code is defined below in “A coding standard”. The
estimates thought of, are estimates for development time and lines of code in a program.Humphrey suggests that there is a connection between the size of a program and the time ittakes to develop it. Based on this, the measurement system he suggests is based on anestimate of the number of logical lines of code. From it, it is possible to derive estimates forthe code size and the code development time of the future program.
A coding standard
To achieve a successful measurement system that measures logical lines of code, a goodcoding standard is really the key. When defining a coding standard the expression Lines Of Code (LOC) is used. A LOC can be either a physical line of code or a logical line of code.
With a logical line of code, the meaning of a logical operation is intended. In the courseHumphrey suggests that the coding standard be such that the number of logical LOC’s equalsthe number of physical LOC’s. If this is the case, it is easy to calculate the number of LOC’sby simply calculating the number of lines in a program, excluding the blank lines.
The Personal Planning Process; PSP1 and PSP1.1
In addition to PSP0, planning steps are added, i.e. the planning-phase becomes morestructured. The planning steps that are added are, test planning, size and resource estimation,and task and schedule planning.
In planning the development of the software, Humphrey suggests that the programmer shouldstart with making an analysis of the software specification. The plan should contain a partwhere the understanding of the specification is written. This is done to demonstrate that theprogrammer has a full comprehension of the problem that lies ahead of him/her. It alsoensures the customer that the programmer has fully grasped what is intended by thespecification.
If the development will take more than a few days, the programmer should break up the
project into smaller parts. By breaking up the initial project into smaller parts, he/she
8/18/2019 Lucru Munca in Echipa
12/82
11
increases the level of details shown in the plan. The programmer should estimate the smaller
parts separately from each other.
When making estimates for a plan, the programmer should base his/her estimates on data of
prior work.
To be able to build up an estimate-database he/she should record his/her estimates for future
use.
For more complicated software development, the use of planning tools might be interesting.
A good plan should give the programmer four general things. They are:
• Job size. How big is the job and how long will it take to perform it?
• Job structure. How is he/she going to perform the job and what is the order of thedifferent parts that need to be carried out?
• Job status. How can he/she tell what status he/she has on the job? Can the programmerdemonstrate that he/she will finish on time by showing parts of the program for the
customer?
• Assessment. How good was the plan? How can he/she improve his/her job the next time?
Coworkers, end-users, and managers probably also want four general things from your plan.
They are:
• What is the commitment? Specifically, what will be delivered and to what cost?
• Does the product have the right quality? Is it possible for them to make interim checks onthe product?
• Is it possible to view the project’s progress? Will early warnings be given if the cost, thequality, or the scheduled delivery time changes?
• Will it be possible for them to later evaluate how well your job was carried out?
To improve and evolve your planing skills towards a quality plan, you can ask your plan sixquestions that should be answered in an affirmative manner. The questions are:
1. Is it complete?
Check if the plan meets the requirements.
2. Is it accessible?
The plan should be in a place and in a format that is accessible.
3. Is it clear?
The plan should be written in a clear manner, i.e. it should follow a specified clearstructure.
4. Is it specific?
Does the plan contain information of what will be done, when, by whom, and at whatcost?
5. Is it precise?
Are the correct units for the estimates used? Does the plan tell what it should?
6. Is it accurate?
Are the estimates accurate?
8/18/2019 Lucru Munca in Echipa
13/82
12
Personal Quality Management Process; PSP2 and PSP2.1
In PSP2, Humphrey acknowledges that defects found late in code development are more
costly than those found early. The cost of a defect is measured as the time it takes to fix the
defect. To be able to find defects early on in development, reviewing techniques are
introduced. To be able to review the code efficiently, you need to know what kind of defects
are introduced into the code, in what phase they are introduced, and how many defects are
expected to be found in each phase. Knowing this, you can construct checklists to use when
performing the reviews.
PSP2.1 handles the design phase. By introducing different verification and consistencytechniques, you can know when to end the design process, knowing that you have a correct
design.
A Cyclic Personal Process; PSP3
At this point, the PSP used in the
course has been aimed at a simple
linear process for developing small
programs. With PSP3, Humphrey
makes the process scale to larger jobs
as well. In PSP3 the use of incrementsis started.
In the linear process model, the
different phases came after each other
and could not be mixed. The linear
process started off with an analysis
phase followed by a design phase,
design review, code phase, code review, compile phase, test phase and a postmortem phase.
The postmortem phase included form completion and analysis of the project.
In an incremental or cyclic process the project is divided into smaller parts, increments, that
can be completed each with a linear process model.
3.2 PSP, in general
The evolution of the PSP can be viewed as an evolution cycle, continuously improving the
PSP. Every PSP starts of with a planning-phase and ends with a postmortem-phase. The
beginning and end of the project are therefore well defined.
In large-system software methods, plans are used to calculate the cost and the time span of a
given project. Humphrey adopts this idea and brings it down to a personal level. For that
reason, the individual programmer is advised to make an analysis and a conceptual design.
The conceptual design is used to create reliable time estimates. These estimates are used to
create a schedule for the coming work. To make quality estimates, the PROBE method,
described in chapter 3.3, is used. In the planning-phase the programmer also decides what to
study and thus what metrics to collect throughout the process. The programmer should have
an outspoken goal with what he/she wants to achieve with his/her metric collection.
In the postmortem-phase he/she makes an analysis based on the collected metrics. Depending
on the findings in this analysis, the programmer can change and improve the initial process.
After the change, the new process is tested an analyzed in the same manner as the first process
was. The process of evaluating and improving the PSP, never ends.
A n a l a s y s
D e s i g n
C o d e
P o s t m o r t e m
C o m p i l e
C o
d e R e v i e w
T e s t
D e s i g n R e v i e w
8/18/2019 Lucru Munca in Echipa
14/82
13
3.3 PROBE - Proxy Based Estimating method
Humphrey suggests the use of an estimation method to produce reliable estimates for the
development plan. A good method should make use of earlier collected data from prior
projects, and constantly refine its estimates. One such method is the PROBE method. It is a
proxy based estimation method.
What is a proxy? A proxy could be thought of as a module library. Consider housebuilding
for instance. It can be hard to picture a house based on the number of square meters it has, e.g.
a flat holds 51 square meters. If the description instead is created from the different rooms the
flat has, it might give you a better picture, e.g. a flat consists of a small kitchen, a large livingroom, a medium hallway, and a medium bedroom. In the latter example, the proxy used is
room.
In software engineering a proxy could be functions, when a function-oriented programming
language is used, or classes and methods, when an object oriented-programming language is
used. The proxy should form a description of the system developed. For example, when you
have made your conceptual design, it should consist of the proxy of choice. The proxy should
consist of as much information as possible without being too specific to use. It is important
that the proxy can be measured by the measurement system. In our case, it would be number
of LOC’s.
When using function as proxy, you should consider refining the proxy to consist of functions
with a relative size. A function could for example be Very Small (VS), Small (S), Medium(M), Large (L), or Very Large (VL). If possible, the use of different function categories couldbe used. Different function categories that might form naturally, when a function oriented
programming language is used, are Control-, Display-, File-, Logic-, Print-, and Text-functions. This forms a proxy matrix:
Category Very Small Small Medium Large Very Large
Control 4.24 8.68 17.79 36.46 74.71
Display 4.72 6.35 8.55 11.50 15.46
File 3.30 6.23 11.74 22.14 41.74
Logic 6.41 12.42 24.06 46.60 90.27
Print 3.38 5.86 10.15 17.59 30.49
Text 4.63 8.73 16.48 31.09 58.62
LOC per Function - [Humphrey95]
8/18/2019 Lucru Munca in Echipa
15/82
14
To calculate the different relative sizes, Humphrey uses a logarithmic scale, that is based on
old data. The reason for using a logarithmic scale is that it has proven to give better estimates
than if a linear scale is used. Function sizes are not normally distributed and thus better
explained by the logarithmic calculations. A good feature with a logarithmic scale is that you
never get negative relative sizes. The formulas for calculating the relative sizes are:
The LOCi is the number of LOC in function i.
After calculating the relative sizes, based on old data, and after the conceptual design is
created, it is time to make use of the PROBE method. The conceptual design consists of the
functions, and their relative sizes, that the new program should consist of. The conceptual
design also contains information on what type of functions they are. Based on the calculated
relative sizes found in the relative size matrix, an initial estimate, of the number of LOC each
new function will have, can be found. When these sizes are added, a first estimate of the size
of the future program is created. To refine this estimate the PROBE uses linear regression.
The idea is that the calculated estimate for a program, correlates with the actual sizes for a
program, on a linear basis. The PROBE method refines the initial estimate using the following
formula:
The parameters, β0 and β1, are calculated based on old data.
To calculate the new, refined estimate, you will first have to calculate the parameters β0 andβ1. The old data is ordered with x i and yi meaning the initial estimate x, for program i, and theactual size y, for program i. Then calculate the new estimate using formula (ii).
By using linear regression and constantly refining the parameters, the estimates will get betterand better. In its finest form, it is possible to calculate prediction intervals for the new
estimates.
( )
( )
( )
( )
( ) σ
σ
σ
σ
⋅−=
−==
+=
⋅+=
2ln
ln
ln
ln
2ln
mVS
mS
m M
m L
mVL( )
( )( )∑
∑
=
=
−=
=
n
ii
n
i
i
m LOC n
LOC n
m
1
2
1
ln
1
ln1
σ
( )
avgavg
n
i
avgi
n
i
avgavgii
x y
xn x
ynx y x
10
1
22
11
β β
β
−=
−
−=
∑
∑
=
=
10 β β k k x y +=
(i)
(ii)
(iii)
8/18/2019 Lucru Munca in Echipa
16/82
15
4 The Teamwork Model
This chapter describes the Teamwork Model, created by L M Ericsson [Jansson] and Q-Labs
[Martín-Vivaldi], based on its presentation in [Courel].
What is teamwork? Although many companies claim to use a teamwork process model, theydo not. A definition of teamwork is presented in chapter 4.1.
In an organization, different players can be identified, e.g. management, developers,
maintenance personnel, etc. A process that is used in an organization, has to define thedifferent roles that the different players in the process model plays. A description containingdefinitions of the different players that act within the Teamwork Model is provided inchapter 4.2.
The most important player in the Teamwork model is the actual team. Chapter 4.3 presents adefinition on what a team is, in the teamwork model.
The teamwork model can be viewed as a lifecycle called the Team Assignment Life Cycle(TALC). The TALC illustrates the different phases and deliverables that the teamwork modelconsists of. A summary of the TALC can be found in chapter 4.4.
When working within a teamwork model, different tools to control the information flow,
between the different players and within the team, can be used. They are tools like “WeeklySchedule”, “1/3 Presentation”, etc. Some tools that can be used are described in chapter 4.5.
4.1 Teamwork
Teamwork is not something that happens by itself. Many companies that claim to useteamwork do not. Instead of having the individual team-members work closely together witha joint responsibility of all parts included in the development cycle, they have the team-members work as individuals with their own responsibilities. The result of this misuse of theteamwork model is missed deadlines, low quality, slow process learning and low motivation[Martín-Vivaldi].
Teamwork is not only a process to use, but also a work-organization for the lowest level of the company structure. It is a process in the regard that it defines in what order tasks are to becarried out. It is an organization model because it defines the relations and responsibilitiesbetween the coworkers.
The Teamwork process could be viewed as a framework process for the team’s own process,i.e. the team’s own process, defines phases within the Teamwork phases. The Teamwork
Process also helps improve the team’s own process.
8/18/2019 Lucru Munca in Echipa
17/82
16
4.2 The three players
In the teamwork model, there are
three main players defined. They all
have different roles to play in the
organization, and the Teamwork
model stipulates their relations. The
players are:
• the Assignment Orderer (AO)
• the Resource Responsible (RR)
• the Assignment Performer (AP)
The responsibilities and relations
between the three players are as
follows:
The AO has a job that needs to be
carried out. It is the AO’sresponsibility to divide the initial job into smaller assignments, fittinga team’s workload. The AO thencontacts the next player, the RR, to
initiate a team with its new task.
The RR is the one that handles the team resources. Resources can be anything from personnelto computers. The RR allocates individuals to form a team. The RR’s major concern is tocreate a well functioning team. The RR has to form the team based on the competence, theexperience and the availability of the individual team members. If some team members needtraining, it is the RR’s responsibility that the team members will receive the necessary
education. It is within the RR’s interest to ensure the performance of the team. To keep track of the team’s progress the RR will constantly do check-ups on the team’s performance.
The third player, the AP, is the team. The AP consists of the RR’s resources and does theAO’s assignment. Throughout the project lifecycle, the AP has contact with both the AO andthe RR. All members forming the AP have joint responsibility for the assignment progress.
4.3 The Team
A team in software development is defined as follows [Courel]:
“ A team is a group of preferably 3-5 people that work together interdependentlyas a whole over a period of time to achieve a common goal, where the team
members are jointly responsible for the result, and strives to maximize
performance through innovative methods.”
The size of a team has been decided, after considering studies showing that humans caninteract with a maximum of eight people effectively. Since software engineering is regardedcomplex by nature, the number of people in a team should be no more than five, and no lessthan three [Courel].
A team should have a clear common goal to strive towards. To achieve this, the team shouldbe given a clear assignment.
[Courel]
AssignmentPerformer
Three Main Players
Assignment
Orderer
Resource
Responsible
8/18/2019 Lucru Munca in Echipa
18/82
17
It is also important that all members of the team are considered as one. They have equal
responsibility for all parts of the development process. The team members should take full
responsibility for each other’s work.
In this thesis, The Assignment Performer can from now on be referred to as the team.
Team member
Although the different team members share responsibility they can play different roles within
the team, i.e. different team members can have different expertise. A team member shouldwork on only one team at a time. The objective is to keep full commitment to the team.
Team Leader
One team member, should have the extra responsibility as Team Leader. The Team Leader’s job is to ensure decision making within the team. He is also the one who keeps contact withparties outside the team. One member should never keep the Team Leader role all the time,instead different members should have this role in different projects. The Team Leader is not,more responsible for the team’s work, than the other team members. The Team Leader role isnot the one of an authority, rather the one of an organizer.
External resource
Team participants, that do not spend their entire time within the team project, but areoccasionally added to the team, to increase competence in certain areas at certain times, arecalled external resources.
8/18/2019 Lucru Munca in Echipa
19/82
18
4.4 The Team Assignment Life Cycle
The Team Assignment Life Cycle (TALC), describes the Teamwork Process. A graphical
overview is shown below. The different sections, or phases, of the life cycle are described in
detail and in order of appearance below.
Pre initiation phase
Duration: 2-3 month
Result: Team Assignment Specification
In this phase, the RR and the AO work tightly together. The AO breaks down the work into
pieces fitting a 3- to 5-man-team. Together they decide what competence is needed. The RR
allocates team members based on their competence, availability, experience and social skill.
After intense negotiation concerning team member training and assignment deadlines, theydeliver the Team Assignment Specification. The Team Assignment Specification then work as
a framework for the team’s work. It contains administrative information, date and timeestimates, and quality goals.
Pre
InitiationPhase
Initiation
Phase
Execution
Phase
ConclusionPhase
TeamAssign-mentSpec
DetailedTeam
Plan
Deliveryof
Results
Go
Go Go
End
ProgressReport
Activity
Kick-Off
Negotiation
Re-
Negotiation
Activity
Analysis
FinalReport
[Courel]
8/18/2019 Lucru Munca in Echipa
20/82
19
Initiation phase
Duration: 1-2 weeks
Result: Detailed Team Plan
The phase usually starts with an Activity Kick-Off. The team meets for the first time and is
informed of its coming project, i.e. they are given the Team Assignment Specification. If theteam is newly formed, it is important to arrange some sort of team building activity. The
Activity Kick-Off should last one day.
The main goal of the Initiation Phase is to make all team members committed to the task they
are about to commence working on. To achieve this, the team makes a plan for how they will
solve their work throughout the assignment. It is important that all team members become
committed to the plan. When the team members study the Team Assignment Specification
they should:
• clarify all ambiguities,
• plan how to reach the requirements,
• divide the work amongst themselves,• determine who will function as the team leader,
• agree on meeting routines,
• define common goals for the team,
• document all the above steps in the Detailed Team Plan and
• commence the assignment work, while starting the negotiation of the Detailed TeamPlan.
The Detailed Team Plan should contain a complete plan for how the team will meet the
requirements specified in the Team Assignment Specification. The plan should includeschedules, different process steps, and information about who is responsible for what. If the
team discovers certain needs, the team should add these needs to the Detailed Team Plan as
well.
At the end of this phase, should negotiations of the Detailed Team Plan between the three
players, i.e. the RR, the AO and the team, be held. This ensures that the team will do the right
work at the right time. Four key-factors need to be agreed upon. They are Duration,
Resources, Functionality and Quality. When the negotiation has ended, all three players
should have reached an agreement on what is expected of the team. The Detailed Team Plan
is then frozen and considered a contract between the three players.
At the end of this phase all team members should be committed to the assignment, and the
agreed upon Detailed Team Plan.
8/18/2019 Lucru Munca in Echipa
21/82
20
Execution phase
Duration: 6-16 weeks
Result: Progress reports and Delivery of results
Throughout this phase, the team carries out the work agreed upon in the Detailed Team Plan.
It is a team responsibility to keep track of the work progress. The team should report anydeviation from the initial plan to management, i.e. the RR and the AO, so that appropriate
measures can be taken. It is important that management gives the team the privilege of
independent work without any interference. To keep the RR and the AO informed of team
status, the team should give Progress Reports regularly. If a deviation from the Detailed Team
Plan occurs, a Re-negotiation of the Detailed Team Plan can be initiated.
The Progress Report should inform the management of how the team’s work is progressing.The report should be written brief and state whether the team is on schedule or not. The
Progress Report should also include already achieved results and problems that haveoccurred.
There should be a Re-negotiation only if, major changes occur, that can jeopardize the
commitment of the team members to the Detailed Team Plan. If a Re-negotiation is necessary,it is of great importance that management does not reduce the power of the team.
At the end of this phase, the team delivers its results. The results should be the ones stated inthe Detailed Team Plan.
Conclusion phase
Duration: 0.5-1 day
Result: Final Report
This phase is the final phase of the whole process. It is in this phase that improvement to theprocess used by the team can take place. In the Final Report the team should state:
• What its members have learned throughout the process
• What can be done to improve the process, to better meet the team’s commitments
• What went well
• General suggestions for process and teamwork improvement
The Final Report consists of positive and negative experiences to help improve the process. It
functions as a feedback to the process model. It can also act as a learning base for futureteams.
8/18/2019 Lucru Munca in Echipa
22/82
21
4.5 Team member tools
Numerous tools are available for a team to manage its work. What tools the team uses should
be decided at team level. Here follows some suggested tools.
Weekly Schedule
The weekly schedule extracts and refines small parts of the Detailed Team Plan. This makesthe team’s coming work visible to its members. It also gives the team a feeling of work progression. The tool also helps to foresee deviations from the Detailed Team Plan so thatappropriate measures can be taken at an early stage.
Action List
Action Lists are used to open issues and log action points during meetings and reviews. The
list contains “ID” to identify and track identification and solution of problems. The reason forkeeping action lists, is to help the team keep track of upcoming problems and keep deadlines.
Status Meeting
At the Status Meeting the team reviews the last week’s work to see if the team is still onschedule.
The team writes a Progress Report to ensure management that the ongoing work is onschedule and progressing correctly. The management suggests what this report shouldcontain, but nothing is determined until the negotiation phase. The report should be keptsimple and short.
The team plans the next week’s work and writes a Weekly Schedule.
1/3 Presentation
When the team has used one third of the scheduled project time, it gives a presentation onhow it will produce the assignment deliverables. All people involved with the assignmentattend the presentation.
Team Review
Team reviews are considered to be the most important tool concerning, early defect detectionand defect prevention, of future defects. The team review consists of a preparation and areview meeting. During the preparation, the team members review the material to find defects
and misunderstandings. At the review meeting, all defects found are pointed out but notcorrected.
Team members, members from other affected teams, and necessary experts attend themeeting.
To make the team review as powerful as possible, it is important that preparations are handledthoroughly. In many organizations a 3-1-1 cycle is used. This implies that during the first
8/18/2019 Lucru Munca in Echipa
23/82
22
three days of the week the team members work on their assignment. The fourth day the team
members review each other’s work and on the last day, the team holds the review meeting.
Work Meetings
At a work meeting, technical problems and solutions are discussed in an informal manner.
The meeting is initiated on request from any team member. Affected external team membersand experts can attend this meeting.
4.6 Management tools
No actual Management tools are discussed in this chapter but some important issuesconcerning the management’s relation to the team are pointed out.
Management should do everything in their power to ease and support the team’s work.Management should, at no time, try to take control of the team. To support the team,management should help, and suggest tools and models that can be used by the team.
8/18/2019 Lucru Munca in Echipa
24/82
23
5 Team Metric Model
In an attempt to merge important characteristics from the Teamwork Model, [Martín-Vivaldi]and [Jansson], with ideas from the PSP [Humphrey], Sebastian Courel developed an add-on tothe Teamwork Model. The result included features like:
• Self management (Teamwork)
• Commitment (Teamwork)
• Joint responsibility (Teamwork)
• The team plans and executes its own work (Teamwork)
• Self improvement (PSP)
• The individual measures and plans his own work (PSP)
• Gradual introduction of quality methods (PSP)
[Courel]
Measurement Execution
M e a s ur e
m en t
P l ann
i n g
InitiationPhase
ExecutionPhase
ConclusionPhase
Metric
Plan Go Go
End
CollectedData
DataAnalysis
Definition
Target
Process
Form&
Tools
Collect Analyse
TeamMetricModel(TMM)
8/18/2019 Lucru Munca in Echipa
25/82
24
The TMM is divided into two parts, the Measurement Planning and the Measurement
Execution. The team carries out the first part of the TMM, The Measurement Planning,
during the Initiation phase. The Measurement Planning is described in chapter 5.1. The team
carries out the second part of the TMM, the Measurement Execution, during the Execution
Phase. Additional information on Measurement Execution is located in chapter 5.2.
A central document is the Metric Document . It consists of two parts. One part is, as described
in chapter 5.1, the Metric Plan. The second part is the collected data and a data analysis.
One feature with introducing TMM is that the team will grow a toolbox for new
measurements. The team can add new metrics, and as new projects form, and the team
matures in its measurement experience, it will be able to create new measurements.
It is of most importance that team members are frank with their metric reporting. If
management is to view any of the individually collected team-member-metrics, it should be
viewed with extreme care, and only when agreed upon by the whole team.
It is the intention of the TMM, that old team-data, could be used as reference by other teams.
Chapter 5.3 presents some general suggestions to teams when introducing the PROBE method
on a team level [Courel].
5.1 Measurement Planning
The Measurement Planning, which the team carries out during the Initiation Phase, consists
of a number of sub-steps. They are Definition, Target, Process, and Forms & Tools. The
different sub-steps are discussed more thoroughly below. The result of the Measurement
Planning is the Metric Plan.
Definition
It is important that the team does not use metrics and metric collection without clearly defined
goals for their excess work. The team needs to know why metrics are collected and what kind
of metrics to collect. The team should first decide upon the objectives, and then decide which
metrics it should collect. The team can do three standard types of measures. They aremeasures of time, size, and defects. By combining the different standard measures, the team
can make a number of interesting studies. Courel suggests, that as a first step, the team should
select one or two of the following objectives to study.
Combination Defect Size Time
Time Defect injection rates
Defect removal rates
Defect fix time
Productivity (LOC/hour)
Code Growth
Development time ratios
Tracking
Size Defect density Tracking (estimated – actual)
Defect Defect tracking
Yield
Defect categories
[Courel]
8/18/2019 Lucru Munca in Echipa
26/82
25
Development time ratios
Using only time measures, the team can study how long time it spends in each phase. It is also
possible for the team to calculate some time ratios. Interesting ratios to check can be to check
if time spent in the design phase is greater than time spent in the code phase. This would
result in a quality design [Humphrey99]. Check if the design review takes 50% of the time
spent in design, thus indicating it was a thorough design review [Humphrey99].
Time tracking
If the schedule, formalized in the Detailed Team Plan, includes many milestones, i.e. many
well-defined checkpoints, the team can get valuable feedback to its time estimates. It can do
so by keeping track of time spent in different phases. By doing this, the team can discover
violations to the Detailed Team Plan, early on in development.
Size tracking
By keeping track of size and compare actual code size versus estimated code size, the team
can check how good size estimates it makes. If the team’s estimates are found not to bereliable, it can indicate that something is wrong in its process. Maybe the team designs its
software too little. Keeping track of program size can work as an input parameter to thePROBE method.
Productivity
The team can measure the productivity both at a team level and at a member level. The
measurements recorded at member level should be handled with care. It should never, at anytime, be used for measuring individual team member effort. The reason for this is thatproductivity is usually measured in LOC per hour, and different team members might havedifferent roles to play in the team. This could give a wrongful picture of the individualproductivity when two members are compared.
Code growth
Keeping track of in what phases the code is growing, can give the team an indication of howwell its process is working. If the code is growing substantially in the test phase this couldindicate that the team does not have a quality product. It has been developed through testingand not by a good design [SEL90].
Defect categories
The technique the team uses to review its work at the end of each development phase, iscalled a phase-review-technique. By logging what kinds of defects are introduced, the teamcan get an indication of the defect-type frequency in the code. The measurement can help theteam to focus on special defect-types and try to eliminate the introduction of them into thecode. By also logging in what phase the defect is introduced, the team can refine its phase-review-technique.
8/18/2019 Lucru Munca in Echipa
27/82
26
Defect tracking
Used correctly this measure can give the team an indication on how many defects it should
find during a design review or a code review.
Yield
Yield is calculated by dividing the number of defects at the beginning of a phase by the
number of defects at the end of the phase. Not until all defects are found in the software, the
final Yield ratio can be calculated. The Yield ratio gives the team knowledge of how good theteam is at finding defects during a specific phase. Yield can help the team improve phase-
review-techniques.
Defect injection/Removal rates
Keeping track of both time and when defects are injected and removed, can help the team
acquire an understanding of how the code is developed. Certain defect-time ratios can help
the team understand what happens to the software throughout the process life cycle. The ratio,
number of defects injected in phase divided with the time spent in a phase, shows in what
phases most defects are introduced. The ratio, number of defects removed in phase divided
with the time spent in a phase, indicates what phase is most effective at finding defects.
Defect fix time
By logging how long time a defect takes to fix, combined with the defect-type, and in what
phase the defect was found and introduced, can present the team with valuable information.
For example, the team can find out what defect type that is the most costly, i.e. what the
average fix time is, for a certain defect type, in a certain phase. The team can also get
knowledge of how costly it is to find defects in later phases.
Defect density
The ratio, number of defects divided by LOC, will give the team knowledge about how defect
dense the code is. Old data can be used to estimate the number of defects in newly developed
software. Combining logging defect density and specific phases, can give the team an idea of
the number of defects left in the code after each phase. Different defect profiles produced can
indicate different levels of quality.
[Humphrey95]
High-Quality Defect Profile
0
2
4
6
8
10
12
14
16
Design
Review
Code
Review
Compile Unit Test Integration
Test
System
Test
1 Year
Operation
Process Phases
R e m a i n i n g D
e f e c t / L O C
Poor-Quality Defect Profile
0
2
4
68
10
12
14
16
Design
Review
Code
Review
Compile Unit Test Integration
Test
System
Test
1 Year
Operation
Process Phases
R e m a n i n g D e f e c t s / L O C
8/18/2019 Lucru Munca in Echipa
28/82
27
Target
After the team has decided what objectives to study, thus decided what metrics it will collect,
it should target its measurement goals. The team can ignore measurement goals if it is going
to use the measures as a base for coming analyses. Even if the team has no prior data, the
team might have some quantitative estimate of how the team works. This estimate can form a
base for setting a goal. A goal need not be hard to meet, because a goal that is met, can even if
it is an easy goal to meet, give the team a sense of achievement.
Process
The team should formulate a process for how it should collect data. The process should
answer, how, when, and who, should collect the data. It is important to keep in mind that data
collection should not take too much time. An overhead of 1 to 2 percent is acceptable
[SEL95].
One team member should be appointed measurement responsible. It is his/her job to ensure
that metrics are collected and analyzed.
If metrics can be collected automatically with the help of a tool, this should be decided. If not,
someone or often all members have to collect their metrics by hand. It is not the measurement
responsible’s job to collect all data, more to check that the collection process is followed.
Forms & Tools
If no metric collection tool can be used the team has to develop forms for metric collection.
The Metric Plan Negotiation
The team should negotiate the Metric Plan with management. Issues to discuss are:
• What metrics should be available for management?
• Are company objectives in conflict with team objectives?• Synchronization of quality assurance with other teams and with delivery of executables.
• Does the use of automatic metric collection tools involve large investments?
5.2 Measurement Execution
The Measurement Execution takes place throughout the TALC execution phase. There aretwo sub-steps during this phase. They are Collect and Analyze.
Collect
Throughout the execution phase the metrics stated in the Metric Plan should be collected. Themetrics should be collected by the one/ones, at the time, and in the form stated in the MetricPlan.
8/18/2019 Lucru Munca in Echipa
29/82
28
Analyze
It is the Metric Plan that defines when collected data should be analyzed by the measurement
responsible. At this time, data is compared and analyzed to see if the targets defined in the
Metric Plan have been met. The measurement responsible then presents the analyzed data to
the whole team, and if agreed upon, management.
5.3 Introducing PROBE in Teams
The most important measure recognized by industry is size. The PROBE helps estimating sizeand time, using prior data and a divide & conquer methodology. As the use of the PROBE
progresses, the PROBE delivers estimates that are more advanced. At its best, the PROBE
delivers estimates with prediction intervals. To use the PROBE some preparations need to be
done.
A quick reminder of the key elements used by the PROBE follows.
Proxies
The PROBE uses proxies as input variables. Proxies used are functions, methods, modules or
procedures. The proxy should be the lowest abstraction level of the conceptual design. Theonly requirement of the proxy is that it should be able to be measured in LOC.
The team should decide on a proxy to use if management postulates none.
LOC counters and coding standard
At most companies, a coding standard exists. If it does not exist, one should be produced. A
coding standard should reflect the complexity of the code. It is recommended that a LOC
counter be used.
Proxy Size Database
When different categories within the proxy are used, the accuracy in PROBE estimates
increases. To ease the use of a proxy, Courel suggests that when the PROBE method is first
used, the proxy should not be divided into categories. In future use of the PROBE, the proxy
can be divided.
Historical data
The PROBE uses historical data as input parameters. The team needs to have at least one of
the following historical data types:
• estimated New & Changed LOC
• actual New & Changed LOC
• actual development time
New & Changed LOC includes the number of LOC that needs to be developed and the
number of LOC that needs to be changed in existing code.
8/18/2019 Lucru Munca in Echipa
30/82
29
The PROBE in Teams
When using the PROBE in teams, the team should use a conceptual design in its planing
phase, i.e. the Detailed Team Plan should include a conceptual design on which the time and
size estimates are formed. The conceptual design should not be regarded final until a few
other design ideas have been tried and not proven to be better.
When the team members have identified the proxies, they should collectively decide on the
relative sizes. If one team member have certain expertise on one proxy, the rest of the team
should let him/her decided on the relative size. When no team member wants to judge a
proxy, they should all take a decision in consensus.
The PROBE can be used to se if, and when, a re-negotiation of the Detailed Team Plan should
be held.
8/18/2019 Lucru Munca in Echipa
31/82
30
6 Ericsson Mobile Communications AB
At large companies, different organizations and processes are used. This chapter discusses the
organization at ECS and processes used at the Department of Applications at ECS. The
description focuses on responsibilities and inherent conflicts within the organization and
suggests were the Teamwork Model, introduced in this thesis, can be used. This chapter also
includes a description of the software goals at the Department of Applications [Ericsson].
6.1 Organization
At Ericsson, a matrix organization is defined. The matrix organization consists of two
overlapping organizations, a Line Organization and a Project Organization. These two
organizations have different conflicting goals. While the Line Organization demands well
documented software, the Project Organization’s greatest interest is to get the product, i.e. thesoftware, out on the market as fast as possible. First is an overview of the Line Organizationfollowed by a description of the Project Organization.
Line Organization
The Line Organization consists of departments. Each department consists of a number of sub-departments. The manager of a sub-department manages the resources of the sub-department.
Resources are mainly considered to be staff, but the sub-department manager also handlespurchasing of development tools such as computers and software.
It is the Line Organization’s role to be responsible for the quality of delivered software and to
support the project organization with resources.It is within the Line Organization’s interest, that the staff documents the software developedthoroughly. The reason for well-documented software is to facilitate maintenance and to easethe continuation of development on the, by future projects, common software code base.
The Line Organization is more or less static in its structure, i.e. the same people work in thesame sub-department through a length of time.
8/18/2019 Lucru Munca in Echipa
32/82
31
Project Organization
Within and across the line organizations many project organizations can exist. At the top of
the project organization is the project manager. A project organization can consist of smaller
project organizations or groups. These groups can consist of additional sub groups. At the
bottom level of the project organization, are people allocated from different Line
Organizations. The structure at sub-department level is typically the one of one project leader,
with just a few, to up to 20 people working for him/her. These people do not work together as
teams, in the Teamwork Model sense of the word, rather as people just working together.
It is within the different project’s interest that the product is developed and delivered as fast aspossible. For that reason, the documentation of a product is not prioritized. Since the company
has an urge to put new products on the market, as fast as possible, this often results in lessdocumentation of the product, which in turn can lead to less quality in the end-product.
The Project Organization is dynamic in its structure, i.e. a person does not have to work onthe same project all the time, but can join a project at any time.
6.2 Processes
At the department level at Ericsson a waterfall process, described below, for producingmobile phones, has been developed, tested and used. The waterfall process is known as thesoftware product process. Through many years of experience and testing, managementconsiders it to be stable, i.e. the development time of a new mobile phone can be calculated
with reasonable accuracy. The waterfall processdivides the work into modules, with a well-definedmilestone in-between. In each module a specifictask is performed. The task can be anything from aPre-study of the work to come, Analysis,Implementation, Testing, etc. A milestonedocument is created to explain the findings made.The work on a new module can not be initiateduntil the prior module is completed and the
milestone document written. The waterfall processis aimed at large-scale projects, affectingdepartments and sub-departments. The staff,actually working on the project, is not exposed to theprocess.
A second, incremental process model, known as the
software platform process, has been developed tobetter illustrate the software process and to allowbetter sub-department synchronization. When usingthe incremental process model, tasks or programfunctionality is identified. Some functionality has tobe developed before other can be developed. When
using the incremental process model, a task-dependency-map is created. Each increment consists of the same sub steps and works as ascaled down module process. The incremental process model affects, as well as the modulemodel, only the departments and sub-departments at ECS.
At the bottom level, no real process is used. Until now, staff engineers have been working asindividuals within the different projects. A buddy system has been tried in an attempt to
spread knowledge throughout the organization. This system has not worked satisfactorily.Because of lack of system, or process, the code developed has little documentation, the
Increment 1
Increment 2
Increment 3
Increment 4
Increment 5
M i l e s t o n e 1
M i l e s t o n e 2
M i l e s t o n e 3
M i l e s t o n e 4
M i l e s t o n e 5
M o d u l e 1
M o d u l e 2
M o d u l e 3
M o d u l e 4
M o d u l e 5
8/18/2019 Lucru Munca in Echipa
33/82
32
projects are missing their deadlines, and staff is under pressure and has to deal with high
levels of multitasking. Some key engineers have become very valuable to the company, since
they are the only ones that know about “their” area. This makes the whole organization veryfragile.
It is within the incremental process, the Teamwork Model introduced in this thesis, will beused. The idea is that the Teamwork Model with TMM will work at the lowest level of thedevelopment chain. The Teamwork Model should help predict development time, predictcode size, produce proper documentation, and reduce the level of multitasking that staff isexposed to. It should also help spread knowledge throughout the organization, thus also help
introduce new coworkers to the company.
6.3 Software Goals for Ericsson Mobile Communications AB
At the Department of Application an MMI software module for mobile phones is underconstant development. The department has formulated a few, major, software goals, toenhance the output of products.
The first goal is that the code written for the MMI should form a platform code base. Themeaning of this is, that a diversity of products should be able to use the MMI. To do this the
code needs to be scalable to many different product specifications. To be able to realize thisgoal, the code needs to be well documented, to facilitate product specific code tweaking.
At this point, the MMI lacks in documentation, which makes it hard to maintain a propersoftware platform. Management is also aware of that the lack of documentation also rendersthe introduction of new coworkers to the department more difficult.
8/18/2019 Lucru Munca in Echipa
34/82
33
7 The Teamwork Model for Ericsson MobileCommunications AB
This chapter describes how the Teamwork Model, explained in chapter 4, with the TMM add-
on, explained in chapter 5, is merged with the documentation structure and organization
structure at ECS. The Teamwork Model is also adapted to fit a shorter project time span, thus
a new version of the Teamwork Model is created.
Knowledge is spread throughout the organization through reports and meetings. For thatreason, it is important to have both, a well functioning documentation standard and a well
functioning company meeting culture. To be able to merge the documentation standard of the
Teamwork Model and the TMM, with the standard used at ECS, this thesis identifies three
types of documents. Chapter 7.1 describes the three types of documents and all documents
used in the new process model.
To be able to merge the organization structure of the Teamwork Model with the structure at
ECS, this thesis introduces a new player. Chapter 7.2 provides a description of all players in
the new model. The chapter also explains how they interact and what their different roles are
within the model.
At ECS, the number of meetings a person has to attend has grown almost exponentially. Too
many meetings might be a sign of using a poor method [Ericsson]. The Teamwork Modelproposes a number of meetings. To be able to restrict the number of meetings, chapter 7.3
provides a definition of the different meetings that can, and should be used within the new
model. Chapter 4.4 explained the different process steps of the Teamwork Model, the TALC.
The new process model follows in much the TALC with the TMM add-on. Some changes are
introduced to allow a shorter time span. Chapter 7.4 describes the new model’s process steps.
7.1 Documents
When creating the new Teamwork Process Model, three types of documents are identified.
The three types are product documents, project documents, and team documents. Product
documents follow the product throughout its life cycle. Examples of product documents arethe documents used in the Team Assignment Specifications. Project documents, are thosedocuments that are used by the project players to spread knowledge of project status, e.g. theProgress reports. Team documents are typically those documents that follow the teamthroughout the team life cycle, i.e. they follow the team throughout a number of assignments.
An example of a team document is the Final Report.
For the evaluation projects, described in chapter 9, templates for all product documents arecreated. Below follows a description of all documents used in the new Teamwork Model.
8/18/2019 Lucru Munca in Echipa
35/82
34
Team Assignment Specification Document
At ECS, most specifications written, are
function specifications. The function
specifications only describe the
functionality of the application. Other
restrictions, such as architectural
restrictions and general coding restrictions,
are placed in a number of documents.Today at ECS, surprisingly, the function
specifications are rarely written on time.
Management at ECS is concerned about
the fact that this flaw might propagate
erroneous time and size estimates for the projects [Ericsson]. To be able to use the Teamwork
process model with the TMM, it is important that the teams receive a proper Team
Assignment Specification Document. As a step towards introducing the Teamwork process
model at ECS, a template for this document is created.
The Team Assignment Specification Document should include both a Function Specification
Document, containing a description of the functionality of the desired application, and a
Design Restriction Specification Document, containing all general architectural and coding
restrictions regarding the specific application. The Team Assignment Specification
Document, should include all information needed by the team to create its Detailed Team
Plan. The document is typically a product document.
Detailed Team Plan & Metric Plan
The Detailed Team Plan and Metric Plan
are the documents that form the contract
between the players. The Detailed Team
Plan is typically a project document and
the Metric Plan is a team document. No
templates are created for these documents.
The guidelines for these documents are the
same as described in chapter 4.4 and
chapter 5.1.
Since the Detailed Team Plan forms the
project contract between the players, it is probably the most important project document. The
Detailed Team Plan serves two purposes. It is an assurance to management that the team will
do the correct task in an accurate manner and it helps the team visualize what to do and when
to do it.
When the team uses the PROBE, the Detailed Team Plan should include a Conceptual
Design. When creating software for applications for mobile phones, it is crucial thatinformation on memory usage, code structure, and file-structure is given as early as possible
[Ericsson]. Since a Conceptual Design is non-specific regarding this information, this thesis
proposes that the Conceptual Design be substituted by a High-Level Design, including this
information.
The Metric Plan is an important team document. In this document, the team specifies what
area of its process it will study. It is central that the team does not feel that it is forced to
review its process. It should rather feel that it has been given a chance of improving its
Team Assignment Document
Function Specification
Document
Design RestrictionSpecification Document
The Contract
Detailed Team Plan Metric Plan
8/18/2019 Lucru Munca in Echipa
36/82
35
process and that management is in favor of this improvement process. The Metric Plan is part
of the contract between the players.
Progress reports
In the Teamwork Model, information on project progress
is past to management through Progress Reports. This
thesis proposes, that at least once a week, the team writes
a written Progress Report. If there is a need for more
Progress Reports, these should be oral Progress Reports.The Progress Report is considered to be a project
document and should be written brief. The main goal of the Progress
Report is to inform management that the project is on time and that no
deviations from the Detailed Team Plan have occurred.
Application Description Document
The description of the produced application is a significant product
document. As long as the application is in use, the description will live
with it. The document is mainly used to facilitate maintenance and to ease
application tweaking for different hardware configurations. A template iscreated for this document to ensure that the description includes all parts
requested by ECS. These parts are a problem description, a solution
description, a graphic UML description, and a description of how to port
between different hardware configurations.
Final Report
Together with the Metric Plan, the Final Report is the key document to the
team’s process improvement. The Final Report is a team document and notemplate is created for it. The document is mainly written by and for the
team members. If members from management are to read the Final Report,it should not include individual team member data. It includes various ideasand thoughts of how the team process can be refined. The improvementideas should be based on an analysis of the collected metrics. The analysisis also included in the Final Report.
Progress ReportProgressReport
Application DescriptionDocument
Final Report
8/18/2019 Lucru Munca in Echipa
37/82
36
7.2 Organization
In the original Teamwork Model, chapter 4, three main players are discussed. The players are
the Assignment Orderer (AO), the Resource Responsible (RR), and the Assignment
Performer (AP). Another player discussed, is the External Resource (ER).
At ECS, the project manager allocates a project leader and staff from a sub-department. The
number of staff engineers involved in a project is normally larger than the recommended
Teamwork team size, i.e. more than five people. To fit this organization, this thesis introduces
a new player, the Team Owner (TO). The TO can be the former project leader, but instead of managing a number of single staff engineers, he/she manages a number of teams. If the TO is
going to handle a number of teams, it is recommended that he/she is given a small staff to
help him/her organize the work, e.g. help write specifications, help be responsible for certain
specific areas, etc. If the TO has a staff, this whole group should be regarded as the TO.
What are the benefits of having such a player in the organization?
• The TO can be thought of as a pipeline between the AO, the RR, and the AP, thusreducing the work load for management, e.g. reduce the number of meetings the AO and
the RR would have to attend, divide the AO’s work to fit a team, write Team Assignment
Specification, etc.
• The TO can coordinate a number of team projects, forming a larger project.• The TO can synchronize many AO’s assignments, thus forming one general assignment
to be used by many products.
• If staff engineers exist, valued to important to be included in a team, the TO can stillmanage these peoples’ work. These people can also act as ER’s for different teams.
The organizational structure would be as depicted below.
Teamwork Organization at EricssonMobile Communications AB
Assignment
Orderer
Team Owner
ResourceResponsible
ExternalResources
AssignmentPerformer
8/18/2019 Lucru Munca in Echipa
38/82
37
The different players’ roles are as follows:
• The AO is the person/persons in the project organization ordering the project. Theirinterest is the finished product. There can be many AO’s for one team project, i.e. anassignment’s or project’s product can be used by more than one retail product. The AO
has an overall deadline for the finished retail product.
• The RR is, as before, the owner of the personnel and hardware. It is also the RR who willmanage the maintenance of the finished product. It is in the RR’s interest that, if possible,the code produced can be used in a variety of end products and that the product is welldocumented. It is also in his interest that deadlines are followed so that he can optimizethe resource usage. The RR is also interested in the ongoing team process improvement
work.
• The TO acts as a person between the Team and the AO/RR. The TO should be anexperienced and knowledgeable person both in processes and in technical issues. The TOcan handle a number of teams. Based on the estimates made by the teams, stated in theirDetailed Team Plans, the TO negotiates deadlines with the RR and the AO. Since the TOhandles or manages a number of teams he can aid the teams with sharing information and
code. It is the TO who will divide the assignment, given by the AO, to fit a teamworkload. He will also try to join as many assignments from different AO’s as possible,to formulate one general assignment. The TO will also manage and assist the team, i.e.allocate experts or assist the team in terms of aiding the team in interpreting their
collected metrics.
• The AP is the team consisting of 2 to 5 people. The team will carry out the assignmentgiven to them by the TO. The team is thought of as one. The different members have jointresponsibility of all issues regarding the product they are developing.
• The ER is an important actor to the team. The ER is appointed to the team to perform aspecific task and then leave the team. An ER can work on many teams at the same timeand does not share the team members' common responsibility. Staff members consideredto be too valuable to be locked up in a team, are considered to be ER’s.
8/18/2019 Lucru Munca in Echipa
39/82
38
7.3 Meetings
Together with reports, meetings are the only way of spreading
knowledge throughout the company. It is helpful if the number of
meetings a person has to attend is small [Ericsson].
This thesis divides the meetings to be used in the Teamwork Model
into two categories. One category of meetings is the kind of meetings where only team
members attend, and the other is the kind where people external to the team attends as well.
The only kind of meetings that this chapter discusses, is the latter one.
Kick-Off Meeting
Every new project starts off with a Kick-Off Meeting. All Team members and the TO must
attend the Kick-Off meeting. The RR, the AO, and ER can attend this meeting as well. During
this meeting the requirements are discussed and reviewed. All information that the TO, the
RR, the AO, and the ER might have is revealed. Possible solutions to the assignments are also
discussed.
External Resource Meeting
At the External Resource Meeting, the team meets with the ER provided to the team. At this
meeting issues affecting the ER are discussed in an informal manner. An External Resource
Meeting can be called by any team member and by any ER.
Progress Meeting
Throughout the whole process, Progress Meetings are held. The minimum amount of Progress
Meetings that should be held is once a week. If the project is short or the team is new to the
TO, it is recommended that Progress Meetings are held more often. The Progress Meetings
help build up trust for the team since it is at these meetings that the TO is ensured that theDetailed Team Plan is followed. To inform the TO, the team will give oral Progress Reports.
Written Progress Reports are handed over, when agreed upon in the Detailed Team Plan, at
these meetings. The whole team and the TO attend the Progress Meetings.
Code Review Meeting
When the Team has more or less finalized its code for the assignment, it should call for a
Code Review Meeting. During the meeting, the team and external personnel appointed by the
RR, review the code. The meeting is held to ensure the RR that, the code is written according
to the ruling coding standard, no memory leaks are discovered, and that the code is easily
read, i.e. the code is well commented. This meeting should not replace any team internal codereviews, i.e. when the meeting is held, the team should be content with its quality.
8/18/2019 Lucru Munca in Echipa
40/82
39
Delivery Meeting
The team, the TO and if possible the AO and/or the RR attend the Delivery Meeting. At the
Delivery Meeting the team delivers its results agreed upon in the Detailed Team Plan. The
team shows that the requirements have been followed.
Conclusion Meeting
The team and the TO attend the Conclusion Meeting. The Final report is presented and
discussed. The discussion should include improvements to the internally used team processand improvement to the processes used by the company as a whole that affect the team.
8/18/2019 Lucru Munca in Echipa
41/82
40
7.4 The Process
The new, adapted model uses the same process steps as the Teamwork Model, presented in
chapter 4, with the TMM add-on, described in chapter 5. This thesis introduces some changes
to allow shorter project lead-times and provides a description of the different process steps of
the new model.
Pre initiation phase
Duration: 1-3 weeks
Result: Function Specification Document
Design Restriction Specification Document
During this phase the TO divides up the assignment given by the AO. The TO also creates the
Function Specification Document and the Design Restriction Specification Document needed
by the Team. The TO tries to anticipate the team’s resource-need in terms of personnel and
equipment. The TO will then apply for resources from the RR.
Initiation Phase
Duration: 2-5 days
Result: High-Level Design
Detailed Team Plan
Metric Plan
A Kick-Off meeting initiates the Initiation Phase. At the Kick-Off meeting, the team views
the assignment for the first time. The specifications are reviewed and all ideas and solutionproposals that the TO might have, are discussed.
After the Kick-Off meeting the team members have to agree on a number of subjects. It isduring this phase that the team members become committed to the assignment. The teammembers should focus on the following, while studying the requirements given to them at theKick-Off meeting:
• clarify all ambiguities,
• plan how to reach the requirements,
• divide up the work amongst themselves,
• determine who will function as the team leader,
• define common goals within the team, i.e. make a Metric Plan,
• document all the above steps in the Detailed Team Plan and
• commence the assignment work while waiting for the negotiation of the Detailed TeamPlan.
PreInitiation