lucru munca in echipa

8/18/2019 Lucru Munca in Echipa

1/82


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.


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.


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


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


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.


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


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.


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]


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


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?


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


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]


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)


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.


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


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.


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]


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.


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.


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


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.


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)


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]


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.


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


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.


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.


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.


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.


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


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.


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.


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


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


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


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.


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.


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.


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