Lecture 6 - Method tailoring and contingency models (Sociomateriality) Flashcards
What are the major issues discussed in the article?
Source: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
- Flexibility
- Plan-based vs. agile software development
- Development of a contigency framework to account for benefits/costs of flexibility
To develop the contingency framework, it will be useful to consider in greater detail the arguments that depict the evolution of plan-based approaches in terms that parallel the historic transition from craft to industrial production of physical products. Mention the three industrial makings:
Source: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
- Pre-industrial Making
- Industrial Making
- Post-industrial Making
Explain the elements in the Pre-industrial Making.
Source: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
- Each product is produced individually (example: blacksmith/knife)
- Product shows core benefit (knife cuts) and novelty benefit (knife fits particularly for this customers needs)
- With each product: costs for reconfiguration, exploration and production
- Production processes is highly flexible but expensive
(Bullet points from slide 5, which sum up the article)
Explain the elements in the Industrial Making.
Source: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
- Concept of ‘mass production’, assembly line manufacturing (Ford T-model)
- Separation of phases:development vs. production
- All costs for reconfiguration and exploration occur at beginning of process and are shared over all produced units -> economies of scale (break-even point)
- Limited flexibility in process, only planned variations
- ISD: plan-based models
- Need to anticipate potential process variations and consider them when planning
Explain the elements in the Post-industrial Making.
Source: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
- Reduce costs for configuration and exploration using IS
- Run simulations instead of trial/error
- Similartopre-industrialmakingbutlowercostsduetoISsupport
- Novelty benefit / Novelty costs
- Advancements in technology allow for less expensive but still flexible products with high novelty benefits
In a contingency perspective, which two quantities are particular important?
Source: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
- Novelty benefit
- Novelty cost
(Which is the sum of reconfiguration and exploration cost
The contingency framework can be instantiated with
specific sources of benefit and cost to connect its
implications to practice and inform debates about the feasibility of agile practices.
See if you can talk about some of these sources.
Source: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
(See also slide 9)
Sources of Novelty benefit:
- Originality valued for its own sake
• Perceived elegance or artistry in a changed product or system - Potential for business differentiation
• Strategic differentiation (firm level)
• Brand differentiation
• Product differentiation - Difficulty discerning requirements ex ante (changes take into account requirements discovered in process, over time)
• Requirements difficult to see, know, or understand in advance
• Requirements become better understood over time
• Users know their requirements but have trouble communicating them to developers - Variety in requirements across users (customization for different users)
• Many users need something different (many customer segments); product changes satisfy needs of additional customers - Technology turbulence
• Requirements change often because business environment changes rapidly (due to technology advances, new entrants, disruptive business models, etc.); product changes track changing business requirements
Sources of Novelty cost:
- Lack of “pliability” in materials, process, equipment, or other means of production
• High cost to rearrange production in order to make something different (e.g., need to buy new equipment, reconfigure a factory, retrain workers) - High cost of time or materials consumed in creating something new
• Cost of nonuseful prototypes or practice runs
• Recycle, restock, or scrap costs (precious time or materials “wasted”) - Coordination burden
• Large organization or product (greater scope of follow-on changes necessary after an intended change)
• Complexity of organization or product (more discrete subparts to be potentially affected by changes)
• Product integrality (tight functional coupling or absence of modularity between components)
• Geographically distributed team (difficult or costly to
communicate changes and assess follow-on implications across distance) - Context-dependent exploration costs
• Serious consequences (e.g., loss of life, very great expense) when a prototype, pilot, or experiment “fails”
• Testing changes can be costly even if they can be made
inexpensively
Try and see if you can explain what this article is overall about: AUSTIN, R. D. & DEVIN, L. 2009. Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design.
Abstract:
In recent years, flexibility has emerged as a divisive issue in discussions about the appropriate design of processes
for making software. Partisans in both research and practice argue for and against plan-based (allegedly
inflexible) and agile (allegedly too flexible) approaches. The stakes in this debate are high; questions raised
about plan-based approaches undermine longstanding claims that those approaches, when realized, represent
maturity of practice. In this commentary, we call for research programs that will move beyond partisan disagreement to a more nuanced discussion, one that takes into account both benefits and costs of flexibility. Key to such programs will be the development of a robust contingency framework for deciding when (in what
conditions) plan-based and agile methods should be used. We develop a basic contingency framework in this
paper, one that models the benefit/cost economics described in narratives about the transition from craft to
industrial production of physical products. We use this framework to demonstrate the power of even a simple
model to help us accomplish three objectives: (1) to refocus discussions about the appropriate design of software development processes, concentrating on when to use particular approaches and how they might be usefully combined; (2) to suggest and guide a trajectory of research that can support and enrich this discussion; and (3) to suggest a technology-based explanation for the emergence of agile development at this point in history. Although we are not the first to argue in favor of a contingency perspective, we show that there remain many opportunities for information systems (IS) research to have a major impact on practice in this area.
Try and see if you can explain what this article is overall about: Ramasubbu et. al. 2011. Working Paper: Does Software Process Ambidexterity Lead To Better Software Project Performance
Abstract:
Plan-based and agile software development processes seem diametrically opposed in their approaches, with the former emphasizing discipline and control and the latter promoting flexibility and improvisation. Similar tensions in organizational contexts where efficiency versus flexibility considerations simultaneously jostle for management attention has led to the recognition that ambidexterity or the ability to manage seemingly conflicting demands is an important precursor to organizational success. In this study, we extend the idea of ambidexterity to software development processes and empirically examine the performance implications of the ability of software project teams to pursue process designs that simultaneously facilitate both control and flexibility. Utilizing data from a quasi-experiment involving 424 large commercial software projects of a multinational software services firm, we employ a potential outcomes empirical methodology to examine the causal linkage between software process ambidexterity and project performance. Our results show that projects that encountered frequent requirement changes, larger and complex code-bases, new technologies, higher levels of end-user engagements, and smaller, inexperienced teams tend to choose ambidextrous software process designs over a pure plan-based approach. We find that ambidextrous process design positively contributes to better project performance, including on the average about 9% higher productivity, 50% reduction in delivered defects, 12% reduction in internal defects, and 3% improvement in overall profitability. Complementing the archival data analysis with an in-depth qualitative study of the projects pursuing ambidextrous process designs, we enumerate the different mechanisms employed by the project teams to balance control requirements with needs for realizing flexibility. We discuss the implications of our results and elucidate potential pathways to achieve and sustain ambidextrous process designs in software firms.
What is Ambidexterity?
Source: Ramasubbu et. al. 2011.: Does Software Process Ambidexterity Lead To Better Software Project Performance
The idea of ambidexterity in organizations recognizes that demands in task environments are always to some degree in conflict and so there are always trade-offs to be made.
We define software process ambidexterity as the ability of a software development project team to pursue process designs that simultaneously facilitate both control and flexibility.
Which four key dimensions did they find?
Source: Ramasubbu et. al. 2011.: Does Software Process Ambidexterity Lead To Better Software Project Performance
In the later rounds of our discussions, we utilized this taxonomy to garner specific examples of balancing plan-based and agile aspects in process designs. Overall, the balancing tactics we uncovered can be organized along four key dimensions:
- Tradeoff shifting mechanisms
- Client relationships
- Artifact specification
- Project governance.
What was the main reason to alter composition of plan-based vs. more agile elements in the process?
Source: Ramasubbu et. al. 2011.: Does Software Process Ambidexterity Lead To Better Software Project Performance
The main reason to alter composition of plan-based vs. more agile elements in the process was ”pro- action” to changes, reaction to change, learning from change
WHAT DO YOU NEED TO DO AMBIDEXTROUS ISD?
Source: Ramasubbu et. al. 2011.: Does Software Process Ambidexterity Lead To Better Software Project Performance
- Structural and operational support mechanisms
- Organization-wide metrics irrespective of the methodology that is used
- Not all projects benefit equally: knowledge, experience, learning instead of just doing it
Try and see if you can explain what this article is overall about: Improving software organizations: agility challenges and implications. Boerjesson et.al. 2005.
Abstract
Purpose – The paper seeks to explore the impact of events in Software Process Improvement (SPI)
environments based on a longitudinal study of a requirements management initiative at Ericsson.
Design/methodology/approach – The paper presents the initiative from three perspectives – the
improvement initiative, the targeted software practices, and the environment.
Findings – SPI initiatives easily get interrupted, are side-tracked, and progress slowly due to
changing environments. While most practitioners are painfully aware of this, the SPI literature has so
far only touched on the issue. Agility principles would have helped Ericsson respond more effectively
to events that impacted the initiative. Development of agile SPI practices requires coordination and
alignment with other initiatives to develop agile software organizations.
Originality/value – SPI has been adopted by many organizations to help them to deliver quality
What does SPI stand for?
Software Process Improvement
