-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathTeam-Topologies-references-BibTeX.bib
3008 lines (2790 loc) · 243 KB
/
Team-Topologies-references-BibTeX.bib
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
@article{sosa_misalignment_2004,
title = {The {Misalignment} of {Product} {Architecture} and {Organizational} {Structure} in {Complex} {Product} {Development}},
volume = {50},
issn = {0025-1909},
url = {https://pubsonline.informs.org/doi/abs/10.1287/mnsc.1040.0289},
doi = {10.1287/mnsc.1040.0289},
abstract = {Product architecture knowledge is typically embedded in the communication patterns of established development organizations. While this enables the development of products using the existing architecture, it hinders the organization's ability to implement novel architectures, especially for complex products. Structured methods addressing this issue are lacking, as previous research has studied complex product development from two separate perspectives: product architecture and organizational structure. Our research integrates these viewpoints with a structured approach to study how design interfaces in the product architecture map onto communication patterns within the development organization. We investigate how organizational and system boundaries, design interface strength, indirect interactions, and system modularity impact the alignment of design interfaces and team interactions. We hypothesize and test how these factors explain the existence of the following cases: (1) known design interfaces not addressed by team interactions, and (2) observed team interactions not predicted by design interfaces. Our results offer important insights to managers dealing with interdependences across organizational and functional boundaries. In particular, we show how boundary effects moderate the impact of design interface strength and indirect team interactions, and are contingent on system modularity. The research uses data collected from a large commercial aircraft engine development process.},
number = {12},
urldate = {2018-11-03},
journal = {Management Science},
author = {Sosa, Manuel E. and Eppinger, Steven D. and Rowles, Craig M.},
month = dec,
year = {2004},
keywords = {TT refs},
pages = {1674--1689},
file = {Sosa et al. - 2004 - The Misalignment of Product Architecture and Organ.pdf:C\:\\Users\\matth\\Zotero\\storage\\LFX4UP2D\\Sosa et al. - 2004 - The Misalignment of Product Architecture and Organ.pdf:application/pdf;Snapshot:C\:\\Users\\matth\\Zotero\\storage\\HX3KUJAM\\mnsc.1040.html:text/html},
}
@book{mcchrystal_team_2015,
address = {New York, NY},
title = {Team of {Teams}: {New} {Rules} of {Engagement} for a {Complex} {World}},
isbn = {978-0-241-25083-9},
shorttitle = {Team of {Teams}},
abstract = {As commander of Joint Special Operations Command (JSOC), General Stanley McChrystal discarded a century of management wisdom and pivoted from a pursuit of mechanical efficiency to organic adaptability. In this book, he shows how any organization can make the same transition to act like a team of teams - where small groups combine the freedom to experiment with a relentless drive to share their experience.Drawing on a wealth of evidence from his military career and sources as diverse as hospital emergency rooms and NASA's space program, McChrystal frames the existential challenge facing today's organizations, and presents a compelling, effective solution.},
language = {English},
publisher = {Portfolio Penguin},
author = {McChrystal, General Stanley and Silverman, David and Collins, Tantum and Fussell, Chris},
month = nov,
year = {2015},
keywords = {TT refs},
}
@article{dunbar_neocortex_1992,
title = {Neocortex size as a constraint on group size in primates},
volume = {22},
issn = {0047-2484},
url = {http://www.sciencedirect.com/science/article/pii/004724849290081J},
doi = {10.1016/0047-2484(92)90081-J},
abstract = {Two general kinds of theory (one ecological and one social) have been advanced to explain the fact that primates have larger brains and greater congnitive abilities than other animals. Data on neocortex volume, group size and a number of behavioural ecology variables are used to test between the various theories. Group size is found to be a function of relative neocortical volume, but the ecological variables are not. This is interpreted as evidence in favour of the social intellect theory and against the ecological theories. It is suggested that the number of neocortical neurons limits the organism's information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group's size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time. The data suggest that the information overload occurs in terms of the structure of relationships within tightly bonded grooming cliques rather than in terms of the total number of dyads within the group as a whole that an individual has to monitor. It thus appears that, among primates, large groups are created by welding together sets of smaller grooming cliques. One implication of these results is that, since the actual group size will be determined by the ecological characteristics of the habitat in any given case, species will only be able to invade habitats that require larger groups than their current limit if they evolve larger neocortices.},
number = {6},
urldate = {2018-11-02},
journal = {Journal of Human Evolution},
author = {Dunbar, R. I. M.},
month = jun,
year = {1992},
keywords = {behavioural ecology, body size, brain size, grooming, social intellect, TT refs},
pages = {469--493},
file = {ScienceDirect Snapshot:C\:\\Users\\matth\\Zotero\\storage\\DBXXV44R\\004724849290081J.html:text/html},
}
@misc{casella_improving_2016,
title = {Improving {Team} {Productivity} by {Reducing} {Context} {Switching} {\textbar} {LinkedIn}},
url = {https://www.linkedin.com/pulse/improving-team-productivity-reducing-context-karen-casella/},
urldate = {2017-10-09},
journal = {LinkedIn Pulse},
author = {Casella, Karen},
month = oct,
year = {2016},
keywords = {TT refs},
file = {Improving Team Productivity by Reducing Context Switching | LinkedIn:C\:\\Users\\matth\\Zotero\\storage\\NSUUWJMW\\improving-team-productivity-reducing-context-karen-casella.html:text/html},
}
@misc{skelton_icebreaker_2012,
title = {Icebreaker for {Agile} {Retrospectives} – {Empathy} {Snap}},
url = {http://empathysnap.com/},
abstract = {I was invited by one of our London dev teams to facilitate their retrospective yesterday. I’m far from an expert in facilitating retros, although I enjoy it, and I find that I learn a huge amount f…},
language = {en},
urldate = {2018-10-30},
journal = {Matthew Skelton},
author = {Skelton, Matthew},
month = nov,
year = {2012},
note = {https://blog.matthewskelton.net/2012/11/15/icebreaker-for-agile-retrospectives-empathy-snap/},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\3WUB82YS\\icebreaker-for-agile-retrospectives-empathy-snap.html:text/html},
}
@misc{kelly_conways_2013,
title = {Conway's {Law} v. {Software} {Architecture}},
url = {https://dzone.com/articles/conways-law-v-software},
abstract = {I've written about Conway's Law before (Return to Conway’s Law (2006) and a Focus Group I ran at EuroPLoP “What do we think of Conway’s Law Now?”) But I make no...},
language = {en},
urldate = {2018-10-30},
journal = {dzone.com},
author = {Kelly, Allan},
month = mar,
year = {2013},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\LXVJPATG\\conways-law-v-software.html:text/html},
}
@misc{neumark_devops_2015,
title = {{DevOps} \& {Product} {Teams} - {Win} or {Fail}?},
url = {https://www.infoq.com/articles/devops-product-teams},
abstract = {Peter Neumark found a new world when he moved from a DevOps infrastructure team to a Lean product team.How to experiment frequently while keeping operational performance? Platform teams to the rescue!},
urldate = {2016-08-11},
journal = {InfoQ},
author = {Neumark, Peter},
month = jun,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\XFCDAPW2\\devops-product-teams.html:text/html},
}
@misc{snowden_rule_2006,
title = {The rule of 5,15 \& 150},
url = {http://cognitive-edge.com/blog/logn-0-093-3-389-logcr-1-r20-764-t3410-35-p0-001/},
abstract = {Recognise it? Well of course, it’s the best-fit reduced major axis regression equation between neocortex…},
urldate = {2016-08-11},
journal = {Cognitive Edge},
author = {Snowden, Dave},
month = dec,
year = {2006},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\SWFX2CGN\\logn-0-093-3-389-logcr-1-r20-764-t3410-35-p0-001.html:text/html},
}
@misc{ingles_convergence_2018,
title = {Convergence to {Kubernetes}},
url = {https://medium.com/@pingles/convergence-to-kubernetes-137ffa7ea2bc},
abstract = {Standardisation to Scale},
urldate = {2018-10-29},
journal = {Paul Ingles},
author = {Ingles, Paul},
month = jun,
year = {2018},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\Q3NGIXLX\\convergence-to-kubernetes-137ffa7ea2bc.html:text/html},
}
@book{humble_continuous_2010,
address = {Upper Saddle River, NJ},
edition = {01 edition},
title = {Continuous {Delivery}: {Reliable} {Software} {Releases} through {Build}, {Test}, and {Deployment} {Automation}},
isbn = {978-0-321-60191-9},
shorttitle = {Continuous {Delivery}},
abstract = {Winner of the 2011 Jolt Excellence Award!Getting software released to users is often a painful, risky, and time-consuming process.This groundbreaking new book sets out the principles and technical practices that enablerapid, incremental delivery of high quality, valuable new functionality to users. Throughautomation of the build, deployment, and testing process, and improved collaboration betweendevelopers, testers, and operations, delivery teams can get changes released in a matter of hours―sometimes even minutes–no matter what the size of a project or the complexity of its code base. Jez Humble and David Farley begin by presenting the foundations of a rapid, reliable, low-riskdelivery process. Next, they introduce the “deployment pipeline,” an automated process formanaging all changes, from check-in to release. Finally, they discuss the “ecosystem” needed tosupport continuous delivery, from infrastructure, data and configuration management to governance. The authors introduce state-of-the-art techniques, including automated infrastructure managementand data migration, and the use of virtualization. For each, they review key issues, identify bestpractices, and demonstrate how to mitigate risks. Coverage includes • Automating all facets of building, integrating, testing, and deploying software• Implementing deployment pipelines at team and organizational levels• Improving collaboration between developers, testers, and operations• Developing features incrementally on large and distributed teams• Implementing an effective configuration management strategy• Automating acceptance testing, from analysis to implementation• Testing capacity and other non-functional requirements• Implementing continuous deployment and zero-downtime releases• Managing infrastructure, data, components and dependencies• Navigating risk management, compliance, and auditing Whether you’re a developer, systems administrator, tester, or manager, this book will help yourorganization move from idea to release faster than ever―so you can deliver value to your businessrapidly and reliably.},
language = {English},
publisher = {Addison Wesley},
author = {Humble, Jez and Farley, David},
month = jul,
year = {2010},
keywords = {TT refs},
}
@book{humble_lean_2015,
address = {Beijing},
edition = {1 edition},
title = {Lean {Enterprise}: {How} {High} {Performance} {Organizations} {Innovate} at {Scale}},
isbn = {978-1-4493-6842-5},
shorttitle = {Lean {Enterprise}},
abstract = {How well does your organization respond to changing market conditions, customer needs, and emerging technologies when building software-based products? This practical guide presents Lean and Agile principles and patterns to help you move fast at scale—and demonstrates why and how to apply these methodologies throughout your organization, rather than with just one department or team.Through case studies, you’ll learn how successful enterprises have rethought everything from governance and financial management to systems architecture and organizational culture in the pursuit of radically improved performance. Adopting Lean will take time and commitment, but it’s vital for harnessing the cultural and technical forces that are accelerating the rate of innovation.Discover how Lean focuses on people and teamwork at every level, in contrast to traditional management practicesApproach problem-solving experimentally, by exploring solutions, testing assumptions, and getting feedback from real usersLead and manage large-scale programs in a way that empowers employees, increases the speed and quality of delivery, and lowers costsLearn how to implement ideas from the DevOps and Lean Startup movements even in complex, regulated environments},
language = {English},
publisher = {O'Reilly Media},
author = {Humble, Jez and Molesky, Joanne and O'Reilly, Barry},
month = jan,
year = {2015},
keywords = {TT refs},
}
@misc{skelton_your_2018,
type = {Tweet},
title = {Your team's {API} includes: - code: {REST} endpoints, libraries, clients, {UI}, etc. - wiki / docs - especially "{How} {To}" guides - your approach to team chat tools ({Slack}/{Hipchat}) - anything else which other teams need to use to interact with your team {It}'s not just about code. \#{DevEx}},
url = {https://twitter.com/matthewpskelton/status/1022111880423395329},
language = {en},
urldate = {2018-10-29},
journal = {@matthewpskelton},
author = {Skelton, Matthew},
month = jul,
year = {2018},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\LNZMUFKB\\1022111880423395329.html:text/html},
}
@misc{cottmeyer_things_2014,
title = {Things to {Consider} {When} {Structuring} {Your} {Agile} {Enterprise}},
url = {https://www.leadingagile.com/2014/02/structure-agile-enterprise/},
abstract = {There are a lot of unique challenges that large organizations face when hey are trying to form Agile Teams. In this post, Mike Cottmeyer breaks down the ins and outs of Agile organizational structure.},
language = {en-US},
urldate = {2018-10-29},
journal = {LeadingAgile},
author = {Cottmeyer, Mike},
month = feb,
year = {2014},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\337AQ9GA\\structure-agile-enterprise.html:text/html},
}
@misc{shibata_how_2018,
title = {How to build a platform team now! the secrets to successful engineering},
url = {https://hackernoon.com/how-to-build-a-platform-team-now-the-secrets-to-successful-engineering-8a9b6a4d2c8},
abstract = {TLDR; Scaling teams are hard. A platform team done right can help ease the hardships.},
urldate = {2018-10-29},
journal = {Hacker Noon},
author = {Shibata, Kenichi},
month = sep,
year = {2018},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\9DYTS98U\\how-to-build-a-platform-team-now-the-secrets-to-successful-engineering-8a9b6a4d2c8.html:text/html},
}
@book{perri_escaping_2018,
address = {S.l.},
edition = {1 edition},
title = {Escaping the {Build} {Trap}},
isbn = {978-1-4919-7379-0},
abstract = {To remain innovative in today's market, companies have to adopt a culture of learning and customer-centric practices that are focused on outcomes rather than outputs. This book provides product managers with a practical process that focuses on finding opportunities to solve customer problems and achieve business goals. Author Melissa Perri provides a toolbox of product management principles that can be applied to any company, big or small. By understanding the secrets to communicating and collaborating within a company structure, you'll learn how to overcome product development roadblocks and build products that benefit both the business and the customer.},
language = {English},
publisher = {O′Reilly},
author = {Perri, Melissa},
month = nov,
year = {2018},
keywords = {TT refs},
}
@misc{marshall_team_2018,
type = {Tweet},
title = {A team is not a group of people who work together. {A} team is a group of people who each put the team before themselves.},
url = {https://twitter.com/flowchainsensei/status/1056838136574152704},
language = {en},
urldate = {2018-10-29},
journal = {@flowchainsensei},
author = {Marshall, Bob},
month = oct,
year = {2018},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\VQT2LZHI\\1056838136574152704.html:text/html},
}
@book{karlgaard_team_2015,
address = {New York, NY},
title = {Team {Genius}: {The} {New} {Science} of {High}-{Performing} {Organizations}},
isbn = {978-0-06-230254-0},
shorttitle = {Team {Genius}},
abstract = {A groundbreaking book that sheds new light on the vital importance of teams as the fundamental unit of organization and competition in the global economy.Teams—we depend on them for both our professional success and our personal happiness. But isn't it odd how little scrutiny we give them? The teams that make up our lives are created mostly by luck, happenstance, or circumstance—but rarely by design. In trivial matters—say, a bowling team, the leadership of a neighborhood group, or a holiday party committee—success by serendipity is already risky enough. But when it comes to actions by fast-moving start-ups, major corporations, nonprofit institutions, and governments, leaving things to chance can be downright dangerous.Offering vivid reports of the latest scientific research, compelling case studies, and great storytelling, Team Genius shows managers and executives that the planning, design, and management of great teams no longer have to be a black art. It explores solutions to essential questions that could spell the difference between success and obsolescence. Do you know how to reorganize your subpar teams to turn them into top performers? Can you identify which of the top-performing teams in your company are reaching the end of their life span? Do you have the courage to shut them down? Do you know how to create a replacement team that will be just as effective—without losing time or damaging morale? And, most important, are your teams the right size for the job?Throughout, Rich Karlgaard and Michael S. Malone share insights and real-life examples gleaned from their careers as journalists, analysts, investors, and globetrotting entrepreneurs, meeting successful teams and team leaders to reveal some "new truths": The right team size is usually one fewer person than what managers think they need. The greatest question facing good teams is not how to succeed, but how to die. Good "chemistry" often makes for the least effective teams. Cognitive diversity yields the highest performance gains—but only if you understand what it is. How to find the "bliss point" in team intimacy—and become three times more productive. How to identify destructive team members before they do harm. Why small teams are 40 percent more likely to create a successful breakthrough than a solo genius is. Why groups of 7 (± 2), 150, and 1,500 are magic sizes for teams.Eye-opening, grounded, and essential, Team Genius is the next big idea to revolutionize business.},
language = {English},
publisher = {HarperBusiness},
author = {Karlgaard, Rich and Malone, Michael S.},
month = aug,
year = {2015},
keywords = {TT refs},
}
@book{burgess_thinking_2015,
address = {Sebastopol, California},
edition = {1 edition},
title = {Thinking in {Promises}},
isbn = {978-1-4919-1787-9},
abstract = {Imagine a set of simple principles that could help you to understand how parts combine to become a whole, and how each part sees the whole from its own perspective. If such principles were any good, it shouldn’t matter whether we’re talking about humans on a team, birds in a flock, computers in a datacenter, or cogs in a Swiss watch. A theory of cooperation ought to be pretty universal, so we should be able to apply it both to technology and to the workplace.Such principles are the subject of Promise Theory, and the focus of this insightful book. The goal of Promise Theory is to reveal the behavior of a whole from the sum of its parts, taking the viewpoint of the parts rather than the whole. In other words, it is a bottom-up, constructionist view of the world. Start Thinking in Promises and find out why this discipline works for documenting system behaviors from the bottom-up.},
language = {English},
publisher = {O'Reilly Media},
author = {Burgess, Mark},
month = jul,
year = {2015},
keywords = {TT refs},
}
@book{narayan_agile_2015,
address = {New York},
edition = {01 edition},
title = {Agile {IT} {Organization} {Design}: {For} {Digital} {Transformation} and {Continuous} {Delivery}},
isbn = {978-0-13-390335-5},
shorttitle = {Agile {IT} {Organization} {Design}},
abstract = {Design IT Organizations for Agility at Scale Aspiring digital businesses need overall IT agility, not just development team agility. In Agile IT Organization Design, IT management consultant and ThoughtWorks veteran Sriram Narayan shows how to infuse agility throughout your organization. Drawing on more than fifteen years’ experience working with enterprise clients in IT-intensive industries, he introduces an agile approach to “Business–IT Effectiveness” that is as practical as it is valuable. The author shows how structural, political, operational, and cultural facets of organization design influence overall IT agility—and how you can promote better collaboration across diverse functions, from sales and marketing to product development, and engineering to IT operations. Through real examples, he helps you evaluate and improve organization designs that enhance autonomy, mastery, and purpose: the key ingredients for a highly motivated workforce. You’ll find “close range” coverage of team design, accountability, alignment, project finance, tooling, metrics, organizational norms, communication, and culture. For each, you’ll gain a deeper understanding of where your organization stands, and clear direction for making improvements. Ready to optimize the performance of your IT organization or digital business? Here are practical solutions for the long term, and for right now. Govern for value over predictability Organize for responsiveness, not lowest cost Clarify accountability for outcomes and for decisions along the way Strengthen the alignment of autonomous teams Move beyond project teams to capability teams Break down tool-induced silos Choose financial practices that are free of harmful side effects Create and retain great teams despite today’s “talent crunch” Reform metrics to promote (not prevent) agility Evolve culture through improvements to structure, practices, and leadership—and careful, deliberate interventions},
language = {English},
publisher = {Addison-Wesley Professional},
author = {Narayan, Sriram},
month = jun,
year = {2015},
keywords = {TT refs},
}
@misc{urquhart_communications_2016,
title = {Communications and {Conway}’s {Law}},
url = {https://medium.com/digital-anatomy/communications-and-conways-law-6a1a9deae32},
abstract = {In my last post, I described what I see as a disruption in the way digital businesses will operate in the future:},
urldate = {2018-10-27},
journal = {Digital Anatomy},
author = {Urquhart, James},
month = sep,
year = {2016},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\P5SAHF4I\\communications-and-conways-law-6a1a9deae32.html:text/html},
}
@article{urquhart_it_2010,
title = {{IT} operations in a cloudy world},
url = {https://www.cnet.com/news/it-operations-in-a-cloudy-world/},
abstract = {Understanding how cloud computing and data center virtualization are forcing change in IT operations is important to understanding how to take advantage of cloud's disruptive nature.},
language = {en},
urldate = {2018-10-27},
journal = {CNET},
author = {Urquhart, James},
month = sep,
year = {2010},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\S6PI5EAQ\\it-operations-in-a-cloudy-world.html:text/html},
}
@book{dunbar_how_2010,
address = {London},
edition = {Main edition},
title = {How {Many} {Friends} {Does} {One} {Person} {Need}?: {Dunbar}'s {Number} and {Other} {Evolutionary} {Quirks}},
isbn = {978-0-571-25342-5},
shorttitle = {How {Many} {Friends} {Does} {One} {Person} {Need}?},
abstract = {We are the product of our evolutionary history and this history colours our everyday lives - from why we kiss to how religious we are. In How Many Friends Does One Person Need? Robin Dunbar explains how the distant past underpins our current behaviour, through the groundbreaking experiments that have changed the thinking of evolutionary biologists forever. He explains phenomena such as why 'Dunbar's Number' (150) is the maximum number of acquaintances you can have, why all babies are born premature and the science behind lonely hearts columns. Stimulating, provocative and highly enjoyable, this fascinating book is essential for understanding why humans behave as they do - what it is to be human.},
language = {English},
publisher = {Faber \& Faber},
author = {Dunbar, Professor Robin},
month = feb,
year = {2010},
keywords = {TT refs},
}
@misc{wastell_what_2018,
title = {What we mean when we talk about service design at the {Co}-op},
url = {https://digitalblog.coop.co.uk/2018/10/25/what-we-mean-when-we-talk-about-service-design-at-the-co-op/},
abstract = {I wanted to write this post to explain what service design is at the Co-op. Service design helps build more inclusive teams as well as products and services that meet user and business needs. What …},
language = {en},
urldate = {2018-10-26},
journal = {Co-op Digital Blog},
author = {Wastell, Katherine},
month = oct,
year = {2018},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\FV9LB3CI\\what-we-mean-when-we-talk-about-service-design-at-the-co-op.html:text/html},
}
@misc{hall_itsm_2016,
title = {{ITSM}, {DevOps}, and why three-tier support should be replaced with {Swarming}.},
url = {https://medium.com/@JonHall_/itsm-devops-and-why-the-three-tier-structure-must-be-replaced-with-swarming-91e76ba22304},
abstract = {The 3-tier support structure is ubiquitous in ITSM, but it is fundamentally at odds with DevOps principles. Swarming is a better answer.},
urldate = {2018-10-26},
journal = {Medium},
author = {Hall, Jon},
month = dec,
year = {2016},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\42HW7BFA\\itsm-devops-and-why-the-three-tier-structure-must-be-replaced-with-swarming-91e76ba22304.html:text/html},
}
@misc{kitson_squad_2017,
title = {Squad {Health} {Checks}},
url = {https://technology.skybettingandgaming.com/2017/02/01/squad-health-checks/},
abstract = {Enabling Continuous Improvement through regular introspection by the teams themselves.},
urldate = {2018-10-26},
journal = {Sky Betting \& Gaming Technology Blog},
author = {Kitson, Jon},
month = feb,
year = {2017},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\VTL5ZZEK\\squad-health-checks.html:text/html},
}
@misc{overeem_how_2015,
title = {How {I} {Used} the {Spotify} {Squad} {Health} {Check} {Model} – {Barry} {Overeem} – {The} {Liberators}},
url = {http://www.barryovereem.com/how-i-used-the-spotify-squad-health-check-model/},
language = {en-US},
urldate = {2018-10-26},
author = {Overeem, Barry},
month = aug,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\VCL7UFWI\\how-i-used-the-spotify-squad-health-check-model.html:text/html},
}
@misc{kniberg_squad_2014,
title = {Squad {Health} {Check} model – visualizing what to improve},
url = {https://labs.spotify.com/2014/09/16/squad-health-check-model/},
abstract = {(Download the cards \& instructions as PDF or PPTX) (Translations of this article: Chinese, French) What is a squad health check model? A lot of companies experiment with ways of measuring and visualizing how their teams are doing. They’re usually called “maturity models”, and involve some sort of progression through different levels. The intent of these…},
language = {en},
urldate = {2018-10-26},
journal = {Labs},
author = {Kniberg, Henrik},
month = sep,
year = {2014},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\AY6BREM7\\squad-health-check-model.html:text/html},
}
@book{davies_agile_2009,
address = {Raleigh, N.C},
edition = {1 edition},
title = {Agile {Coaching}},
isbn = {978-1-934356-43-2},
abstract = {Discover how to coach your team to become more Agile. Agile Coaching de-mystifies agile practices--it's a practical guide to creating strong agile teams. Packed with useful tips from practicing agile coaches Rachel Davies and Liz Sedley, this book gives you coaching tools that you can apply whether you are a project manager, a technical lead, or working in a software team.To lead change, you need to expand your toolkit, and this book gives you the tools you need to make the transition from agile practitioner to agile coach. Agile Coaching is all about working with people to create great agile teams. You'll learn how to build a team that produces great software and has fun doing it. In the process, you'll grow a team that's self-sufficient and skillful.This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software. You'll find chapters dedicated to introducing Test-Driven Development, designing Retrospectives, and making progress visible. Find out what works and what to avoid when introducing agile practices to your team. Throughout the book the authors share their personal coaching stories from experience with real teams, giving you insights into what works and what to avoid. Each chapter also covers hurdles that you and your team may face and what to do to clear them.},
language = {English},
publisher = {Pragmatic Bookshelf},
author = {Davies, Rachel and Sedley, Liz},
month = sep,
year = {2009},
keywords = {TT refs},
}
@book{adkins_coaching_2010,
address = {Upper Saddle River, NJ},
edition = {01 edition},
title = {Coaching {Agile} {Teams}: {A} {Companion} for {ScrumMasters}, {Agile} {Coaches}, and {Project} {Managers} in {Transition}},
isbn = {978-0-321-63770-3},
shorttitle = {Coaching {Agile} {Teams}},
abstract = {The Provocative and Practical Guide to Coaching Agile Teams As an agile coach, you can help project teams become outstanding at agile, creating products that make them proud and helping organizations reap the powerful benefits of teams that deliver both innovation and excellence. More and more frequently, ScrumMasters and project managers are being asked to coach agile teams. But it’s a challenging role. It requires new skills―as well as a subtle understanding of when to step in and when to step back. Migrating from “command and control” to agile coaching requires a whole new mind-set. In Coaching Agile Teams, Lyssa Adkins gives agile coaches the insights they need to adopt this new mind-set and to guide teams to extraordinary performance in a re-energized work environment. You’ll gain a deep view into the role of the agile coach, discover what works and what doesn’t, and learn how to adapt powerful skills from many allied disciplines, including the fields of professional coaching and mentoring. Coverage includesUnderstanding what it takes to be a great agile coach Mastering all of the agile coach’s roles: teacher, mentor, problem solver, conflict navigator, and performance coach Creating an environment where self-organized, high-performance teams can emerge Coaching teams past cooperation and into full collaboration Evolving your leadership style as your team grows and changes Staying actively engaged without dominating your team and stunting its growth Recognizing failure, recovery, and success modes in your coaching Getting the most out of your own personal agile coaching journey Whether you’re an agile coach, leader, trainer, mentor, facilitator, ScrumMaster, project manager, product owner, or team member, this book will help you become skilled at helping others become truly great. What could possibly be more rewarding?},
language = {English},
publisher = {Addison-Wesley Professional},
author = {Adkins, Lyssa},
month = may,
year = {2010},
keywords = {TT refs},
}
@book{skelton_tech_2018,
address = {Leeds, UK},
edition = {1},
title = {Tech {Talks} for {Beginners}},
isbn = {978-1-912058-85-3},
publisher = {Conflux Digital},
author = {Skelton, Matthew},
year = {2018},
keywords = {TT refs},
}
@book{morgan-smith_internal_2019,
address = {Leeds, UK},
edition = {1},
title = {Internal {Tech} {Conferences}},
isbn = {978-1-912058-97-6},
publisher = {Conflux Digital},
author = {Morgan-Smith, Victoria and Skelton, Matthew},
year = {2019},
keywords = {TT refs},
}
@misc{kitagawa_platforms_2018,
title = {Platforms at {Twilio}: {Unlocking} {Developer} {Effectiveness}},
shorttitle = {Platforms at {Twilio}},
url = {https://www.infoq.com/presentations/twilio-devops},
abstract = {Justin Kitagawa talks about Twilio’s DevOps culture of “You build it, you run it”, and how its internal Platform has evolved to reduce their engineer’s cognitive load by providing a unified self-service, declarative platform to build, deliver, and run the thousands of global microservices that make up Twilio. He discusses the evolution, tenets, and lessons learned of Twilio’s internal Platform.},
urldate = {2018-10-24},
author = {Kitagawa, Justin},
month = oct,
year = {2018},
keywords = {TT refs},
file = {Kitagawa - 2018 - Platforms at Twilio Unlocking Developer Effective.pdf:C\:\\Users\\matth\\Zotero\\storage\\XGL6886I\\Kitagawa - 2018 - Platforms at Twilio Unlocking Developer Effective.pdf:application/pdf},
}
@book{rother_toyota_2009,
address = {New York},
edition = {1 edition},
title = {Toyota {Kata}: {Managing} {People} for {Improvement}, {Adaptiveness} and {Superior} {Results}},
isbn = {978-0-07-163523-3},
shorttitle = {Toyota {Kata}},
abstract = {"Toyota Kata gets to the essence of how Toyota manages continuous improvement and human ingenuity, through its improvement kata and coaching kata. Mike Rother explains why typical companies fail to understand the core of lean and make limited progress―and what it takes to make it a real part of your culture."―Jeffrey K. Liker, bestselling author of The Toyota Way"[Toyota Kata is] one of the stepping stones that will usher in a new era of management thinking."―The Systems Thinker"How any organization in any industry can progress from old-fashioned management by results to a strikingly different and better way."―James P. Womack, Chairman and Founder, Lean Enterprise Institute"Practicing the improvement kata is perhaps the best way we've found so far for actualizing PDCA in an organization."―John Shook, Chairman and CEO, Lean Enterprise InstituteThis game-changing book puts you behind the curtain at Toyota, providing new insight into the legendary automaker's management practices and offering practical guidance for leading and developing people in a way that makes the best use of their brainpower.Drawing on six years of research into Toyota's employee-management routines, Toyota Kata examines and elucidates, for the first time, the company's organizational routines--called kata--that power its success with continuous improvement and adaptation. The book also reaches beyond Toyota to explain issues of human behavior in organizations and provide specific answers to questions such as:How can we make improvement and adaptation part of everyday work throughout the organization?How can we develop and utilize the capability of everyone in the organization to repeatedly work toward and achieve new levels of performance?How can we give an organization the power to handle dynamic, unpredictable situations and keep satisfying customers? Mike Rother explains how to improve our prevailing management approach through the use of two kata: Improvement Kata--a repeating routine of establishing challenging target conditions, working step-by-step through obstacles, and always learning from the problems we encounter; and Coaching Kata: a pattern of teaching the improvement kata to employees at every level to ensure it motivates their ways of thinking and acting.With clear detail, an abundance of practical examples, and a cohesive explanation from start to finish, Toyota Kata gives executives and managers at any level actionable routines of thought and behavior that produce superior results and sustained competitive advantage.},
language = {English},
publisher = {McGraw-Hill Education},
author = {Rother, Mike},
month = oct,
year = {2009},
keywords = {TT refs},
}
@misc{pivotal_microservices:_2016,
type = {Technology},
title = {Microservices: {Organizing} {Large} {Teams} for {Rapid} {Delivery}},
shorttitle = {Microservices},
url = {https://www.slideshare.net/Pivotal/microservices-organizing-large-teams-for-rapid-delivery},
abstract = {SpringOne Platform 2016
Speakers: Patricia Anderson; Senior Consultant, Credera. Micah Blalock; Senior Architect, Credera. Jason Goth; Principal Architect, Credera.
A microservice architecture is pattern that is most commonly associated with larger organizations where services and teams are organized around separate business capabilities. In a project our team recently completed, we used a microservice architecture to allow us to organize a large team to develop a large analytics platform at speeds that would not have been possible using a more typical service-oriented architecture.
In this session, we discuss the organizational structure and communication and development strategies and tools to allow teams to work in parallel without drowning in process overhead and coordination costs.},
urldate = {2018-10-19},
author = {Pivotal},
year = {2016},
keywords = {TT refs},
}
@book{forsgren_accelerate:_2018,
address = {Portland, Oregon},
title = {Accelerate: {The} {Science} of {Lean} {Software} and {Devops}: {Building} and {Scaling} {High} {Performing} {Technology} {Organizations}},
isbn = {978-1-942788-33-1},
shorttitle = {Accelerate},
abstract = {Accelerate your organization to win in the marketplace. How can we apply technology to drive business value? For years, we've been told that the performance of software delivery teams doesn't matter that it can't provide a competitive advantage to our companies. Through four years of groundbreaking research, Dr. Nicole Forsgren, Jez Humble, and Gene Kim set out to find a way to measure software delivery performance and what drives it using rigorous statistical methods. This book presents both the findings and the science behind that research, making the information accessible for readers to apply in their own organizations. Readers will discover how to measure the performance of their teams, and what capabilities they should invest in to drive higher performance. This book is ideal for management at every level.},
language = {English},
publisher = {Trade Select},
author = {Forsgren, Nicole and Humble, Jez},
month = apr,
year = {2018},
keywords = {TT refs},
}
@book{roberts_modern_2007,
address = {Oxford},
title = {The {Modern} {Firm}: {Organizational} {Design} for {Performance} and {Growth}},
isbn = {978-0-19-829375-0},
shorttitle = {The {Modern} {Firm}},
abstract = {Business firms around the world are experimenting with new organizational designs, changing their formal architectures, their routines and processes, and their corporate cultures as they seek to improve their current performance and their growth prospects. In the process they are changing the scope of their business operations, redrawing their organization charts, redefining the allocation of decision-making authority and responsibility, revamping the mechanisms for motivating and rewarding people, reconsidering which activities to conduct in-house and which to out-source, redesigning their information systems, and seeking to alter the shared beliefs, values and norms that their people hold. In this book, John Roberts argues that there are predictable, necessary relationships among these changes that will improve performance and growth. The organizations that are successful will establish patterns of fit among the elements of their organizational designs, their competitive strategies and the external environment in which they operate and will go about this in a holistic manner. The Modern Firm develops powerful conceptual frameworks for analyzing the interrelations between organizational design features, competitive strategy and the business environment. Written in a non-technical language, the book is nevertheless based on rigorous modeling and draws on numerous examples from eighteenth century fur trading companies to such modern firms such as BP and Nokia. Finally the book explores why these developments are happening now, pointing to the increase in global competition and changes in technology.},
language = {English},
publisher = {Oxford University Press, USA},
author = {Roberts, John},
month = oct,
year = {2007},
keywords = {TT refs},
}
@book{degrandis_making_2017,
address = {Portland, OR},
edition = {1 edition},
title = {Making {Work} {Visible}: {Exposing} {Time} {Theft} to {Optimize} {Workflow}},
isbn = {978-1-942788-15-7},
shorttitle = {Making {Work} {Visible}},
abstract = {If someone stole your wallet, you'd notice it. So why don't people notice when they are robbed of something much more valuable than their wallet--time?Today's workers are drowning: nonstop requests for time, days filled to the brim with meetings, and endless nights spent heroically fixing the latest problems. This churn and burn is creating a workforce constantly on the edge of burnout. In this timely book, IT time management expert Dominica DeGrandis reveals the real crime of the century--time theft, one of the most costly factors impacting enterprises in their day-to-day operations. Through simple solutions that make work visible, DeGrandis helps people round up the five thieves of time and take back their lives with time-saving solutions. Chock-full of exercises, takeaways, real-world examples, colorful diagrams, and an easy-going writing style, readers will quickly learn effective practices to create high-performing workflows within an organization. The technology world--and indeed the whole business world--is moving at a pace faster than ever before, and it shows no signs of slowing down. Instead of consigning ourselves to the pressure cooker of the modern world, it's time to elevate how we work. It's time to level up our game. It's time to make work visible.},
language = {English},
publisher = {IT Revolution Press},
author = {Degrandis, Dominica},
month = nov,
year = {2017},
keywords = {TT refs},
}
@book{stanford_economist_2015,
address = {London},
edition = {2 edition},
title = {The {Economist} {Guide} to {Organisation} {Design} 2nd edition: {Creating} high-performing and adaptable enterprises},
isbn = {978-1-78125-310-6},
shorttitle = {The {Economist} {Guide} to {Organisation} {Design} 2nd edition},
abstract = {Thousands of established businesses fail every year because of the way they are organised, or re-organised. Business survival can depend not only on whether its structures and reporting lines meet the needs of the market, but also whether they can adapt in the face of a rapidly changing business environment. Yet managers seldom talk coherently about structuring or restructuring their operations, let alone take a systematic approach to this vital issue. Too often, companies are restructured for the wrong reasons - for example, because a new CEO wants to make an impact, or to work around a new IT system. This revised and updated Economist Guide shows how leaders should think about and implement the design of a company, using five easy-to-use guiding principles: - Design a company around its strategy and the operating context, not for ulterior or non-business reasons; - Think holistically - don't restructure just one division without taking into account other operations;- Consider future markets, customers and trends, not just what works best now;- Invest time and resources: - a redesign can be complicated to implement and must be done without disrupting daily activities; and - Go back to the basics of how the company operates and its market position; this is not a repair job to fix a short-term problem.},
language = {English},
publisher = {Economist Books},
author = {Stanford, Naomi},
month = feb,
year = {2015},
keywords = {TT refs},
}
@misc{it_revolution_devops_2018,
title = {{DevOps} {Over} {Coffee} - {Adidas}},
url = {https://www.youtube.com/watch?v=oOjdXeGp44E&feature=youtu.be&t=1071},
urldate = {2018-10-16},
author = {{IT Revolution}},
month = jul,
year = {2018},
keywords = {adidas, devops, devops enterprise summit, devops training, devops tutorial, does18, does18 london, does18 uk, enterprise, fernando cornago, london, markus rautert, summit, TT refs, uk, what is devops},
}
@misc{humble_theres_2012,
title = {There's {No} {Such} {Thing} as a "{Devops} {Team}" - {Continuous} {Delivery}},
url = {https://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/},
urldate = {2018-10-15},
journal = {Continuous Delivery},
author = {Humble, Jez},
month = oct,
year = {2012},
keywords = {TT refs},
file = {There's No Such Thing as a "Devops Team" - Continuous Delivery:C\:\\Users\\matth\\Zotero\\storage\\UC6XPKB2\\theres-no-such-thing-as-a-devops-team.html:text/html},
}
@misc{mihaljov_having_2017,
type = {Tweet},
title = {Having a dedicated {DevOps} person who does all the {DevOpsing} is like having a dedicated collaboration person who does all the collaborating.},
url = {https://twitter.com/noidi/status/852879869998501889},
language = {en},
urldate = {2018-10-15},
journal = {@noidi},
author = {Mihaljov, Timo},
month = apr,
year = {2017},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\BKWL4T64\\852879869998501889.html:text/html},
}
@misc{beal_industry_2017,
title = {The {Industry} {Just} {Can}'t {Decide} about {DevOps} {Teams}},
url = {https://www.infoq.com/news/2017/10/devops-teams-good-or-bad},
abstract = {The incidence of DevOps teams is on the rise according to reports, but the industry remains divided on whether a DevOps team should even exist. Some are wary of creating additional silos, or are of the opinion that DevOps is a methodology that everyone should subscribe to in an organisation; others point to DevOps teams as an effective way of transitioning to a new way of working.},
urldate = {2018-10-15},
journal = {InfoQ},
author = {Beal, Helen},
month = oct,
year = {2017},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\FYUNDLSG\\devops-teams-good-or-bad.html:text/html},
}
@misc{munns_chris_2016,
title = {Chris {Munns}, {DevOps} @ {Amazon}: {Microservices}, 2 {Pizza} {Teams}, \& 50 {Mill}…},
shorttitle = {Chris {Munns}, {DevOps} @ {Amazon}},
url = {http://www.slideshare.net/TriNimbus/chris-munns-devops-amazon-microservices-2-pizza-teams-50-million-deploys-a-year},
urldate = {2016-08-12},
author = {Munns, Chris},
month = may,
year = {2016},
keywords = {TT refs},
file = {Munns - 2016 - Chris Munns, DevOps @ Amazon Microservices, 2 Piz.pdf:C\:\\Users\\matth\\Zotero\\storage\\ZDUED6WE\\Munns - 2016 - Chris Munns, DevOps @ Amazon Microservices, 2 Piz.pdf:application/pdf},
}
@book{pink_drive_2011,
address = {Edinburgh},
edition = {Main edition},
title = {Drive},
isbn = {978-1-84767-769-3},
abstract = {A BOOK THAT WILL CHANGE HOW YOU THINK AND TRANSFORM HOW YOU LIVEForget everything you thought you knew about how to motivate people - at work, at school, at home. As Daniel H. Pink explains in this paradigm-shattering book, the true secret to high performance and satisfaction in today's world is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and the world.},
language = {English},
publisher = {Canongate Books Ltd},
author = {Pink, Daniel H.},
month = jan,
year = {2011},
keywords = {TT refs},
}
@misc{pais_prezis_2012,
title = {Prezi's {CTO} on how to remain a lean startup after 4 years},
url = {https://www.infoq.com/news/2012/10/Prezi-lean-startup},
abstract = {Peter Halacsy, CTO of Prezi, spoke today at DevOps Days in Rome about the evolution of the company in the past 3 years as a lean startup. He discussed how embracing failure is the only way to grow and improve the business. These principles affected all aspects of the company, from its structure to people recruitment, responsibility, technology stack and mostly the culture.},
urldate = {2018-10-15},
journal = {InfoQ},
author = {Pais, Manuel},
month = oct,
year = {2012},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\XBSSQZH6\\Prezi-lean-startup.html:text/html},
}
@article{bauernberger_devops_2014,
title = {{DevOps} in {Telecoms} – is it possible?},
url = {http://www.telecomstechnews.com/news/2014/oct/01/devops-telecoms-it-possible/},
abstract = {In telecoms, the adoption of DevOps is much higher than generally believed and it seems most are willing to extend their existing agile methodologies.},
urldate = {2016-07-06},
journal = {Telecom Tech News},
author = {Bauernberger, Joachim},
month = oct,
year = {2014},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\7ZII52A2\\devops-telecoms-it-possible.html:text/html},
}
@misc{netflix_technology_blog_netflix_2011,
title = {The {Netflix} {Simian} {Army}},
url = {https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116},
abstract = {Keeping our cloud safe, secure, and highly available},
urldate = {2018-10-15},
journal = {Netflix TechBlog},
author = {{Netflix Technology Blog}},
month = jul,
year = {2011},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\XZZSL7UH\\the-netflix-simian-army-16e57fbab116.html:text/html},
}
@misc{bryson_architects_2015,
title = {Architects {Should} {Code}: {The} {Architect}'s {Misconception}},
shorttitle = {Architects {Should} {Code}},
url = {https://www.infoq.com/articles/architects-should-code-bryson},
abstract = {The responsibility of an architect reaches far past design and business concerns. Their design's implementation is ultimately their only measure of success; they should get their hands dirty and help.},
urldate = {2018-10-15},
journal = {InfoQ},
author = {Bryson, Brandon},
month = aug,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\TKCX2LFH\\architects-should-code-bryson.html:text/html},
}
@misc{adams_scaling_2015,
title = {Scaling {Product} {Teams}: {How} to {Build} and {Structure} for {Hypergrowth}},
shorttitle = {Scaling {Product} {Teams}},
url = {https://www.intercom.com/blog/how-we-build-software/},
abstract = {There’s been lots written about how Internet businesses should build software, from books like The Lean Start-Up, and posts from...},
language = {en-US},
urldate = {2018-10-15},
journal = {Inside Intercom},
author = {Adams, Paul},
month = jan,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\REPVWSJQ\\how-we-build-software.html:text/html},
}
@article{hastie_interview_2014,
title = {An interview with {Sam} {Guckenheimer} on {Microsoft}'s {Journey} to {Cloud} {Cadence}},
url = {https://www.infoq.com/articles/agile2014-guckenheimer},
abstract = {At the recent Agile 2014 conference Sam Guckenheimer gave the opening keynote on Microsoft Developer Division's transition to a continuous delivery model. After the talk he sat down with InfoQ to discuss what it takes to achieve operational agility and cloud cadence.},
urldate = {2018-10-15},
journal = {InfoQ},
author = {Hastie, Shane},
month = oct,
year = {2014},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\ILDAF4FE\\agile2014-guckenheimer.html:text/html},
}
@misc{kniberg_real-life_2015,
address = {Bangkok},
title = {Real-{Life} {Agile} {Scaling}},
url = {http://blog.crisp.se/wp-content/uploads/2015/11/Real-life-agile-scaling.pdf},
author = {Kniberg, Henrik},
month = nov,
year = {2015},
keywords = {TT refs},
file = {Real-life-agile-scaling.pdf:C\:\\Users\\matth\\Zotero\\storage\\FC76KA3I\\Real-life-agile-scaling.pdf:application/pdf},
}
@misc{innolution_feature_nodate,
title = {Feature {Team} {Definition} {\textbar} {Innolution}},
url = {https://innolution.com/resources/glossary/feature-team},
urldate = {2018-10-14},
author = {{innolution}},
keywords = {TT refs},
file = {Feature Team Definition | Innolution:C\:\\Users\\matth\\Zotero\\storage\\CSL5ASPY\\feature-team.html:text/html},
}
@book{beyer_site_2016,
address = {Beijing ; Boston},
edition = {1 edition},
title = {Site {Reliability} {Engineering}},
isbn = {978-1-4919-2912-4},
abstract = {The overwhelming majority of a software system’s lifespan is spent in use, not in design or implementation. So, why does conventional wisdom insist that software engineers focus primarily on the design and development of large-scale computing systems?In this collection of essays and articles, key members of Google’s Site Reliability Team explain how and why their commitment to the entire lifecycle has enabled the company to successfully build, deploy, monitor, and maintain some of the largest software systems in the world. You’ll learn the principles and practices that enable Google engineers to make systems more scalable, reliable, and efficient—lessons directly applicable to your organization.This book is divided into four sections:Introduction—Learn what site reliability engineering is and why it differs from conventional IT industry practicesPrinciples—Examine the patterns, behaviors, and areas of concern that influence the work of a site reliability engineer (SRE)Practices—Understand the theory and practice of an SRE’s day-to-day work: building and operating large distributed computing systemsManagement—Explore Google's best practices for training, communication, and meetings that your organization can use},
language = {English},
publisher = {O′Reilly},
author = {Beyer, Betsy and Petoff, Jennifer and Jones, Chris and Murphy, Niall Richard},
month = apr,
year = {2016},
keywords = {TT refs},
}
@misc{dogan_sre_2017,
title = {The {SRE} model},
url = {https://medium.com/@rakyll/the-sre-model-6e19376ef986},
abstract = {Cindy Sridharan’s fantastic article on why everyone is not ops makes you rethink of the relationship between your development and…},
urldate = {2018-10-14},
journal = {JBD},
author = {Dogan, Jaana B.},
month = jul,
year = {2017},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\YBCLU3NT\\the-sre-model-6e19376ef986.html:text/html},
}
@misc{rensin_introducing_2016,
title = {Introducing {Google} {Customer} {Reliability} {Engineering}},
url = {https://cloud.google.com/blog/products/gcp/introducing-a-new-era-of-customer-support-google-customer-reliability-engineering/},
abstract = {In the 25 years that I’ve been in technology nearly everything has changed. Computers have moved out of the labs and into our pockets. They’re connected to},
urldate = {2018-10-14},
journal = {Google Cloud Blog},
author = {Rensin, Dave},
month = oct,
year = {2016},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\8TF4ZA2H\\introducing-a-new-era-of-customer-support-google-customer-reliability-engineering.html:text/html},
}
@book{weinberg_introduction_2001,
address = {New York},
edition = {25 Silver anniversary ed edition},
title = {An {Introduction} to {General} {Systems} {Thinking}},
isbn = {978-0-932633-49-1},
abstract = {For more than twenty-five years, An Introduction to General Systems Thinking has been hailed as an innovative introduction to systems theory, with applications in computer science and beyond. Used in university courses and professional seminars all over the world, the text has proven its ability to open minds and sharpen thinking. Originally published in 1975 and reprinted more than twenty times over a quarter century—and now available for the first time from Dorset House Publishing—the text uses clear writing and basic algebraic principles to explore new approaches to projects, products, organizations, and virtually any kind of system. Scientists, engineers, organization leaders, managers, doctors, students, and thinkers of all disciplines can use this book to dispel the mental fog that clouds problem-solving. As author Gerald M. Weinberg writes in the new Preface to the Silver Anniversary Edition, "I haven't changed my conviction that most people don't think nearly as well as they could had they been taught some principles of thinking." Now an award-winning author of nearly forty books spanning the entire software development life cycle—including The Psychology of Computer Programming: Silver Anniversary Edition and Exploring Requirements (with Donald C. Gause)—Weinberg had already acquired extensive experience as a programmer, manager, university professor, and consultant when this book was originally published. With helpful illustrations, numerous end-of-chapter exercises, and an appendix on a mathematical notation used in problem-solving, An Introduction to General Systems Thinking may be your most powerful tool in working with problems, systems, and solutions.},
language = {English},
publisher = {Dorset House Publishing Co Inc.,U.S.},
author = {Weinberg, Gerald M.},
month = jan,
year = {2001},
keywords = {TT refs},
}
@misc{scaled_agile_system_2015,
title = {System {Team} – {Scaled} {Agile} {Framework}},
url = {https://www.scaledagileframework.com/system-team/},
abstract = {SAFe for Lean Enterprises},
language = {en-US},
urldate = {2018-10-14},
author = {{Scaled Agile}},
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\MBRRIA76\\system-team.html:text/html},
}
@article{oconnor_understanding_2018,
title = {{UNDERSTANDING} {TEAM} {COGNITION} {IN} {PERFORMANCE} {IMPROVEMENT} {TEAMS}: {A} {META} {ANALYSIS} {OF} {CHANGE} {IN} {SHARED} {MENTAL} {MODELS}},
shorttitle = {{UNDERSTANDING} {TEAM} {COGNITION} {IN} {PERFORMANCE} {IMPROVEMENT} {TEAMS}},
abstract = {Team cognition is comprised of several factors including shared knowledge or shared mental models (SMM). As there is little agreement about best methods for measuring SMM, this study utilized data from four previous studies and the ACSMM methodology for analysis of data. Findings about SMM in Performance Improvement teams indicate that changes in SMM take place during team task performance and that the changes are similar from one PI team to another. 1 Background},
author = {O'Connor, Debra and Johnson, Tristan},
month = oct,
year = {2018},
keywords = {TT refs},
}
@book{salas_team_2004,
address = {Washington, DC},
title = {Team {Cognition}: {Understanding} the {Factors} {That} {Drive} {Process} and {Performance}},
isbn = {978-1-59147-103-5},
shorttitle = {Team {Cognition}},
abstract = {Given the increased reliance on teams in many organizational settings, it is critical that all those who are interested in improving training and performance better understand team dynamics. During the past decade, cognitive science has substantially influenced the study of team performance and has helped develop the field of team cognition. The contributors to this volume describe the many ways in which team cognition is being used as an organizing framework to guide research into factors that affect team coordination. Nowadays, team cognition must be considered not only within ""conventional"" teams, but also across time and space in distributed teams, and - because of increased use of artificial team members (e.g., intelligent agents) - across people and machines. All of these complicating factors are considered, along with methodological issues that surround the process of measuring and defining team cognition. The unique blend of theory and data in this multidisciplinary book will be of value to psychologists and academics interested in cognition and organizational behavior, to team researchers and practitioners in Industry and the military, and to graduate students Interested in group processes and performance.},
language = {English},
publisher = {American Psychological Assoc},
editor = {Salas, Eduardo and Fiore, Stephen M.},
month = mar,
year = {2004},
keywords = {TT refs},
}
@misc{jo_pearce_hacking_2016,
type = {Technology},
title = {Hacking {Your} {Head} : {Managing} {Information} {Overload} (extended)},
shorttitle = {Hacking {Your} {Head}},
url = {https://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-extended},
abstract = {There are limits on our ability to learn and process information.},
urldate = {2018-10-13},
author = {{Jo Pearce}},
month = apr,
year = {2016},
keywords = {TT refs},
}
@misc{sinha_harsh_2018,
title = {Harsh {Sinha} on {Building} {Culture} at {TransferWise}},
url = {https://www.infoq.com/podcasts/Harsh-Sinha-transferwise-building-culture},
abstract = {In this podcast Shane Hastie, Lead Editor for Culture \& Methods, spoke to Harsh Sinha, CTO of TransferWise, about deliberately designing organisational culture.},
urldate = {2018-10-12},
author = {Sinha, Harsh},
month = feb,
year = {2018},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\385WSC2A\\Harsh-Sinha-transferwise-building-culture.html:text/html},
}
@inproceedings{eckstein_architecture_2014,
series = {Lecture {Notes} in {Business} {Information} {Processing}},
title = {Architecture in {Large} {Scale} {Agile} {Development}},
isbn = {978-3-319-14358-3},
abstract = {In order to welcome changing requirements (even late in development) agile development should enable the architecture to incorporate these changes and therefore to emerge over time. This implies not finalizing the architecture upfront. Moreover, in small agile teams it is assumed that there is no dedicated role for an architect – instead the whole team should be responsible for the architecture. In large-scale agile development the requirement for an emergent architecture still holds true. However, it is unrealistic to ask members of e.g. ten teams to be equally responsible for the architecture. Moreover, the role and support for the architecture depends not only on the degree of the size but as well on the degree of complexity. In this paper I report on the experience using different models for supporting emergent architecture in large environments that take the degree of complexity into account.},
language = {en},
booktitle = {Agile {Methods}. {Large}-{Scale} {Development}, {Refactoring}, {Testing}, and {Estimation}},
publisher = {Springer International Publishing},
author = {Eckstein, Jutta},
editor = {Dingsøyr, Torgeir and Moe, Nils Brede and Tonelli, Roberto and Counsell, Steve and Gencel, Cigdem and Petersen, Kai},
year = {2014},
keywords = {agile methods, architect, change, chief architect, community of practice, complexity, emergent architecture, large-scale agile software development, project management, software engineering, technical consulting team, technical service team, TT refs, uncertainty},
pages = {21--29},
file = {Eckstein - 2014 - Architecture in Large Scale Agile Development.pdf:C\:\\Users\\matth\\Zotero\\storage\\JE895XXZ\\Eckstein - 2014 - Architecture in Large Scale Agile Development.pdf:application/pdf},
}
@book{eckstein_agile_2004,
address = {New York},
title = {Agile {Development} in the {Large}: {Diving} into the {Deep}},
isbn = {978-0-932633-57-6},
shorttitle = {Agile {Development} in the {Large}},
abstract = {Agile or "lightweight" processes have revolutionized the software development industry. They're faster and more efficient than traditional software development processes. They enable developers to * embrace requirement changes during the project * deliver working software in frequent iterations * focus on the human factor in software development Unfortunately, most agile processes are designed for small or mid-sized software development projects—bad news for large teams that have to deal with rapid changes to requirements. That means all large teams! With Agile Software Development in the Large, Jutta Eckstein—a leading speaker and consultant in the agile community—shows how to scale agile processes to teams of up to 200. The same techniques are also relevant to teams of as few as 10 developers, especially within large organizations. Topics include * the agile value system as used in large teams * the impact of a switch to agile processes * the agile coordination of several sub-teams * the way project size and team size influence the underlying architecture Stop getting frustrated with inflexible processes that cripple your large projects! Use this book to harness the efficiency and adaptability of agile software development.},
language = {English},
publisher = {Dorset House Publishing Co Inc.,U.S.},
author = {Eckstein, Jutta},
month = jan,
year = {2004},
keywords = {TT refs},
}
@book{deming_out_1986,
address = {Cambridge, Mass.},
title = {Out of the {Crisis}},
isbn = {978-0-262-54115-2},
publisher = {Massachusetts Institute of Technology},
author = {Deming, W. Edwards},
year = {1986},
keywords = {TT refs},
}
@article{jay_cyclomatic_2009,
title = {Cyclomatic {Complexity} and {Lines} of {Code}: {Empirical} {Evidence} of a {Stable} {Linear} {Relationship}},
volume = {2},
shorttitle = {Cyclomatic {Complexity} and {Lines} of {Code}},
doi = {10.4236/jsea.2009.23020},
abstract = {Researchers have often commented on the high correlation between McCabe's Cyclomatic Complexity (CC) and lines of code (LOC). Many have believed this correlation high enough to justify adjusting CC by LOC or even substituting LOC for CC. However, from an empirical standpoint the relationship of CC to LOC is still an open one. We undertake the largest statistical study of this relationship to date. Employing modern regression techniques, we find the linearity of this relationship has been severely underestimated, so much so that CC can be said to have absolutely no explanatory power of its own. This research presents evidence that LOC and CC have a stable practically perfect linear relationship that holds across programmers, languages, code paradigms (procedural versus object-oriented), and software processes. Linear models are developed relating LOC and CC. These models are verified against over 1.2 million randomly selected source files from the SourceForge code repository. These files represent software projects from three target languages (C, C++, and Java) and a variety of programmer experience levels, software architectures, and development methodologies. The models developed are found to successfully predict roughly 90\% of CC's variance by LOC alone. This suggest not only that the linear relationship between LOC and CC is stable, but the aspects of code complexity that CC measures, such as the size of the test case space, grow linearly with source code size across languages and programming paradigms.},
journal = {JSEA},
author = {Jay, Graylin and Hale, Joanne and Smith, Randy and Hale, David and Kraft, Nicholas and Ward, Charles},
month = jan,
year = {2009},
keywords = {TT refs},
pages = {137--143},
file = {Full Text PDF:C\:\\Users\\matth\\Zotero\\storage\\ZBXI8CGR\\Jay et al. - 2009 - Cyclomatic Complexity and Lines of Code Empirical.pdf:application/pdf},
}
@article{lowe_how_2015,
title = {How to use event storming to achieve domain-driven design},
url = {https://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design},
abstract = {Event storming is a fast, lightweight group modeling technique you can use to accelerate developer productivity and facilitate domain-driven design.},
language = {en},
urldate = {2018-10-10},
journal = {TechBeacon},
author = {Lowe, Steven A.},
month = oct,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\ML8SIA37\\introduction-event-storming-easy-way-achieve-domain-driven-design.html:text/html},
}
@misc{tune_domain-driven_2015,
title = {Domain-{Driven} {Architecture} {Diagrams}},
url = {https://medium.com/nick-tune-tech-strategy-blog/domain-driven-architecture-diagrams-139a75acb578},
abstract = {Domain-Driven Design is about creating shared understanding of the problem space that is reinforced ubiquitously via conversations, code and diagrams. DDD’s Shared understanding enhances synergy and…},
urldate = {2018-10-10},
journal = {Nick Tune’s Tech Strategy Blog},
author = {Tune, Nick},
month = aug,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\U72BQYKC\\domain-driven-architecture-diagrams-139a75acb578.html:text/html},
}
@article{brandolini_strategic_2009,
title = {Strategic {Domain} {Driven} {Design} with {Context} {Mapping}},
url = {https://www.infoq.com/articles/ddd-contextmapping},
abstract = {Many approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity. Context Mapping technique can be used to manage the complexity in large software development projects. In this article, author Alberto Brandolini discusses the many sides of bounded contexts and how to use them to build a context map to support key decisions in a software project.},
urldate = {2018-10-10},
journal = {InfoQ},
author = {Brandolini, Alberto},
month = nov,
year = {2009},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\H7AZU2ME\\ddd-contextmapping.html:text/html},
}
@misc{wiley_scaling_2018,
title = {Scaling {XP} {Through} {Self}-{Similarity} at {Pivotal} {Cloud} {Foundry}},
url = {https://www.agilealliance.org/resources/experience-reports/scaling-xp-through-self-similarity-at-pivotal-cloud-foundry/},
abstract = {RESOURCES Author: Please Note: You must be logged in as a Member to download this content. Download (PDF)},
language = {en-US},
urldate = {2018-10-10},
journal = {Agile Alliance},
author = {Wiley, Evan},
month = jul,
year = {2018},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\W9EPDT2L\\scaling-xp-through-self-similarity-at-pivotal-cloud-foundry.html:text/html},
}
@misc{blalock_mustard_2015,
title = {Of {Mustard} {Seeds} and {Microservices}},
url = {https://www.credera.com/blog/technology-insights/java/mustard-seeds-microservices/},
abstract = {Does your current architecture encourage or impede the development of a rhizomatic culture of autonomy, responsibility, collaboration, speed, and rapid course correction?},
urldate = {2018-10-10},
journal = {Credera},
author = {Blalock, Micah},
month = may,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\6JI5YJ7G\\mustard-seeds-microservices.html:text/html},
}
@misc{nygard_perils_2015,
title = {The {Perils} of {Semantic} {Coupling} - {Wide} {Awake} {Developers}},
url = {http://michaelnygard.com/blog/2015/04/the-perils-of-semantic-coupling/},
abstract = {On the subject of maneuverability, many organizations run into trouble when they try to enter new lines of business, create a partnership, or merge with another company. Updating enterprise systems becomes a large cost factor in these business initiatives, sometimes large enough to outweigh the benefits case. This is a terrible irony: our automation provides efficiency, but removes flexibility. If you break down the cost of such changes, you'll find it comes in equal parts from changes to individual systesm and changes to integrations across systems.},
language = {en},
urldate = {2018-10-10},
author = {Nygard, Michael},
month = apr,
year = {2015},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\KNS9WLXC\\the-perils-of-semantic-coupling.html:text/html},
}
@misc{long_gary_2016,
type = {Tweet},
title = {{GARY} (go ahead, repeat yourself)},
url = {https://twitter.com/starbuxman/status/735550836147814400},
language = {en},
urldate = {2018-10-10},
journal = {@starbuxman},
author = {Long, Josh},
month = may,
year = {2016},
keywords = {TT refs},
file = {Snapshot:C\:\\Users\\matth\\Zotero\\storage\\RVUS2JYV\\735550836147814400.html:text/html},
}
@misc{pivotal_essential_2016,
title = {The {Essential} {Elements} of {Enterprise} {PaaS}},
url = {https://content.pivotal.io/white-papers/the-essential-elements-of-enterprise-paas},
urldate = {2018-10-09},
publisher = {Pivotal},
author = {{Pivotal}},
month = dec,
year = {2016},
keywords = {TT refs},
file = {Pivotal - 2016 - The Essential Elements of Enterprise PaaS.pdf:C\:\\Users\\matth\\Zotero\\storage\\F9JCGQDA\\Pivotal - 2016 - The Essential Elements of Enterprise PaaS.pdf:application/pdf;Snapshot:C\:\\Users\\matth\\Zotero\\storage\\RCQ2W9CL\\the-essential-elements-of-enterprise-paas.html:text/html},
}
@article{maccormack_exploring_2006,
title = {Exploring the {Structure} of {Complex} {Software} {Designs}: {An} {Empirical} {Study} of {Open} {Source} and {Proprietary} {Code}},
volume = {52},
issn = {0025-1909, 1526-5501},
shorttitle = {Exploring the {Structure} of {Complex} {Software} {Designs}},
url = {http://pubsonline.informs.org/doi/abs/10.1287/mnsc.1060.0552},
doi = {10.1287/mnsc.1060.0552},
language = {en},
number = {7},
urldate = {2018-10-09},
journal = {Management Science},
author = {MacCormack, Alan and Rusnak, John and Baldwin, Carliss Y.},