Iwot2017 teamwork in software development

Teamwork in software development:
From self-managing agile teams to multi-team projects
Keynote, International Workshop on Teamworking 21: 
Putting knowledge into team design
Trondheim, 7 September, 2017
Torgeir Dingsøyr
Chief Scientist, SINTEF Digital
Adjunct Professor, Department of Computer Science 
Norwegian University of Science and Technology
Handouts: http://bit.ly/2iZSwjr

Overview
1. Why is Teamwork in Software Development Interesting?
2. Agile Software Development in 10 minutes
3. Teamwork in Agile Development
4. Teamwork in Multi-team Development Projects
5. Future challenges; Teamwork research needs from
practitioners

1. Why is Teamwork in
Software Development
Interesting?

Picture: Arkady Arkagorodsky - http://msprojectreporter.com/wp-content/uploads/2016/08/, Public Domain, https://commons.wikimedia.org/w/index.php?curid=58353093

Teamwork in agile development
«The best architectures, requirements, and
designs emerge from self-organizing teams»
Principle behind agile manifesto

0"
20"
40"
60"
80"
100"
120"
Psychological"factors" Social"factors" Team"proper:es" Work"proper:es" Team"processes" Team"external"
proper:es"
Team"outcomes"
Other"disciplines"
Informa:on"Systems"
Sofware"Engineering"
IKT
Studies on software teams
Dingsøyr, T., Fægri, T. E., Dybå, T., Haugset, B., and Lindsjørn, Y., "Team Performance in Software Development: Research Results versus Agile Principles," IEEE Software, vol. 33, pp. 106-110, 2016.
0"
20"
40"
60"
80"
Psychological"factors" Social"factors" Team"proper:es" Work"pro
0"
20"
40"
60"
80"
100"
Psychological"factors" Social"factors" Team"proper:es" Work"proper:es" Team"p
0"
20"
40"
60"
80"
100"
120"
Psychological"factors" Social"factors" Team"proper:es" Work"proper:es" Team"p
Software engineering
Information systems
Other disciplines

ICT
Studies on agile development
Dingsøyr, T., Nerur, S., Balijepally, V., and Moe, N. B., "A Decade of Agile Methodologies: Towards Explaining Agile Software Development," Journal of Systems and Software, vol. 85, pp.
1213-1221, 2012. Figure 2: Publications on agile software development by country. Darker colour indicates more publications.

2. Agile Software
Development in 10
minutes

IKT
Scrum
Source: www.scrum.org

Sprint planning
Code the middle tier (8 hours)
Code the user interface (4)
Write test ﬁxtures (4)
Code the foo class (6)
Update performance tests (4)
Product backlog Iteration backlog (“sprint")

Form groups of three to four persons.
Raise your hands when you have formed a group.
Exercise; Effort estimation

IKT
Estimation; Planning poker
Henrik Kniberg: Scrum and XP from the Trenches, 2007.

IKT
Exercise; Effort estimation
Assume that “noodles” has a value of “2”, estimate the work involved
making the following dishes using planning poker:
n Pizza
n Spaghetti Bolognese
n Fish soup
Planning poker:
1. Distribute a deck of cards to each group member.
2. Make an individual estimate; identify the closest card.
3. Everyone shows their cards.
4. If you agree, record estimate, if not:
5. Ask for arguments for the highest and lowest estimate.
6. Goto 2

Daily meetings
1. What did I do yesterday that helped the development
team meet the sprint goal?  
2. What will I do today to help the development team meet
the sprint goal?  
3. Do I see any impediment that prevents me or the
development team from meeting the  
sprint goal?
Schwaber, K. and Sutherland, J., "The Scrum Guide," 2016. Available from: http://www.scrumguides.org/

Sprint review: Demonstrating product

Dybå, T., Dingsøyr, T., and Moe, N. B., Process Improvement in Practice - A Handbook for IT Companies. Boston: Kluwer, 2004.

3. Teamwork in Agile
Development

IKT
Agenda: Focus group
n Exercise1:
n Brainstorm:
n What fosters effective teamwork (green stickers)?
n What hinders effective teamwork (yellow stickers)?
n Lightning talk: A team performance model
n Exercise 2:
n Presentation of topics from exercise 1
n Group the stickers on flip-over in categories

ICT
IKT
Team
leadership
Team
orientation
Mutual 
performance
monitoring
Adaptability
Back-up 
behaviour
Shared 
mental 
models
Mutual 
trust
Closed-loop 
communication
Salas et al. Team Performance Model
Salas, E., Sims, D. E., and Burke, S. C., "Is there a "Big five" in teamwork?," Small Group Research, vol. 36, pp. 555-599, 2005.

ICT
What fosters or hinders team
performance?
Dingsøyr, T. and Lindsjørn, Y., "Team Performance in Agile Development Teams: Findings from 18 Focus Groups," in Agile Processes in Software Engineering and Extreme Programming. vol. 149, H.
Baumeister and B. Weber, Eds., ed: Springer Berlin Heidelberg, 2013, pp. 46-60.

ICT
Team leadership
No.ofstickers
Foster team performance
Hinder team performance
0"
2"
4"
6"
8"
10"
12"
14"
16"
18"
20"
Planning" Shielding"from"
Interrup:ons"
Work"process" Adequate"resources" Infrastructure"
Dingsøyr, T. and Lindsjørn, Y., "Team Performance in Agile Development Teams: Findings from 18 Focus Groups," in Agile Processes in Software Engineering and Extreme Programming. vol. 149, H.
Baumeister and B. Weber, Eds., ed: Springer Berlin Heidelberg, 2013, pp. 46-60.
0"
2"
4"
6"
8"
10"
12"
14"
16"
18"
20"
Planning" Shielding"from"
Interrup:ons"
Work"process" Adequate"resources" Infrastructure"

IKT From Bent Hamer, the movie “Kitchen stories”, 2003.

ICT
Project Overview
Moe, N.B., Dingsøyr, T., and Dybå, T., A teamwork model for understanding an agile team: A case study of a Scrum project, Information and Software Technology 52 (2010) 480–491.

ICT
In Theory: Team Leadership
n Definition:
n Direct and coordinate the
activities of other team
members
n Assess team performance
n Assign tasks
n Develop team knowledge,
skills, and abilities
n Motivate team members
n Plan, organize, and establish a
positive atmosphere
n The Scrum team:
n Planning
n Scheduling
n Assigning tasks to members
n Making decisions
n The Scrum master:
n Removes impediments of the
process
n Facilitates meetings
Salas, E., Sims, D. E., and Burke, S. C., "Is there a "Big five" in teamwork?," Small Group Research, vol. 36, pp. 555-599, 2005.

ICT
In Practice: Team Leadership
«We classified tasks as finished before they were completed, and we
knew there was still work to be done. It seems that the scrum master
wants to show progress and make us look a little better than we really
are»
– developer
«The daily meetings are mostly about reporting to the Scrum
master. When he is not there, the meetings are better because then
we communicate with each other»
– developer

IKT
Team
leadership
Team
orientation
Mutual 
performance
monitoring
Adaptability
Back-up 
behaviour
Shared 
mental 
models
Mutual 
trust
Closed-loop 
communication
Scrum
Case

4. Teamwork in Multi-
Team Development
Projects

Importance of coordination
«While there is no single cause of the software
crisis, a major contribution is the problem of
coordinating activities while developing large
software systems. We argue that coordination
becomes much more difficult as project size and
complexity increases»
Kraut and Streeter, Communications of the ACM, 1995

The Scrum of Scrums
Kniberg, H., Scrum and XP from the Trenches: InfoQ, 2007, 2nd edition 2015.
Scrum of scrums

But does it work?
«Scrum-of-Scrum meetings involving representatives from all
teams were severely challenged: the audience was too wide
to keep everybody interested ... often ending up not reporting
anything»
(Paasivaara et al. 2012)
«inter-group coordination becomes a major challenge when
groups enjoy high levels of autonomy»
(Ingvaldsen and Rolfsen 2012)
Paasivaara, M., Lassenius, C., Heikkil, V. T., "Inter-team coordination in large-scale globally distributed scrum: do scrum-of-scrums really work?," Proceedings of the ACM-IEEE international
symposium on Empirical software engineering and measurement, Lund, Sweden, 2012.
Ingvaldsen, J. A. and Rolfsen, M., "Autonomous work groups and the challenge of inter-group coordination," Human Relations, vol. 65, pp. 861-881, Jul 2012.

Coordination modes
Plans
Routines
Personal Impersonal
Horisontal
Vertical
Individual
Scheduled meetings
Unscheduled meetings
Group
Van de Ven, A. H., Delbecq, A. L., & Koenig Jr, R. (1976). Determinants of coordination modes within organizations. American sociological review, 322-338.

Many practices of coordination
■ All three modes used
■ 19 coordination practices in total
”I think the combination of scheduled and
unscheduled coordination that just appeared
was very important”
(scrum master and developer)
Dingsøyr, T., Moe, N. B., and Seim, E. A., "Coordinating Knowledge Work in Multi-Team Programs: Findings from a Large-Scale Agile Development Program," Work in progress.
Dingsøyr, T., Moe, N. B., Fægri, T. E., and Seim, E. A., "Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation,"
Empirical Software Engineering, pp. 1-31, 2017.

Conclusion
■ Teamwork is essential in software development
■ A number of changes in how software development is
conducted
■ An interesting form of knowledge work
■ Small but growing body of studies

5. Future challenges;
Teamwork research
needs from
practitioners

Requests from the software industry
Gregory, P., Barroca, L., Sharp, H., Deshpande, A., and Taylor, K., "The challenges that challenge: Engaging with agile practitioners’ concerns," Information and Software Technology,
vol. 75, pp. 26-38, 7// 2016.
(13) people over process worldview to a future of autonomous, self-managed
agents in a systemic organisation is too much if the
system does not change itself – including leaders’
Changing mindsets (7) Agile is more than a set of practices used by IT
requiring wide ranging change to work patterns
‘It’s a mindset not a methodology. Without a change
in mind set the result will not be met’
National culture (5) Differences in national culture, particularly
between East and West, compound issues with
organisational culture
‘Is it possible to do agile with all nationalities and
cultures?’
. Distributed teams (5) Business realities are often contrary to the agile
need for co-located teams, with teams distributed
across the UK, Europe or worldwide
‘It requires co-location in a digital world, where
travel is too expensive’
Trust (1) Providing a safe environment to develop and
innovate
‘What is the cost for not investing in trust?’
Team practices (11) Uncertainty and perhaps lack of training in specific
practices or techniques
‘How to estimate/ better estimate the effort to
support planning?’
Leadership (5) Traditional project management approaches of
’command and control’ need to be replaced by a
facilitation style of leadership
‘That the manifesto lacks Leadership over
Management’
Finding good people (4) Agile requires skilled, self-directed and motivated
team players
‘Getting the right people interested- decision makers
and users’
Individual motivation
(4)
Agile philosophies are often at odds with
organisational reward structures that value
individuals
‘It sometimes marginalises lonely problem solvers’
Process improvement
(15)
Once adopted, agile requires on-going change and
commitment in order to become sustainable and
embedded within teams and the organisation
‘If it is codified it becomes "bureaucratic" and if not it
is too diverse to be taken seriously’
Documentation (4) Tensions arise when management sees
documentation as a way to demonstrate control
whilst developers focus on code over documents
‘That it has become an excuse not to do any
documentation or planning beyond the sprint and
product backlog’
Contracts (3) Standard contracts require detailed upfront
specifications that are contrary to the evolving
approach of agile
‘Some think they need a contract’
Knowledge sharing (1) Needs a positive learning environment to motivate
individual commitment in order to establish
effective knowledge sharing
‘We innovate but we don’t really share innovations’
Large projects (10) Working at programme level where team practices
need to scale across multiple teams in large
complex projects
‘Agility in large projects effecting several applications,
platforms, techniques’
Governance (5) Traditional mechanisms that ensure projects
achieve regulatory or legal compliance are often
‘Have not yet found any clear view on how the
‘governance’ at Business Case level works or could
Teamwork challenges faced by agile practitioners, study by Agile Research Network UK:

Selected studies from our group
n Dingsøyr, T., Moe, N. B., Fægri, T. E., and Seim, E. A., "Exploring software development at the very large-scale: a
revelatory case study and research agenda for agile method adaptation," Empirical Software Engineering, pp. 1-31,
2017.
n Lindsjørn, Y., Sjøberg, D. I. K., Dingsøyr, T., Bergersen, G. R., and Dybå, T., "Teamwork quality and project success
in software development: A survey of agile development teams," Journal of Systems and Software, vol. 122, pp.
274-286, 12// 2016.
n Dingsøyr, T., Fægri, T. E., Dybå, T., Haugset, B., and Lindsjørn, Y., "Team Performance in Software Development:
Research Results versus Agile Principles," IEEE Software, vol. 33, pp. 106-110, 2016.
n Dingsøyr, T. and Lindsjørn, Y., "Team Performance in Agile Development Teams: Findings from 18 Focus Groups," in
Agile Processes in Software Engineering and Extreme Programming. vol. 149, H. Baumeister and B. Weber, Eds.,
ed: Springer Berlin Heidelberg, 2013, pp. 46-60.
n Dingsøyr, T., Nerur, S., Balijepally, V., and Moe, N. B., "A Decade of Agile Methodologies: Towards Explaining Agile
Software Development," Journal of Systems and Software, vol. 85, pp. 1213-1221, 2012.
n Dingsøyr, T. and Dybå, T., "Team Effectiveness in Software Development: Human and Cooperative Aspects in Team
Effectiveness Models and Priorities for Future Studies," in Workshop on Co-operative and Human Aspects of
Software Engineering, International Conference on Software Engineering (ICSE), Zürich, Switzerland, 2012, pp.
27-29.
n Moe, Nils Brede, Dingsøyr, Torgeir and Dybå, Tore, “A teamwork model for understanding an agile team: A case study
of a Scrum project,” Information and Software Technology, vol. 52, 2010, pp. 480–491.
n Moe, Nils Brede, Dingsøyr, Torgeir and Dybå, Tore, “Overcoming Barriers to Self-Management in Software Teams,”
IEEE Software, vol. 26, no. 6, 2009, pp. 20-26.
n Dingsøyr, T., "Postmortem reviews: Purpose and Approaches in Software Engineering," Information and Software
Technology, vol. 47, pp. 293-303, 2005.

Follow the “Agile 2.0” project
https://www.researchgate.net/project/Agile-20

Iwot2017 teamwork in software development

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Iwot2017 teamwork in software development

Similar to Iwot2017 teamwork in software development (20)

Recently uploaded

Recently uploaded (20)

Iwot2017 teamwork in software development