Organisering av digitale prosjekt: Hva har IT-bransjen lært om store prosjekter?

Organisering av digitale prosjekt:
Hva har IT-bransjen lært om store prosjekter?
Tekna prosjektlederkonferanse 2018 
Oslo, 24. April
Torgeir Dingsøyr
Sjefforsker, SINTEF Digital
Professor II, Institutt for datateknologi og informatikk, 
Norges teknisk-naturvitenskapelige universitet

Agenda
1. Kjennetegn og utfordringer i digitale prosjekt
2. Prosjektledelse med smidige metoder
3. Smidige metoder og store prosjekt
4. Koordinering i store IT-prosjekt
5. Oppsummering

1. Kjennetegn og
utfordringer i digitale
prosjekt

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

IKTFlyvbjerg, B. and Budzier, A., "Why Your IT Project May Be Riskier Than You Think," Harvard Business Review, vol. 89, pp. 23-25, Sep 2011.

Risikofaktorer etter relativ viktighet
most important? Can the risk factors be categorized
in such a way as to provide insight into appropriate
risk mitigation strategies?
To address these questions we assembled panels of
experienced software project managers in different parts
items. While there were differences across panels in
the level of importance ascribed to some of these risk
factors, the fact that all three panels independently
selected these 11 risk factors suggests they are, in
some sense, universal. In experimental terms, each
1 2 3 4 5 6 7 8 9 10
Lack of required knowledge/skills
in the project personnel
Lack of top management
commitment to the project
Failure to gain user commitment
Misunderstanding the requirements
Lack of adequate user involvement
Failure to manage end user
expectations
Lack of frozen requirements
Introduction of new technology
Insufficient/inappropriate staffing
Changing scope/objections
Conflict between user departments
0
HKG
USA
FIN
1 = less important, 10 = more important
Figure 1. Risk factors identified by all three panels ordered by relative importance
Keil, M., Cule, P. E., Lyytinen, K., & Schmidt, R. C. (1998). A framework for identifying software project risks. Communications of the ACM, 41(11), 76-83.

2. Prosjektledelse med
smidige metoder.
(Lynkurs)

IKT
Scrum
Source: www.scrum.org

Sprint planlegging
Code the middle tier (8 hours)
Code the user interface (4)
Write test ﬁxtures (4)
Code the foo class (6)
Update performance tests (4)
Produktkø Iterasjonskø (“sprint”)

IKT
Estimering med Planning Poker
Henrik Kniberg: Scrum and XP from the Trenches, 2007.

Daglige møter
1. Hva har du gjort siden sist som hjelper teamet å møte
målene i iterasjonen? 
2. Hva vil du gjøre til neste gang som hjelper teamet å møte
målene i iterasjonen? 
3. Ser du noen hindringer som gjør at du eller teamet ikke vil
nå målene i iterasjonen?
Schwaber, K. and Sutherland, J., "The Scrum Guide," 2016. Available from: http://www.scrumguides.org/

Sprint gjennomgang: Demonstrasjon

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

Kritikk av smidige metoder
n Over-solgt
n “Gammel vin på nye flasker”
n For lite fokus på arkitektur
n Smidige praksiser fungerer sjelden
i virkeligheten
n Fungerer ikke i store prosjekter
Meyer, Bertrand, "Making Sense of Agile Methods,"
IEEE Software, vol. 35, pp. 91-94, 2018.
0 7 4 0 - 7 4 5 9 / 1 8 / $ 3 3 . 0 0 © 2 0 1 8 I E E E MARCH/APRIL 2018 | IEEE SOFTWARE 91
Editor: Cesare Pautasso
University of Lugano
c.pautasso@ieee.org
Editor: Olaf Zimmermann
University of Applied Sciences
of Eastern Switzerland, Rapperswil
ozimmerm@hsr.ch
INSIGHTS
Making Sense
of Agile Methods
Bertrand Meyer
SOME 10 YEARS ago, I realized I
had been missing something big in
software engineering. I had heard
about Extreme Programming (XP)
early, thanks to a talk by Pete
McBreen at a summer school in 1999
and another by Kent Beck himself at
TOOLS USA in 2000. But I hadn’t
paid much attention to Scrum. When
I took a look, I noticed two strik-
ing discrepancies in the state of agile
methods.
The first discrepancy was be-
tween university software engineer-
ing courses, which back then (things
have changed) often didn’t cover
agility, and the industry buzz, which
was only about agility.
As I started going through the ag-
ile literature, the second discrepancy
emerged: an amazing combination
of the best and the worst ideas, plus
much in between. In many cases,
when faced with a new methodologi-
cal approach, a person can quickly
deploy what in avionics is called
Identification Friend or Foe (IFF):
will it help or hurt? With agile, IFF
fails. It didn’t help that the tone of
most published discussions on ag-
ile methods (with a few exceptions,
notably Balancing Agility and Dis-
cipline: A Guide for the Perplexed1)
was adulatory. Sharing your passion
for a novel approach is commend-
able, but not a reason to throw away
your analytical skills. A precedent
comes to mind: people (including
me) who championed object-oriented
programming a decade or so earlier
might at times have let their enthu-
siasm show, but we didn’t fail to dis-
cuss cons along with pros.
Beyond the Boasts and Good
Intentions
The natural reaction was to apply a
rule that often helps: when curious,
teach a class; when bewildered, write
a book. Thus was Agile! The Good,
the Hype and the Ugly born.2 (Also
see the edX online course Agile
Software Development; www.edx.org
/course/agile-software-development
-ethx-asd-1x-0.) My first goal was
to provide a concise tutorial on agile
methods, addressing a frequently
heard request for a comprehensive,
no-frills, news-not-editorial descrip-
tion of agile concepts. The second
goal was analytical: offering an as-
sessment of agile boasts.
These boasts are impressive.
The title of a recent book by one
of the creators of Scrum prom-
ises “Twice the Work in Half
the Time.”3 Wow! I’ll take a produc-
tivity improvement of four any time.
Another book by both of the meth-
od’s creators informs us, “You have
been ill served by the software in-
dustry for 40 years—not purposely,
but inextricably. We want to restore
the partnership.”4 No less! (Was any
software used in producing that
statement?)
The agile literature has a certain
adolescent quality (“No one else un-
derstands!”), but ideas aren’t born in
a vacuum. I quickly realized that the
agile movement was best understood
as evolution rather than revolution.
Although you wouldn’t guess it from
some of the agile proclamations, the
From the Editors
Bertrand Meyer runs agile methods and practices through his personal friend-or-foe
test. Find out more about his experiences and opinions about the hype, ugly, good,
and even brilliant aspects of agile! —Cesare Pautasso and Olaf Zimmermann
Empirical studies of agile software development: A systematic review
Tore Dyba˚ *, Torgeir Dingsøyr
SINTEF ICT, S.P. Andersensv. 15B, NO-7465 Trondheim, Norway
Received 22 October 2007; received in revised form 22 January 2008; accepted 24 January 2008
Available online 2 February 2008
Abstract
Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A system-
atic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified
1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption,
human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about
the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The
main implication for research is a need for more and better empirical studies of agile software development within a common research
agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to
their own settings and situations.
Ó 2008 Elsevier B.V. All rights reserved.
Keywords: Empirical software engineering; Evidence-based software engineering; Systematic review; Research synthesis; Agile software development; XP;
Extreme programming; Scrum
Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
2. Background – agile software development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
2.1. The field of agile software development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
2.2. Summary of previous reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
2.3. Objectives of this review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
3. Review method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
3.1. Protocol development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
3.2. Inclusion and exclusion criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
3.3. Data sources and search strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
3.4. Citation management, retrieval, and inclusion decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
3.5. Quality assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
3.6. Data extraction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
3.7. Synthesis of findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
4. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
4.1. Overview of studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
4.2. Research methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
4.3. Methodological quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
4.4. Introduction and adoption of agile development methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
0950-5849/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved.
doi:10.1016/j.infsof.2008.01.006
*
Corresponding author. Tel.: +47 73 59 29 47; fax: +47 73 59 29 77.
E-mail addresses: tore.dyba@sintef.no (T. Dyba˚), torgeir.dingsoyr@sintef.no (T. Dingsøyr).
www.elsevier.com/locate/infsof
Available online at www.sciencedirect.com
Information and Software Technology 50 (2008) 833–859
Dybå, Tore and Dingsøyr, Torgeir, "Empirical Studies of
Agile Software Development: A Systematic Review,"
Information and Software Technology, vol. 50, pp.
833-859, 2008.

Bruk av smidige praksiser
Rodriguez, P., Markkula, J., Oivo, M., and Turula, K., "Survey on agile and lean usage in finnish software industry," presented at the Proceedings of the ACM-IEEE international symposium on Empirical
software engineering and measurement, Lund, Sweden, 2012.
1 2 3 4 5
Pair programming
Test-driven development (TDD)
Burn-down charts
Collective code ownership
Refactoring
Active customer participation
Self-organizing team
Automated builds
Retrospectives
Daily stand-up meetings
Unit testing
Continuous integration
Release planning
Iteration/sprint planning
Frequent delivery
Prioritized work list

3. Smidige metoder og
store prosjekt

Hva er et stort prosjekt?
Dingsøyr, T., Fægri, T., and Itkonen, J., "What Is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development," in Product-Focused Software Process Improvement. vol. 8892, A.
Jedlitschka, P. Kuvaja, M. Kuhrmann, T. Männistö, J. Münch, and M. Raatikainen, Eds., ed: Springer International Publishing, 2014, pp. 273-276.

Perform-prosjektet
Dingsøyr, Torgeir, Moe, Nils Brede, Fægri, Tor Erlend, and Seim, Eva Amdahl, "Exploring Software Development at the Very Large-Scale: A Revelatory Case Study and Research Agenda for Agile
Method Adaptation," Empirical Software Engineering, 2018. http://rdcu.be/tcT3

Prosjektorganisering

Fysisk organisering

Leveransemodell
Dingsøyr, T., Dybå, T., Gjertsen, M., Jacobsen, A. O., Mathisen, T.-E., Nordfjord, J. O., Røe, K., and Strand, K., "Key Lessons from Tailoring Agile Methods for Large-Scale Software Development," To
appear in IEEE IT Professional, 2018.

Flere faser i parallell

4. Koordinering i store
IT-prosjekt

Viktigheten av koordinering
«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

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

Koordineringspraksiser
Planer
Rutiner
Personlig Upersonlig
Horisontalt
Vertikalt
Individ
Planlagte møter
Uplanlagte møter
Gruppe
Van de Ven, A. H., Delbecq, A. L., & Koenig Jr, R. (1976). Determinants of coordination modes within organizations. American sociological review, 322-338.

Mange praksiser
■ Alle tre typer praksisene i bruk
■ 19 koorineringspraksiser totalt
"å ha nok koordineringspunkter til å vite at «oi,
det er vi som bør snakke sammen» og at det
er det man bør gå å diskutere i detalj.
Kombinasjonen av de semi-styrte møtene og
de som bare oppstod synes jeg var viktige"
(scrum master og utvikler)
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," https://arxiv.org/abs/1801.08764
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, 2018. http://rdcu.be/tcT3

Hva har IT-bransjen lært?
■ Iterativ utvikling fungerer både i liten og stor skala
■ Store prosjekter:
■ “Tradisjonell” overbygning
■ Smidige metoder for teamene
■ Matrise-organisering
■ Samlokalisering
■ Koordinering av kunnjskapsarbeid
■ Planlagte møter i starten
■ Tilrettelegg for uformelle møter og individuell
koordinering

Les mer
Studie tilgjengelig som open access:
http://rdcu.be/tcT3
”Forskning viser at” i Dagens Næringsliv, 28.
Juli 2017.

Følg forskningsprosjektet Agile 2.0
https://www.researchgate.net/project/Agile-20
http://www.cw.no/artikkel/utvikling-metode/forskningsprosjektet-agile-20

Organisering av digitale prosjekt: Hva har IT-bransjen lært om store prosjekter?

Recommended

Recommended

More Related Content

Similar to Organisering av digitale prosjekt: Hva har IT-bransjen lært om store prosjekter?

Similar to Organisering av digitale prosjekt: Hva har IT-bransjen lært om store prosjekter? (20)

Recently uploaded

Recently uploaded (20)

Organisering av digitale prosjekt: Hva har IT-bransjen lært om store prosjekter?