This repository was archived by the owner on Mar 31, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathfeed.xml
1136 lines (940 loc) · 74.8 KB
/
feed.xml
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
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Software Management</title>
<description></description>
<link>http://css566.github.io/</link>
<atom:link href="http://css566.github.io/feed.xml" rel="self" type="application/rss+xml"/>
<pubDate>Wed, 01 Jun 2016 17:59:32 +0000</pubDate>
<lastBuildDate>Wed, 01 Jun 2016 17:59:32 +0000</lastBuildDate>
<generator>Jekyll v3.1.2</generator>
<item>
<title>Software Management Body of Knowledge (SMBOK)</title>
<description><p>The intent of this document is to represent the breadth of information that would be useful for a person to know if they have to make decisions about either (a) managing a system creating software-enabled systems, or (b) managing software-enabled systems. This is the software management body of knowledge (SMBOK).</p>
<h2><a name="content">Content</a></h2>
<ul>
<li>
<h3 id="a-nameteamorganizationteam--organizationa"><a name="teamorganization">Team Organization</a></h3>
<ul>
<li>Agile Teams</li>
<li>Resources Management</li>
<li>Customer requirements</li>
<li>Adaptation</li>
<li>Change management</li>
<li>Communication</li>
<li>Team cohesion</li>
<li>Personality types</li>
<li>Collaboration</li>
<li>Co-located Teams</li>
<li>Cross-Functional Teams</li>
<li>Pair Programming</li>
<li>Virtual Teams (see also Distributed Teams)</li>
<li><a href="/syllabus/2016/05/24/Managing_Distributed_Teams.html">Distributed teams</a>
<ul>
<li>Globally Distributed Teams</li>
</ul>
</li>
<li>Risk tolerance</li>
<li>Org Structure
<ul>
<li>Hierarchical</li>
<li>Flat</li>
<li>Hybrid</li>
<li>Choosing One</li>
</ul>
</li>
<li>Leadership in Software Organisations</li>
<li>Lean Development</li>
</ul>
</li>
<li>
<h3 id="a-nameteambuildingteam-buildinga"><a name="teambuilding">Team Building</a></h3>
<ul>
<li>Recruitment/Hiring
<ul>
<li>Hiring the right people</li>
<li>Retaining people
<ul>
<li>Relationship with culture</li>
<li>Relationship with empathy</li>
<li>Effect / Need of diversity</li>
<li>Attrition/turnover management</li>
</ul>
</li>
</ul>
</li>
<li>People Management
<ul>
<li>Evaluation/assessment</li>
<li>Low performance handling</li>
<li>Peer reviews</li>
<li>Incentives</li>
</ul>
</li>
<li>Orientation</li>
<li>Talent Acquisition</li>
<li>Talent Upgrade</li>
<li>Training</li>
<li>On-boarding</li>
<li>Employee satisfaction</li>
<li>Emotional Safety</li>
<li>Diversity</li>
<li>Tiger teams</li>
<li>Character and Personality Types</li>
<li>Skillsets</li>
</ul>
</li>
<li>
<h3 id="a-nameagilemethodologiesagile-methodologiesa"><a name="agilemethodologies">Agile Methodologies</a></h3>
<ul>
<li>Scrum</li>
<li><a href="/syllabus/2016/04/23/less_syllabus.html">Large-scale Scrum (LeSS)</a></li>
<li>Kanban
- <a href="/2016/04/28/agile_Kanban.html">Physical Aspects of Kanban</a></li>
<li>Scaled Agile Framework (SAFe)</li>
<li>Extreme Programming (XP)</li>
<li>Test-driven development (TDD)</li>
<li>Feature-driven development (FDD)</li>
<li>Lean software development</li>
<li>Rapid Application Development (RAD)</li>
</ul>
</li>
<li>
<h3 id="a-nameriskmanagementrisk-managementa"><a name="riskmanagement">Risk Management</a></h3>
<ul>
<li>Risk identification</li>
<li>Quantitative risk analysis</li>
<li>Qualitative risk analysis</li>
<li>Risk monitoring and control</li>
<li>Risk response planning</li>
</ul>
</li>
<li>
<h3 id="a-namecontinuousimprovementcontinuous-improvementa"><a name="continuousimprovement">Continuous Improvement</a></h3>
<ul>
<li><a href="/2016/05/05/Continuous_Improvement.html">Kaizen</a></li>
<li>Diverse team skillset</li>
<li>Diverse teams and backgrounds</li>
<li>Effective retrospective</li>
<li><a href="/2016/05/12/Lean-Startups_and_CI.html">Lean Startup</a></li>
<li><a href="/2016/05/05/software-measurement.html">Software Metrics and Measurement</a>
<ul>
<li>Defects</li>
<li>ROI/Financials</li>
<li>Productivity</li>
<li><a href="/2016/05/16/CMMI.html">CMMI</a>, other Standards</li>
</ul>
</li>
<li>Agile Methodologies for CI</li>
</ul>
</li>
<li>
<h3 id="a-namefocusoncustomerfocus-on-customera"><a name="focusoncustomer">Focus on Customer</a></h3>
<ul>
<li>Developer engagement-detachment</li>
<li>Customer engagement-detachment</li>
<li>Bringing back emotional connections</li>
<li>Value driven software management</li>
<li>Demonstration-based approach to customer engagement</li>
<li>Emotional design</li>
</ul>
</li>
<li>
<h3 id="a-nameorganizationorganizationa"><a name="organization">Organization</a></h3>
<ul>
<li>Human
<ul>
<li><a href="/2016/05/10/Social_Aspects_of_Software_Management.html">Social aspects of SM</a></li>
<li>Communication</li>
<li>Importance of culture</li>
<li>Value of empathy</li>
</ul>
</li>
<li>Process
<ul>
<li>Identifying and Managing Bottlenecks</li>
</ul>
</li>
<li>Technology</li>
<li>Organizational influences and cultures
<ul>
<li><a href="http://www.agilemanifesto.org/">Agile Manifesto</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<p>Back to <a href="#content">top</a></p>
<ul>
<li>
<h3 id="a-namechangemanagementchange-management---how-to-manage-change-organizational-change-change-agents-seedsa"><a name="changemanagement">Change Management - how to manage change, organizational change, change agents, seeds</a></h3>
</li>
<li>
<h3 id="a-nameinformationsharinginformation-sharinga"><a name="informationsharing">Information Sharing</a></h3>
</li>
<li>
<h3 id="a-namesharedunderstandingshared-understandinga"><a name="sharedunderstanding">Shared Understanding</a></h3>
<ul>
<li>Aligned goals</li>
<li>Collaborate</li>
<li>Teamwork</li>
</ul>
</li>
<li>
<h3 id="a-namecollaborationcollaborationa"><a name="collaboration">Collaboration</a></h3>
<ul>
<li>Human Resource Management</li>
<li><a href="/2016/05/05/physical-workspaces.html">Office Floor Plans</a></li>
</ul>
</li>
<li>
<h3 id="a-nameproductivityproductivitya"><a name="productivity">Productivity</a></h3>
<ul>
<li><a href="/2016/05/05/software-measurement.html">Measuring productivity</a></li>
<li>Effect of collaboration</li>
<li>Concepts form Mythical man month</li>
</ul>
</li>
<li>
<h3 id="a-namecoordinationcoordinationa"><a name="coordination">Coordination</a></h3>
<ul>
<li>Negotiation</li>
<li>Conflict management</li>
</ul>
</li>
<li>
<h3 id="a-namesystemsthinkingsystems-thinkinga"><a name="systemsthinking">Systems Thinking</a></h3>
</li>
<li>
<h3 id="a-nametimetimea"><a name="time">Time</a></h3>
<ul>
<li>Time Constraints</li>
<li>Software Delivery Cadence</li>
<li>Fiscal Quarters</li>
<li>Deadlines</li>
<li>Estimating delivery time</li>
<li>Adapting to a schedule</li>
<li>Time Management</li>
</ul>
</li>
<li>
<h3 id="a-nameproblemsolvingproblem-solvinga"><a name="problemsolving">Problem Solving</a></h3>
<ul>
<li>Complexity Analysis</li>
</ul>
</li>
<li>
<h3 id="a-nameplanningplanninga"><a name="planning">Planning</a></h3>
<ul>
<li>Estimation/sizing</li>
<li>Resource allocation</li>
<li>Timeline/schedule planning</li>
<li>Commitment</li>
</ul>
</li>
<li>
<h3 id="a-nameprocessprocessa"><a name="process">Process</a></h3>
<ul>
<li>Frameworks</li>
<li>Software methodologies</li>
</ul>
</li>
<li>
<h3 id="a-nameoverallmanagementoverall-managementa"><a name="overallmanagement">Overall Management</a></h3>
<ul>
<li>Program</li>
<li>Portfolio</li>
<li>Release</li>
</ul>
</li>
<li>
<h3 id="a-nameoperationssupportoperationssupportmaintenance-managementa"><a name="operationssupport">Operations/Support/Maintenance Management</a></h3>
<ul>
<li>DevOps</li>
<li>Tech Support</li>
<li>Automated/instrumentalized log reporting/bug reporting</li>
</ul>
</li>
<li>
<h3 id="a-namelifecyclemanagementlifecycle-managementa"><a name="lifecyclemanagement">Lifecycle Management</a></h3>
<ul>
<li>Product, software, process</li>
<li>Iterative life cycle processes</li>
</ul>
</li>
</ul>
<p>Back to <a href="#content">top</a></p>
<ul>
<li>
<h3 id="a-nametheoryofconstraintstheory-of-constraintsa"><a name="theoryofconstraints">Theory of Constraints</a></h3>
</li>
<li>
<h3 id="a-namequeuingtheoryqueuing-theorya"><a name="queuingtheory">Queuing Theory</a></h3>
</li>
<li>
<h3 id="a-namerolesandresponsibilitiesroles-and-responsibilitiesa"><a name="rolesandresponsibilities">Roles and Responsibilities</a></h3>
<ul>
<li>Stakeholders</li>
<li>Business Team</li>
<li>Dev Team</li>
<li>Test Team</li>
<li>Ops Team</li>
<li>Marketing Team</li>
<li>Define roles/tasks of team members</li>
<li>Customer
<ul>
<li>Influencer, buyer</li>
</ul>
</li>
</ul>
</li>
<li>
<h3 id="a-namequalitymanagementquality-managementa"><a name="qualitymanagement">Quality Management</a></h3>
<ul>
<li>QA</li>
<li><a href="/2016/05/05/software-measurement.html">Metrics</a></li>
<li>Quality attributes</li>
<li>Automation</li>
<li>Continuous improvement</li>
</ul>
</li>
<li>
<h3 id="a-namefinancialmanagementfinancial-managementa"><a name="financialmanagement">Financial Management</a></h3>
<ul>
<li>Budget</li>
<li>P&amp;L</li>
<li>Resource management</li>
<li>Business models</li>
<li>Cost/revenue</li>
<li>Investors</li>
</ul>
</li>
<li>
<h3 id="a-namefeasibilityanalysisfeasibility-analysisa"><a name="feasibilityanalysis">Feasibility Analysis</a></h3>
<ul>
<li>Technical Feasibility</li>
<li>Market Feasibility</li>
</ul>
</li>
<li>
<h3 id="a-namedevelopmentcontextdevelopment-contexta"><a name="developmentcontext">Development Context</a></h3>
<ul>
<li>Organization</li>
<li><a href="/syllabus/2016/04/28/physical_syllabus.html">Physical Environment</a></li>
<li>Social Aspects (Human Factors)
<ul>
<li>Personalities</li>
<li>Cultures</li>
<li>Leadership</li>
<li>Collaboration</li>
</ul>
</li>
<li>Cyber
<ul>
<li>Development Tools</li>
<li>Development Frameworks</li>
</ul>
</li>
</ul>
</li>
<li>
<h3 id="a-namesoftwaredeliverymechanismsoftware-delivery-mechanisma"><a name="softwaredeliverymechanism">Software Delivery Mechanism</a></h3>
<ul>
<li>Software as a service – subscription model</li>
</ul>
</li>
<li>
<h3 id="a-namearchitecturearchitecturea"><a name="architecture">Architecture</a></h3>
<ul>
<li>Design Foundation
<ul>
<li><a href="/2016/05/03/waterfall_physical.html">Waterfall</a>/Separate Design Phase
<ul>
<li>BUFD (Big UpFront Design)</li>
</ul>
</li>
<li>Deployment context</li>
<li>Pregame (Scrum)</li>
</ul>
</li>
<li>Agile Design Approach
<ul>
<li>Interative</li>
<li>Refactoring</li>
<li>Experimental</li>
</ul>
</li>
<li>Documentation
<ul>
<li>Design Artifacts</li>
<li>Agile (code is best artifacts)</li>
<li>Maintainability</li>
</ul>
</li>
</ul>
</li>
<li>
<h3 id="a-namesourcecontrolsource-controla"><a name="sourcecontrol">Source Control</a></h3>
<ul>
<li>Open Repositories</li>
<li>Online Repositories</li>
<li>Commitment and Rollback</li>
<li>Version Control</li>
</ul>
</li>
<li>
<h3 id="a-nameopensourceopen-sourcea"><a name="opensource">Open Source</a></h3>
<ul>
<li>Management of codebase</li>
<li>Access Rights</li>
<li>Distribution Rights</li>
<li>Copyright/Copyleft</li>
</ul>
</li>
<li>
<h3 id="a-namemanagementfor-publicmanagement-for-publicgovernment-projectsa"><a name="managementfor public">Management for Public/Government Projects</a></h3>
<ul>
<li>Requirements Analysis</li>
<li>Schedule</li>
<li>Financials</li>
<li>Application of Agile Methodologies</li>
</ul>
</li>
<li>
<h3 id="a-namelegalconsiderationslegal-considerations-for-software-managementa"><a name="legalconsiderations">Legal Considerations for Software Management</a></h3>
<ul>
<li>Security</li>
<li>Open Source</li>
<li>Critical Systems (Driverless Vehicles, Flight Control Systems, Medical Systems)</li>
<li>Copyright</li>
</ul>
</li>
<li>
<h3 id="a-namesoftwaretestingsoftware-testinga"><a name="softwaretesting">Software Testing</a></h3>
<ul>
<li>Quality Control/Assurance (QC/QA)</li>
<li>Test vs. Production Environments</li>
<li>Static Testing</li>
<li>Load Simulation</li>
</ul>
</li>
<li>
<h4 id="visual-maps-of-software-management-theories-principles-and-practicessyllabus20160503visualmapshtml"><a href="/syllabus/2016/05/03/visual_maps.html">Visual Maps of Software Management Theories, Principles, and Practices</a></h4>
</li>
</ul>
<p>Back to <a href="#content">top</a></p>
</description>
<pubDate>Thu, 26 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/2016/05/26/SWBOK.html</link>
<guid isPermaLink="true">http://css566.github.io/2016/05/26/SWBOK.html</guid>
</item>
<item>
<title>Continuous Improvement - Related Videos</title>
<description><h1 id="continuous-improvement-videos">Continuous Improvement Videos</h1>
<p><a href="https://www.youtube.com/watch?v=KyhR9hvMlPw">Creating A Continuous Improvement Culture</a><br />
This video focuses on how to create a continuous improvement culture in an organization.
The video goes into details about the history of continuous improvement, the goals behind
continuous inprovement, examples of continuous improvement in major companies, and how to
create continuous improvement in an organization.</p>
<p><a href="https://www.youtube.com/watch?v=yeLZSEQW3pE">8 Things To Avoid to Make Your Kaizen More Successful</a><br />
This video gives a lecture on eight things to avoid to help make continuous improvement more successful.
This video gives examples of things to avoid, and how avoiding these things can lead to different
scenarios that help facilitate better continuous improvement practices.</p>
<p><a href="https://www.youtube.com/watch?v=1hvprBVWn3M">Continuous process improvement: Penny Weller at TEDxKalamazoo</a><br />
This video showcases a Tedx talk with continuous improvement as the subject. This video describes continuous
improvement, how to incorporate continuous improvement, and how integrating continuous improvement can increase
a customer’s satisfaction towards a product or service.</p>
<p><a href="https://www.youtube.com/watch?v=UgAHWhwIyMI">How to implement Continuous Improvement</a><br />
This video showcases a short animated clip showing where to begin when trying to implement continuous improvement into a
business. The video briefly goes over what continous improvement is, and how to integrate continuous improvement
in an already existing business.</p>
<p><a href="https://www.youtube.com/watch?v=VsK--Fs5I40">The Best Leadership Style for Continuous Improvement</a><br />
This video explains about the leadership styles that are best suited towards facilitating continuous improvement,
and this video explains about the impact these leadership styles have on getting people motivated towards continuously
improving themselves.</p>
</description>
<pubDate>Tue, 24 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/2016/05/24/continuous_Improvement_Videos.html</link>
<guid isPermaLink="true">http://css566.github.io/2016/05/24/continuous_Improvement_Videos.html</guid>
</item>
<item>
<title>Continuous Improvement Unit Syllabus</title>
<description><hr />
<h2 id="introduction">INTRODUCTION</h2>
<p>Continuous improvement is a method for identifying opportunities for streamlining work and reducing waste. The practice was formalized by the popularity of Lean / Agile / Kaizen in manufacturing and business, and it is now being used by thousands of companies all over the world to identify savings opportunities.</p>
<p>This unit examines aspects of continuous improvement, and how those aspects may be applied to Software Management. The software development world is extremely competitive - in order to stay ahead, companies need to continuously improve their Software Management methodologies and practices.</p>
<h2 id="learning-objectives">LEARNING OBJECTIVES</h2>
<p>By the end of the unit, the student should be able to:</p>
<ul>
<li>Understand the importance of Continuous Improvement to Software Management.</li>
<li>Understand Lean startups and their connection to Continuous Improvement.</li>
<li>Identify different techniques companies use to implement Continuous Improvement.</li>
<li>Understand aspects of Software Measurement and Metrics, and how they are tied to Continuous Improvement.</li>
</ul>
<h2 id="organization">ORGANIZATION</h2>
<ul>
<li><a href="/2016/05/05/Continuous_Improvement.html">Overview</a></li>
<li><a href="/2016/05/12/Lean-Startups_and_CI.html">Lean Startups and Continuous Improvement</a></li>
<li><a href="/2016/05/05/software-measurement.html">Software Measurement and Metrics</a></li>
<li><a href="/2016/05/16/CMMI.html">Capability Maturity Model Integrated (CMMI)</a></li>
</ul>
<h2 id="additional-resources">Additional Resources</h2>
<ul>
<li><a href="/2016/05/12/Continous_Improvement_Articles.html">Journal Articles</a></li>
<li><a href="/2016/05/12/Continous_Improvement_casestudies.html">Case Studies</a></li>
<li><a href="/2016/05/24/continuous_Improvement_Videos.html">Videos</a></li>
</ul>
<h2 id="smbok-continuous-improvement20160526swbokhtmlcontinuousimprovement"><a href="/2016/05/26/SWBOK.html#continuousimprovement">SMBOK Continuous Improvement</a></h2>
</description>
<pubDate>Tue, 24 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/syllabus/2016/05/24/Continuous_Improvement_Syllabus.html</link>
<guid isPermaLink="true">http://css566.github.io/syllabus/2016/05/24/Continuous_Improvement_Syllabus.html</guid>
<category>syllabus</category>
</item>
<item>
<title>Managing Distributed Teams</title>
<description><h1 id="managing-distributed-teams">Managing Distributed Teams</h1>
<h2><a name="content">Contents</a></h2>
<ul>
<li><a href="#overview">Overview</a></li>
<li><a href="#theories">Theories</a>
<ul>
<li>Social Identity Theory</li>
<li>Technocracy</li>
<li>Swift Trust Theory</li>
<li>Media Richness Theory (MRT)</li>
</ul>
</li>
<li><a href="#principles">Principles</a>
<ul>
<li>Building trust</li>
<li>Time zone, language, and cultural barriers</li>
<li>Communication</li>
<li>Technical alignments</li>
<li>Project and process management</li>
</ul>
</li>
<li><a href="#practices">Practices</a></li>
<li><a href="#resources">Resources</a>
<ul>
<li>Blogs</li>
</ul>
</li>
<li><a href="#references">References</a></li>
</ul>
<h2><a name="overview">Overview</a></h2>
<p>Software development eams can be distributed geographically, culturally, with language barriers, across time zones, or just across campus. Developing software using distributed teams requires special emphasis on communication and building trust. A variety of practices are available to help with these issues. The extra effort can be well worth it. The diversity that distributed teams bring to solving a software problem can help to promote innovation and creativity in your teams.</p>
<p><a href="https://www.youtube.com/watch?v=guhgE9N0AGA" title="what is Distributed Teams"><img src="https://i1.ytimg.com/vi/guhgE9N0AGA/maxresdefault.jpg" alt="what is Distributed Teams" /></a></p>
<h2><a name="theories">Theories</a></h2>
<h3>Social Identity Theory</h3>
<p>People are allocated to more one culture at a time, but different cultures are seen as being mutually exclusive. The theory predicts inter-group behavior on the basis of perceived group state differences, the perceived legitimacy and stability of those differences, and the perceived ability to move from one group to another.</p>
<h3>Technocracy</h3>
<p>The term was originally used to promote applying the scientific method to solving social problems, but is also an organizational structure of governance where decision-makers are selected on the basis of technological knowledge and merit. Technocrats are individuals with technical training and occupations who perceive many important social problems as being solvable, often while proposing technology-focused solutions. A technocrat is primarily driven by their cognitive “problem-solution mindset.”</p>
<h3>Swift Trust Theory</h3>
<p>Swift trust is a form of trust occurring in temporary organizational structures, which can include quick starting groups or teams. It was first explored by Debra Meyerson and colleagues in 1996. In swift trust theory, a group or team assumes trust initially, and later verifies and adjusts trust beliefs accordingly.
Traditionally, trust has been examined in the context of long-term relationships. The establishment of trust has been thought to rely largely on the history of a group and the interactions between members. This traditional view of trust generally assumes that trust builds over time. However, this view is becoming problematic with the increase in globalization, change in technologies, and an increased reliance on temporary teams by organizations. Meyerson et al. propose that swift trust provides the necessary, initial, cognitive confidence for a temporary team to interact as if trust were present. However, swift trust requires an individual to verify that a team can manage vulnerabilities and expectations.</p>
<h3>Media Richness Theory (MRT)</h3>
<p>This theory is based on the work of Daft and Lengel (1984 and 1986) and Daft, Lengel and Trevino (1987). MRT is a theory that can be used to describe the ability of communication media to transfer information. It assumes that organisations process information to reduce uncertainty and equivocality (Weiman,P 2010).</p>
<p>Back to <a href="#content">top</a></p>
<h2><a name="principles">Principles</a></h2>
<h3>Building trust</h3>
<p>Nothing is more important than this crucial element of a hyper-productive team, and building trust is essential in the formation of cohesiveness between team members. Gaining trust is a challenge when team members are distributed across different time zones, cultures, and environments, and when they also face communication, language, technical alignment, and project management issues. When a team doesn’t possess a minimum level of trust, it’s more difficult to deal with challenges when they appear – it is often easy to blame and criticize the ‘other’ groups and the team can break down into competing tribes. When trust is strong, team members are able to work through the most difficult issues and they often create innovative solutions.</p>
<h3>Time zone, language, and cultural barriers</h3>
<p>It is vital to create overlapping office hours so that remote teams can communicate, resolve problems, and bridge time zones for other mission-critical tasks. More overlapping time during the day fosters better engagement and collaboration. When team members come from different cultural backgrounds, language and cultural differences can easily create misunderstanding and generate mistrust among team members. In addition, team members in different regions generally have varying degrees of skill and technology expertise, which can create a class system between the different remote teams and hinder collaboration. W H I T E PA P E R : Successful Distributed Agile Team Working Patterns</p>
<p>Shane Hastie and Johanna Rothman explain the challenges that come with distance, be it cultural, social, linguistic, temporal, or geographic. If you work to reinforce your collaboration habits every day, your geographically distributed agile team will thank you.</p>
<p>Related : https://www.agileconnection.com/article/getting-most-out-your-geographically-distributed-agile-team</p>
<h3>Communication</h3>
<p>As outlined in the section above, different time zones create communication challenges for teams. Overlapping office hours facilitate periods for discussions, problem solving, remote pairing, and other activities that contribute to a project’s success. It is crucial to create as much overlapping time during the day as possible. Team members at different locations often fall back to using low bandwidth communication channels, such as emails or documents, which generates large amounts of lost or misunderstood information. Therefore, high bandwidth communication tools such as video conferencing or desktop sharing should be used as frequently as possible.</p>
<h3>Technical alignments</h3>
<p>Team members from different backgrounds and regions may have divergent preferences about technologies and tools. For example, team members in Redmond, Washington may have a bias towards Microsoft technologies, while members in China may prefer open-source technologies. Misalignment in engineering best practices can also create conflicts between the remote teams – for example, determining whether to use test first vs. test later development practices or when to do refactoring. Other typical misalignments are coding standards, tooling, and architectural design. Within a co-located team, these misalignments on values are generally resolved over time by day-to-day discussion and communication between team members, with team members gradually building mutual understanding.</p>
<h3>Project and process management</h3>
<p>In a co-located team, the need for online project and process management is minimal— most co-located teams prefer a physical task board, and BVCs (big visible charts) in the team area to help them stay current on progress and information-sharing with other members. In a distributed environment, transparency and visibility are essential for all remote teams. High-visibility, real-time online project tracking and process management (for example, next Sprint planning dates, CI monitoring) enables all teams to be fully engaged in the development process.</p>
<p>Related :
https://www.mindtools.com/pages/article/newTMM_40.htm</p>
<p>Back to <a href="#content">top</a></p>
<h2><a name="practices">Practices</a></h2>
<p><a href="https://www.youtube.com/watch?v=FGg23p_ksp8" title="Managing distributed teams!"><img src="https://i1.ytimg.com/vi/FGg23p_ksp8/maxresdefault.jpg" alt="Managing distributed teams,5 golden rules " /></a></p>
<h3>Build “The A Team“</h3>
<p>In order to have the highest quality possible and better productivity, synergy within the team is very important. Often, there are various challenges but this is the most important factor. Team members on the same frequency usually leads to successful projects.</p>
<h3>Set Expectations/Roles within the team</h3>
<p>Team members should always work towards same goal. In our case, it is delivering the highest quality product. Team managers/leads should let each and every team member know what role they are going to play in the project and their responsibility.</p>
<h3>Be Transparent within the team</h3>
<p>Being transparent keeps all the team members on same page, which helps reach their goals collectively.</p>
<h3>Communicate often within the team</h3>
<p>Since the team is distributed, communication is a very important factor, such as having daily calls with leads and with team if required. It is always necessary within the team to have a willingness to learn, share and communicate with peers.</p>
<h3>Status Reporting to the team</h3>
<p>Each and every team should share their status reports to let distributed team members know the progress, which will help them to carry out the tasks remaining.</p>
<h3>Setting up Video conferences</h3>
<p>If not daily or weekly, there should be monthly video conferences to help team to know whom they are working with especially if the team is distributed.</p>
<h3> Having face to face meeting (if possible)</h3>
<h3> Usage of Tools</h3>
<p>Tools help the distributed team to often store data, collaborate adequately within the team. SharePoint, blog, WebEx, net meeting, Team Viewer, Req Pro, Quality Center, Perforce, MS project are some of the examples. It also increases the productivity and helps us to stay on top of things.</p>
<p>Related : https://www.linkedin.com/pulse/best-practices-managing-distributed-teams-mba-csm-lss-gb</p>
<p>Back to <a href="#content">top</a></p>
<h2><a name="resources">Resources</a></h2>
<h3>Blogs</h3>
<h4>Getting most out your geographically distributed agile team </h4>
<p>Shane Hastie and Johanna Rothman explain the challenges that come with distance, be it cultural, social, linguistic, temporal, or geographic. If you work to reinforce your collaboration habits every day, your geographically distributed agile team will thank you.
Related : https://www.agileconnection.com/article/getting-most-out-your-geographically-distributed-agile-team</p>
<h4>Virtual community of practice </h4>
<p>This Wikipedia page talks about what is online community of practice also called as virtual community of practice, current research, its advantages, disadvantages and some real world examples.</p>
<p>Related : https://en.wikipedia.org/wiki/Virtual_community_of_practice</p>
<p>Back to <a href="#content">top</a></p>
<h2><a name="references">References</a></h2>
<p>Christopher P. Furner. 2013. Cultural Determinants of Information Processing Shortcuts in Computer Supported Groups: A Review, Research Agenda and Instrument Validation. Int. J. Inf. Syst. Soc. Chang. 4, 3 (July 2013), 17-32. DOI=http://dx.doi.org/10.4018/jissc.2013070102</p>
<p>Na Li and Mary Beth Rosson. 2014. Using annotations in online group chats. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ‘14). ACM, New York, NY, USA, 863-866. DOI=http://dx.doi.org/10.1145/2556288.2557209</p>
<p>Bruce A. Reinig and Roberto J. Mejias. 2014. On the Measurement of Participation Equality. Int. J. e-Collab. 10, 4 (October 2014), 32-48. DOI=http://dx.doi.org/10.4018/ijec.2014100103</p>
<p>Daft, R.L., &amp; Lengel, R.H. (1984) Information Richness: A New Approach to Managerial Behavior and Organizational Design. In L.L. Cummings, &amp; B.M. Staw (Eds.), Research in Organizational Behavior (pp191-233). Homewood, IL: JAI Press.</p>
<p>Daft, R.L., &amp; Lengel, R.H. (1986) Organizational Information Requirements, Media Richness and Structural Design. Management Science, Vol 32, No. 5, pp554-571.</p>
<p>Daft, R.L., Lengel, R.H., &amp; Trevino, L. K. (1987) Message Equivocality, Media Selection, and Manager Performance Implications r Information Systems. MIS Quarterly, Vol 11, No. 3, pp354-366.</p>
<p>Fang Chen, Limin Zhang, and Joseph Latimer. 2014. How much has my co-worker contributed? The impact of anonymity and feedback on social loafing in asynchronous virtual collaboration. Int. J. Inf. Manag. 34, 5 (October 2014), 652-659. DOI=http://dx.doi.org/10.1016/j.ijinfomgt.2014.05.001</p>
<p>Timo O. A. Lehtinen, Risto Virtanen, Juha O. Viljanen, Mika V. Mäntylä, and Casper Lassenius. 2014. A tool supporting root cause analysis for synchronous retrospectives in distributed software teams. Inf. Softw. Technol. 56, 4 (April 2014), 408-437. DOI=http://dx.doi.org/10.1016/j.infsof.2014.01.004</p>
<p>Jennifer A. Nicholson, Darren B. Nicholson, Patrick Coyle, Andrew Hardin, and Anjala S. Krishen. 2014. Exploring the Use of Virtual World Technology for Idea-Generation Tasks. Int. J. e-Collab. 10, 3 (July 2014), 44-62. DOI=http://dx.doi.org/10.4018/ijec.2014070103</p>
<p>J. F. Nunamaker, Alan R. Dennis, Joseph S. Valacich, Douglas Vogel, and Joey F. George. 1991. Electronic meeting systems. Commun. ACM 34, 7 (July 1991), 40-61. DOI=http://dx.doi.org/10.1145/105783.105793</p>
<p>Gary Klein, James J. Jiang, and Debbie B. Tesch. 2002. Wanted:project teams with a blend of is professional orientations. Commun. ACM 45, 6 (June 2002), 81-87. DOI=http://dx.doi.org/10.1145/508448.508452</p>
<p>Barry W. Boehm. 1991. Software Risk Management: Principles and Practices. IEEE Softw. 8, 1 (January 1991), 32-41. DOI=http://dx.doi.org/10.1109/52.62930</p>
<p>N. Jonsson, D. Novosel, J. Lillieskold, and M. Eriksson. 2001. Successful Management of Complex, Multinational R&amp;D Projects. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences ( HICSS-34)-Volume 8 - Volume 8 (HICSS ‘01), Vol. 8. IEEE Computer Society, Washington, DC, USA, 8044-.</p>
<p>Catherine M. Beise. 2004. IT project management and virtual teams. In Proceedings of the 2004 SIGMIS conference on Computer personnel research: Careers, culture, and ethics in a networked environment (SIGMIS CPR ‘04). ACM, New York, NY, USA, 129-133. DOI=http://dx.doi.org/10.1145/982372.982405</p>
<p>Viviane Santos, Alfredo Goldman, and Cleidson R. B. De Souza. 2015. Fostering effective inter-team knowledge sharing in agile software development. Empirical Softw. Engg. 20, 4 (August 2015), 1006-1051. DOI=10.1007/s10664-014-9307-y http://dx.doi.org/10.1007/s10664-014-9307-y</p>
<p>Wikipedia. (2016, April 15). Swift trust theory. Retrieved from Wikipedia, the free encyclopedia: https://en.wikipedia.org/wiki/Swift_trust_theory</p>
<p>Weimann, P, Hinz, C, Scott, E and Pollock, M. “Changing the Communication Culture of Distributed Teams in a World Where Communication is Neither Perfect nor Complete” The Electronic Journal Information Systems Evaluation Volume 13 Issue 2 2010, (pp187 - 196), available online at www.ejise.com</p>
<p>Lori Anschuetz, Tec-Ed, Inc., “Managing Geographically Distributed Teams”, IPCC 98 Proceedings, the annual conference of the IEEE Professional Communication Society, 1998.
http://teced.com/wp-content/uploads/2011/06/ipcc98la-managing-geographically-distributed-teams.pdf</p>
<p>Monica Yap, Successful Distributed Agile Team Working Patterns, SolutionsIQ, Inc. 2010
https://www.solutionsiq.com/docs/successful-distributed-team-working-patterns.pdf</p>
<p>Back to <a href="#content">top</a></p>
</description>
<pubDate>Tue, 24 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/syllabus/2016/05/24/Managing_Distributed_Teams.html</link>
<guid isPermaLink="true">http://css566.github.io/syllabus/2016/05/24/Managing_Distributed_Teams.html</guid>
<category>syllabus</category>
</item>
<item>
<title>Agile Software Management Economic Unit Principles</title>
<description><ul>
<li>Working software as a minimum shippable product
<ul>
<li>Working software that is continuously delivered creates visibility into the process and helps eliminate wasted time and resources (i.e. money) [1]</li>
</ul>
</li>
<li>Responding to Change
<ul>
<li>“If we built the wrong thing, we can stop wasting money on that path.” [3]</li>
<li>Risk is reduced because business is more able to rapidly respond to change and adapt to changing competitive and technological landscape [1]</li>
</ul>
</li>
<li>Customer collaboration [2]
<ul>
<li>Customers and business gets better product in the end with Agile because their needs are addressed continually. Happier customers = healthier business finances</li>
<li>Customer collaboration creates transparency and trust with them, resulting in evangelists for the business/software and more demand for your software [3]</li>
</ul>
</li>
<li>People and interactions over processes and tools
<ul>
<li>Agile prefers small, cross-org teams over monolithic large teams, leading to faster decisions and mitigation of risks of bad decisions. [3]
<ul>
<li>This has an indirect financial impact that ties in with less wasted resources</li>
<li>Focus on people, both internal and external (employees and customers), results in many social benefits such as sense of ownership, flexibility in approach, dynamic adaptability, and trust with customers. Happier people = better product = happier customers = better business value</li>
</ul>
</li>
</ul>
</li>
</ul>
<p><img src="/images/Customer-Focused-Approach.png" alt="GitHub Logo" width="500" /></p>
<p>Figure 1. Agile focus on customers and people allows for rapid adaptation to customer expectations, as illustrated. Source: [11]</p>
<ul>
<li><a href="/syllabus/2016/04/28/agile_economic_syllabus.html">Unit Home</a></li>
</ul>
</description>
<pubDate>Thu, 19 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/2016/05/19/agile_economic_principles.html</link>
<guid isPermaLink="true">http://css566.github.io/2016/05/19/agile_economic_principles.html</guid>
</item>
<item>
<title>Agile Software Management Economic Unit Practices and Theories</title>
<description><ul>
<li>Build continual planning and customer feedback into the process
<ul>
<li>Value is maximized throughout the development process [1]</li>
<li>“As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process.” [1]</li>
</ul>
</li>
<li>Early and frequent delivery of value to customers
<ul>
<li>Agile development “accelerates the delivery of initial business value” [1]
<ul>
<li>This can be empirically measured, such as the in-class penny exercise that proved that iterative small batches results in faster delivery of value to the customer</li>
</ul>
</li>
<li>Customers will reduce the value they place on something if they have to wait too long, so early delivery is better [4]</li>
<li>Early delivery means early money to use for other business needs and investments [3]</li>
<li>Continual cash flow is healthier for the business than waiting for money at the end of a project [3]</li>
</ul>
</li>
<li>Iterative development
<ul>
<li>Ideas, concepts, and software features depreciate over time and have a “freshness window” before people place no value in them, so Agile development works within that 1-4 week timeframe to stay on top of customer needs and market demands [4</li>
<li>Iterative software product produces less value more frequently and is able to achieve higher overall value before depreciating revenue-wise [4]</li>
<li>Risk is “reset” every iteration due to iterative reevaluation of product [4]</li>
<li>Bug cost is reduced because they are continually tested and squashed instead of looked at far after the code is written [4]</li>
</ul>
</li>
</ul>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/agile_development_value_proposition.jpg" alt="GitHub Logo" width="400" height="400" /></p>
<p>Figure 2. Charts showing value proposition of Agile Development (red) vs. Traditional Development (gray). Source: VersionOne Enterprise Agile Solutions [1]</p>
<ul>
<li>Theory of constraints - “The chain is no stronger than its weakest link” [5]
<ul>
<li>Limiting amount of work that causes constraint or bottleneck</li>
<li>Diverting work away from the bottleneck</li>
<li>Increasing limitation of bottleneck by buying systems or hiring people</li>
</ul>
</li>
<li>Use of agile methodology to reduce cost of failure [5]
<ul>
<li>Faster feedback from stakeholders</li>
<li>Increasing flow of information within participating entities in a scrum</li>
<li>Decreasing the risk of one person failing by reducing number of dependencies on that person and distributing work equally amongst everyone</li>
<li>Focusing more on simplicity and reducing complication</li>
</ul>
</li>
<li>Importance of refactoring in agile [6]
<ul>
<li>More cost is incurred for adding features than the business benefits of adding these features if software system becomes dysfunctional and complicated</li>
<li>Refactoring is safest and cheapest when done in many small chunks</li>
<li>Use of business requests as catalysts for refactoring rather than call from technical teams</li>
<li>Team cohesion in terms of communication and collaboration in regards to which tools, techniques, and practices to use in refactoring</li>
<li>Team’s openness and honesty with all stakeholders about the cost of refactoring</li>
</ul>
</li>
</ul>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/SM_Unit_Economic_CaseStudy_1.jpg" alt="GitHub Logo" width="400" height="400" /></p>
<p>Figure 3. Diagram illustrating how refactoring reduces complexity and costs in agile software development. Source: Richard Fridrich [5]</p>
<ul>
<li>Shorter feedback loops [7]
<ul>
<li>In agile, risks are cut down because of short releases in contrary to multi-year waterfall projects. Hence, feedback reduced to a smaller period</li>
<li>Comparison of the opportunity cost of agile and waterfall results in identifying waste of money and missing opportunity of working on more profitable projects in waterfall</li>
<li>
<p>User satisfaction has value too and not just return on investment in the form of money</p>
</li>
<li><a href="/syllabus/2016/04/28/agile_economic_syllabus.html">Unit Home</a></li>
</ul>
</li>
</ul>
</description>
<pubDate>Thu, 19 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/2016/05/19/agile_economic_practices_theories.html</link>
<guid isPermaLink="true">http://css566.github.io/2016/05/19/agile_economic_practices_theories.html</guid>
</item>
<item>
<title>Agile Software Management Economic Unit Case Studies</title>
<description><p>1) <strong>“Mugshot.com” Website</strong></p>
<p>Case-study that shows how agile outperforms traditional techniques - by Chad Albrecht of Centare [4]
In this video (cited in references [4]), Chad has demonstrated a side-by-side cost model of an Agile vs. Traditional project. This case study is about creating a simple website, “Mugshot.com”. This social network site allows users to connect with family and friends. The major requirement is the website must be up and running ASAP.</p>
<p>Some principles that they are going to use are:</p>
<ul>
<li>Bugs cost more the longer we wait</li>
<li>Requirements change</li>
<li>Some requirements are wrong</li>
<li>Software depreciates</li>
<li>We can choose when to stop developing</li>
</ul>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/SM_Unit_Economic_CaseStudy_2.jpg" alt="GitHub Logo" /></p>
<p>Figure 4. Team structure and budget planning for Mugshot website. Source: [4]</p>
<p>Figure 4 describes the structure of the team that is going to work on developing the website.</p>
<p>They have taken a team of 6 developers who will be working on developing the website. And they are going to include everybody on that team. They have four software engineers, a DBA and a QA. Each of them cost 2000/week. Total comes out to be $12000/week. There are 120 requirements to start with, given a requirement stack. Almost 20% of requirements are invalid. And they are getting approximately two changes a week. Each developer is putting four bugs per day in the code. The longer the bug sticks around, the more it costs to fix. For the first 7 days, it takes 15 minutes. For first 30 days, it takes 30 minutes. Thereafter, they are gonna take 90 minutes to fix. The purpose of this is to model some of the things that we see in industry and try to compare short-cycle vs long-cycle that is, agile practices vs more traditional long cycle practices.</p>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/SM_Unit_Economic_CaseStudy_3.jpg" alt="GitHub Logo" /></p>
<p>Figure 5. Traditional Approach - Cost Summary. Source of image: [4]</p>
<p>What this comes down when you plug all these numbers in is, its gonna cost them about almost half a million dollars to develop in a traditional sense (Refer figure 2), with discovery and estimation, implementation, fixing bugs. It is interesting to see that, the bug fixing phase cost them the most. Almost $330000 just to fix the bugs and stabilize for a total cost of half a million dollars.</p>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/SM_Unit_Economic_CaseStudy_4.jpg" alt="GitHub Logo" /></p>
<p>Figure 6: Agile Approach - Cost Summary. Source: [4]</p>
<p>Figure 6 shows cost summary of agile approach. In agile approach, they ran 20 weeks, that is half the time as traditional approach. And it only cost them $240,000 from a cost standpoint. Moreover, they were keeping up with utility, they were matching utility, they were keeping features fresh, they were releasing more often, and they were adjusting to the two requirements that were changing every week on an on-going basis.</p>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/revenue_comparison.png" alt="GitHub Logo" /></p>
<p>Figure 7. Revenue Comparison of Agile vs. Traditioanl development for Mugshot website case study. Source: [4]</p>
<p>From figure 7, by looking at gross revenue from forecasting standpoint, it looked like they are going to make a lot of money in a traditional sense. But as we get through, all the waste generated costed a lot in traditional approach. And it turns out that our revenue less depreciation is significant on the agile approach.</p>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/overall_comparison.png" alt="GitHub Logo" /></p>
<p>Figure 8. Overall Comparison. Source: [4]</p>
<p>Overall comparison is shown in figure 8. They generated $87000 in waste in traditional sense and the net income if compared shows what economic impact agile is capable of producing. Conclusion is it can range anywhere from 2:1 to 10:1 improvement in agile.</p>
<p>2) <strong>SAFe [8]</strong></p>
<p>This case study is about how SAFe applies lean-agile principles to give a broader economic view and to highlight key role economics plays in successful solution development. It talks about decentralizing decision making enabled by team’s knowledge on fundamental economic drivers for the solution. In particular, decision-making can happen in agreed-to financial context within the team.</p>
<p><img src="https://raw.githubusercontent.com/css566/css566.github.io/master/images/SM_Unit_Economic_CaseStudy_7.jpg" alt="GitHub Logo" /></p>
<p>Figure 9. SAFe constructs for economic decision-making. Source: [8]</p>
<p>Figure 9 illustrates how economic framework decision rules are embedded in SAFe. The components are as following:</p>
<ul>
<li>Lean agile budgeting: This is the very first decision and kind of an important one, as lean-agile enterprise moves from project-based cost-center accounting to a more streamlined budget process. In particular, cost for each program increment is largely fixed and scope is varied as necessary to stay within the PI budget.</li>
<li>Epic funding and governance: Allocating funds to the value streams is all well and good, but what happens when there are substantial concerns such as significant local investment concerns? The empowerment of funding requires responsibility to communicate any investments that are beyond routine.</li>
<li>Decentralize economic decision-making: With these elements of the framework in place, enterprise empowers people relevant context and knowledge to make content decisions at each level of the framework.</li>
<li>
<p>Job sequencing based on cost of delay: Every significant program has a host of new backlog features and capabilities just waiting to be implemented in order to increase efficacy of the solution. But SAFe is a flow-based system and flow-based system economics are optimized by job-sequencing rather than by theoretical job ROI. Picking the right next job is where the greatest benefit lies.</p>
</li>
<li><a href="/syllabus/2016/04/28/agile_economic_syllabus.html">Unit Home</a></li>
</ul>
</description>
<pubDate>Thu, 19 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/2016/05/19/agile_economic_case_studies.html</link>
<guid isPermaLink="true">http://css566.github.io/2016/05/19/agile_economic_case_studies.html</guid>
</item>
<item>
<title>Capability Maturity Model Integration</title>
<description><h2 id="overview">Overview</h2>
<p>Capability Maturity Model Integration (CMMI) is a process improvement training and appraisal program and service administered and marketed by Carnegie Mellon University (CMU) and required by many DoD and U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization.</p>
<p><img src="/images/cmmi_levels.png" alt="GitHub Logo" width="450" /></p>
<blockquote>
<p>CMMI Levels</p>
</blockquote>
<p><a href="https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Characteristics_of_Capability_Maturity_Model.svg/800px-Characteristics_of_Capability_Maturity_Model.svg.png">Source: CMMI levels</a></p>
<p>The process areas below and their maturity levels are listed for the CMMI for Services model:</p>
<h3 id="maturity-level-2--managed">Maturity Level 2 Managed</h3>
<ul>
<li>CM Configuration Management</li>
<li>MA Measurement and Analysis</li>
<li>PPQA Process and Product Quality Assurance</li>
<li>REQM Requirements Management</li>
<li>SAM Supplier Agreement Management</li>
<li>SD Service Delivery</li>
<li>WMC Work Monitoring and Control</li>
<li>WP Work Planning</li>
</ul>
<h3 id="maturity-level-3--defined">Maturity Level 3 Defined</h3>
<ul>
<li>CAM Capacity and Availability Management</li>
<li>DAR Decision Analysis and Resolution</li>
<li>IRP Incident Resolution and Prevention</li>
<li>IWM Integrated Work Managements</li>
<li>OPD Organizational Process Definition</li>
<li>OPF Organizational Process Focus</li>
<li>OT Organizational Training</li>
<li>RSKM Risk Management</li>
<li>SCON Service Continuity</li>
<li>SSD Service System Development</li>
<li>SST Service System Transition</li>
<li>STSM Strategic Service Management</li>
</ul>
<h3 id="maturity-level-4--quantitatively-managed">Maturity Level 4 Quantitatively Managed</h3>
<ul>
<li>OPP Organizational Process Performance</li>
<li>QWM Quantitative Work Management</li>
</ul>
<h3 id="maturity-level-5--optimizing">Maturity Level 5 Optimizing</h3>
<ul>
<li>CAR Causal Analysis and Resolution</li>
<li>OPM Organizational Performance Management</li>
</ul>
<p><img src="/images/cmmi_wheel.png" alt="GitHub Logo" width="600" /></p>
<blockquote>
<p>CMMI Cycle</p>
</blockquote>
<p><a href="http://www.webelite.com/images/cmmi_wheel.png">Source: CMMI cycle</a></p>
<h2 id="smbok-continuous-improvement20160526swbokhtmlcontinuousimprovement"><a href="/2016/05/26/SWBOK.html#continuousimprovement">SMBOK Continuous Improvement</a></h2>
</description>
<pubDate>Mon, 16 May 2016 00:00:00 +0000</pubDate>
<link>http://css566.github.io/2016/05/16/CMMI.html</link>
<guid isPermaLink="true">http://css566.github.io/2016/05/16/CMMI.html</guid>
</item>
<item>
<title>Lean Startups and Continuous Improvement</title>
<description><p><a name="content"></a></p>
<h2 id="overview">Overview</h2>