prof dr eckhart hanser prof. dr. eckhart hanser

Prof. Dr. Eckhart Hanser: TEAM BUILDING IN AGILE PROJECTSProf. Dr. Eckhart Hanser, DHBW Lörrach, Bio-Systems Informatics / Software-Engineeringe

TEAM BUILDING IN AGILE SOFTWARE DEVELOPMENT: lo

errach.de

THE “PROJECT MANAGEMENT LABORATORY” OF BA LOERRACHw

ww.dhbw-l

OF BA LOERRACHw

Prof Dr Eckhart HanserProf. Dr. Eckhart HanserDuale Hochschule Baden-Württemberg LörrachBaden-Württemberg Cooperative State UniversityHead Department Applied Informatics/Bio-Systems Inform.Head Department Applied Informatics/Bio Systems Inform.

[email protected]

Prof. Dr. Eckhart Hanser, Duale Hochschule BW Lörrach, BW Cooperative State University, Department of Applied Informatics /Bio-Systems Informatics Folie 1

Prof. Dr. Eckhart Hanser: TEAM BUILDING IN AGILE PROJECTS

Biosystem-Informatik• Stein des Anstoßes:

– Eigene Projekte in der PraxisFö d d T bild t– Förderung des Teambildungsprozess unter Studierenden an der DHBW Lörrach / Bereich T h ikTechnik:

• Informationstechnik (IT)• Biosystem-Informatik

• Ziel: Vorstellung des

Meta Agile Process Model (MAP)Prof. Dr. Eckhart Hanser, Duale Hochschule BW Lörrach, BW Cooperative State University, Department of Applied Informatics /Bio-Systems Informatics Folie 2

Meta Agile Process Model (MAP)


Th P j t ithThere are Projects with …

project aim #3changing specifications project aim #3

Refactoring necessary

Documentation has a short lifetime!

project aim #2project aim #2Aim changes! #3

P j t t t

Iteration 1 Iter. 2Iter. 3

Original project aimAim changes! #2

Project start


Original project aimAim changes! #2


Introduction - Agile Manifesto - eXtreme Programming – IT laboratory – Mini team size – Psychology - Conclusions

Agile Manifesto

Kent Beck, Alistair Cockburn, Martin Fowler, Jim Highsmith, Robert C. Martin et.al., 2001

http://www.agilemanifesto.org

Four principles:Individuals and interactions over processes and tools• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiationg

• Responding to change over following a plan




Famous agile representative: Kent Beck’s

eXtreme Programming (XP), g g ( )

Important XP rules to be analyzed:

• Designing User Stories

• Collective Code Ownership and Software Integration• Collective Code Ownership and Software Integration

• Pair Programming




IT laboratory / DHBW Lörrach

2004, 2005, 2006, 2007, 2008

• 6th semester of Applied Computer Science / Information Technology

• each spring: 11 sessions with 5 (4) hours• each spring: 11 sessions with 5 (4) hours

=> Up to 800 project hours each spring.

• The size of each course determines the number of the team members

=> Up to 20 team members (students + prof.)

• 2004 – 2008: about 3.500 project hours.




Project: Development of an eMail marketing software

Test content for the interPM

Hi $Title$ $Name$,

I‘ l d b h i Dü ld fI‘m glad to be here in Düsseldorf.



IT laboratory of session 2005


yBA Loerrach

Prerequisites: The lecturer fills the positions of project and qualitymanager with suitable “managers” (i.e. students).

In the beginning the rest of the team has no structure,should however form XP pairs.

Members know about process models, especially XP.p , p y

The customer (i.e. the lecturer) is a team member.

Developmentplatform:

MS Visual Studio .NETplatform:

Team aims: Common programming of a “fully featured” emailketi temarketing system.

XP is required (= decision of the lecturer).

Success? Successful product, successful process (in the end).



Key questions, I want to investigate:

Introduction - Agile Manifesto - eXtreme Programming – IT laboratory – Questions – Psychology - Conclusions


1. Roles of Project and Quality Manager in agile projects?

2. Which (XP) practices are not the result of the „self-organization“ of the team?

3 I th id l i i t i ( th th 2) f f l3. Is there an ideal mini team size (other than 2) for successful teams?



Q1 Th j t i il j t


Q1: The project manager in an agile project (i.e. session 2005)

… characterizes his project role as

• coordinator of the project

• problem solver

• communicator

NET t• .NET expert

• co-designer of user stories (together with the client)



Q1 Th lit i il j t


Q1: The quality manager in an agile project (i.e. session 2005)

… characterizes his project role as

• product and project quality ( i t ti )assurance (reviews, testing)

• problem solver

• communicatorcommunicator

• .NET expert

• co-designer of user stories (t th ith th li t)(together with the client)

Agrees with the view of the project manager! No classical project roles in this agile project. °


p j g p j







3 I th id l i i t i ( th th 2) f3. Is there an ideal mini team size (other than 2) for successful teams?



Q2 D i f t i


Q2: Design of user stories

• In every session only project manager, quality manager and few team members where interested in creating user stories.

• Only when the mini teams had chosen their story cards they began actively• Only when the mini teams had chosen their story cards, they began actively to make a detailed low level design.

• We saw no readiness in the team for collective design or code ownership.

N ll ti d hiNo collective code ownership



Q2: Integration XP says: „Only a pair integrates code at a time.“


Q g y „ y p g

But our experience in all sessions:

• Integration is not a result of the „self-organization“ of the team (> 3 programmers).

• 2004 – 2008 integration only took place after heavy interventions of the customer.

• The lecturer had to take over the role of a communicator not of a typical customer!• The lecturer had to take over the role of a communicator – not of a typical customer!

not to solve the problem, but to communicate its existence.

• Integration had to be „centralized“. g

Not only one machine but also one team member (with full responsibility)

• New role: Integration Engineer• This has to be controlled strictly by the project management.


=> We need a project management!


A new team role: Integration EngineerIntroduction - Agile Manifesto - eXtreme Programming – IT laboratory – Mini team size – Psychology - Conclusions

g g

sits a little “aside“sits a little aside …“Lone Wolf”


session 2005







3 P ti l i h th t t ith b t 5 b3. Practical experience shows that teams with more as about 5 members subdivide into „mini teams“:

1. In XP such a mini team is called a „pair“ (2 members). ( )Are these pairs successful?

2. Is there an ideal mini team size (other than 2)?

3. Do we see a self-organization process of successful mini teams?

4. What is the member structure?


4. What is the member structure?


Q3 Mi i t i


Q3: Mini team size

i 2004 i 2005 2008session 2004 session 2005 - 2008

Mini teams with 3 members as“starting point”.

XP pairs as initial mini teams.

Result: XP pairs do not occur.

Minimal mini team size remains 3.

The most successful mini team has 4members.



Project


Q3 Mi i t i

We see

Project start

Q3: Mini team size

We see

3 pairs…

A triplet First pair grows into a triplet!


session 2005



2 k2 weeks later

But also one

Super teamteam

with6 members

fori t ti


integrationsession 2005


4 k


4 weeks later

O l 1Only 1 "classical“

XP pair

XP pairs decrease!decrease!


session 2005


Mini Team Size


session 2004 session 2005 Session 2008

Mini teams with 3 XP pairs as initial mini XP pairs as initial mini

Mini Team Size

Mini teams with 3members as “startingpoint”.

XP pairs as initial miniteams.

XP pairs as initial miniteams.

Result: XP pairs do not Result: Number of XP Result: 3 XP pairsResult: XP pairs do notoccur.

Result: Number of XPpairs seems to decrease.

Result: 3 XP pairs“survive”.

Minimal mini team sizeremains 3.

Most mini teams grow insize (3, 4 or more).

50% of the team are XPpairs!remains 3. size (3, 4 or more). pairs!

The most successful miniteam has 4 members.

In special phases, e.g.integration, we see ateam size of 6 members.

Integration: several pairsform a larger integrationteam.team size of 6 members. team.

Mini team size “oscillates”


depending on the phase/activity.


Inter XP pair relations (2008)


Inter XP pair relations (2008)




“Super team” explained:

• 5 members

• Integrates the code in a critical Integration Engineer

phase.

• The members take responsibility for the integrationfor the integration.

• The project would fail, if they did not succeed.not succeed.

session 2005




Organizational psychology:Organizational psychology:


discussed with Rainer Baldegger, „Erfolgreich im Team“



A successfull Mini Team needs particularly

• Creative Mind

• Technical Expert

• Technical Problem Solver

• Quality TesterTechnical Expert

• Team Worker

• Communicator

Quality Tester

• Communicator




Details of the “super team“

Problem solver / integrator

“Lone wolf“ Integration Engineer

Team worker

Expert, creative

mind

Lone wolfProject Manager

“external“ Communicator

(P j t

Team worker

mind (Project manager)

Expert, creative

mind“internal“

communicator, creative mindcreative mind

Quality ManagerQuality tester


session 2005

Quality Manager


IT-Labor 2007 – Prozess Crystal ClearIntroduction - Agile Manifesto - eXtreme Programming – IT laboratory – Mini team size – Psychology – Actual results

IT Labor 2007 Prozess Crystal ClearBewertung des Prozess durch das Team / Umfrageergebnis:

Schulnoten!

Wissenschaftliche Begleitung:aus Studienarbeit


Niko Hättich 2007


Crystal Clear 2007

Introduction - Agile Manifesto - eXtreme Programming – IT laboratory – Mini team size – Psychology – Actual results

Crystal Clear 2007

(1) Note nur für interne Osmotische Kommunikation nachvollziehbarnachvollziehbar

(2) Reflektion nicht festgestellt.

(3) Lieferungen unregelmäßig(3) Lieferungen unregelmäßig.

2007: Team fährt“ seinen eigenen agilen Prozess!


2007: Team „fährt seinen eigenen agilen Prozess!


„Meta Agile Process Model“ (MAP Methodology)


„Meta Agile Process Model (MAP Methodology)A successful project in a small to medium-sized team needs the following “ingredients“:

C t• Customer• available to the team

O t C i ti d d fl ibl• One or two Communication managers, good and flexible• for project and quality management

• Integration engineer• continuous software integration

• Well-balanced project team with a good psychological process • 6 characters / types of project members (organizational psychology)


Mini-Team-Size is „oscillating“!


MAP Referenzprojekt aus der Chemie-Industrie:Sep 2008:Sep. 2008:

• Erfolgreiche Diplomarbeit g pals „Feldversuch“ zur agilen Methodology MAPgy

• Laborergebnisse werden im Wesentlichen bestätigt!Wesentlichen bestätigt!



Rollen:Rollen:• Kunde 1 PersonRotes Telefon“• Kunde 1 Person

• Projektleiter 1

„Rotes Telefon

• Qualitätsmanager 1

• Entwickler 5 (im Schnitt 3)

• Integrierer 1 (hier = PL)• Integrierer 1 (hier = PL)

• Tester 1



Probleme mit Pair ProgrammingProbleme mit Pair Programming bestätigt:• Voraussetzung: Sozialkompetenz

• Problem: Effizienz

• PP im Team als nicht notwendig erachtet!PP im Team als nicht notwendig erachtet!

• Truck-Faktor durch Kommunikation reduziert.



Allg. Projekt mit IT-Fokus (Okt. 2008):LKW Abfertigung in einer ÖlraffinerieLKW-Abfertigung in einer Ölraffinerie• Highlight: Impl. eines Zugangskontrollsystems• Der Kunde kommt aus dem operativen Betreiber-Bereich

mit starken DV-KenntnissenP j ktl it k t d P j kt bt il fü N b• Projektleiter kommt aus der Projektabteilung für Neubau-Projekte (eigene Anlagenbauprojekte bis 15 M€ pro Proj.)

• hohe Schnittstellen zu vom Projekt Betroffenen Beteiligten• hohe Schnittstellen zu vom Projekt Betroffenen, Beteiligten und Interessierten; vor allem zu den Gewerken Tiefbau, Elektrik und Mess- und RegeltechnikElektrik und Mess und Regeltechnik

• MAP wird bestätigt!– siehe auch GPM-Newsletter


siehe auch GPM Newsletter

prof dr eckhart hanser prof. dr. eckhart hanser

Documents