acsesim: agile and lean software development in practice...
TRANSCRIPT
A Teaching Case
ACSESim: Agile and Lean software development in
practice
A Research Report
presented to
The Graduate School of Business
University of Cape Town
In partial fulfilment
of the requirements for the
Masters of Business Administration Degree
by
Andries Maritz
December 2016
Supervised by: Fatima Hamdulay
Copyright UCT
i
PLAGIARISM DECLARATION
I know that plagiarism is wrong. Plagiarism is to use another’s work and pretend that it is one’s own.
I have used a recognised convention for citation and referencing. Each significant contribution and
quotation from the works of other people has been attributed, cited and referenced.
I certify that this submission is my own work.
I have not allowed and will not allow anyone to copy this essay with the intention of passing it off as his
or her own work
Andries Maritz
Copyright UCT
ii
ACKNOWLEDGEMENTS Many people contributed to not only the contents of the research report but also towards supporting my
own understanding and growth in the process. My wife, who had to keep the coffee flowing, has been an
invaluable resource. To all my colleagues who sacrificed their time to help me understand the world a
little bit better, thank you very much. To my friends and family – thank you for your patience and
understanding. Finally, thank you for the supervision and guidance from Fatima, who helped keep me
focused on the task at hand while giving me the freedom to explore the research in my own unique way.
Copyright UCT
iii
TABLE OF CONTENTS
Plagiarism Declaration ................................................................................................................................. i
Acknowledgements ..................................................................................................................................... ii
Table of Contents........................................................................................................................................ iii
Abstract ...................................................................................................................................................... vii
Glossary of Terms ..................................................................................................................................... viii
List of Abbreviations ................................................................................................................................... ix
List of Figures ............................................................................................................................................... x
List of Tables ............................................................................................................................................... xi
1. Introduction ......................................................................................................................................... 1
Case Theme, Purpose and Learning Objectives......................................................................................................... 1
Context ...................................................................................................................................................................... 1
Background to the Case Narrative .......................................................................................................................... 1
Learning Objectives .................................................................................................................................................. 5
Case Theme and Focus ............................................................................................................................................. 5
Limitations, Assumptions and Ethics .......................................................................................................................... 6
2. Theoretical Overview .......................................................................................................................... 9
Introduction .................................................................................................................................................................. 9
Software Development Methodologies ..................................................................................................................... 9
Classic Waterfall Method ................................................................................................................................. 10
Agile Software Development ................................................................................................................................. 11
Copyright UCT
iv
Lean Software Development ................................................................................................................................. 13
Use of the Kanban Method in Software Development........................................................................................ 17
Training ........................................................................................................................................................................ 20
Conclusion ................................................................................................................................................................... 22
3. Case Methodology ............................................................................................................................. 24
Introduction ................................................................................................................................................................ 24
Applicability of the Case ............................................................................................................................................ 24
Data Gathering ............................................................................................................................................................ 25
Internal validity ....................................................................................................................................................... 25
External validity....................................................................................................................................................... 26
Data sources ............................................................................................................................................................ 27
Limitations and Assumptions .................................................................................................................................... 29
Conclusion ................................................................................................................................................................... 30
4. Teaching Case .................................................................................................................................... 31
A Brief History ............................................................................................................................................................. 32
Software Development – Then and Now ............................................................................................................ 32
ACSESim Development............................................................................................................................................... 34
AutoSolve Buys ACSE.................................................................................................................................................. 36
From Concept to Delivery .......................................................................................................................................... 37
Tools of the Trade ................................................................................................................................................... 37
The Lifespan of a Feature or Bug ........................................................................................................................... 41
Mark’s Budget for New Hires .................................................................................................................................... 43
Systems .................................................................................................................................................................... 43
Copyright UCT
v
Training .................................................................................................................................................................... 44
Choices, Choices...................................................................................................................................................... 44
Exhibit 1: Glossary ...................................................................................................................................................... 45
Exhibit 2: The Lifecycle of an Issue ........................................................................................................................... 46
Exhibit 3: GUI Practices .............................................................................................................................................. 47
Exhibit 4: GUI Team Experience ................................................................................................................................ 49
5. Instructor’s Guide – Teaching Note .................................................................................................. 50
Case Synopsis .............................................................................................................................................................. 50
Target Group ............................................................................................................................................................... 51
Statement of Learning Objectives ............................................................................................................................ 52
Learning Objective 1 – Understanding Agile and Lean software development concepts ................................ 52
Learning Objective 2 – Complexities and implication of hiring new developers ............................................... 52
Suggested Readings .................................................................................................................................................... 53
Embracing Agile [Required] ................................................................................................................................... 53
Lean knowledge work [Required] .......................................................................................................................... 54
The Toyota way in services: The case of lean product development [Optional] ............................................... 55
Suggested Assignment Question .............................................................................................................................. 56
Discussion Outline and Time Allotment ................................................................................................................... 58
Overview.................................................................................................................................................................. 58
Learning Objective 1 ............................................................................................................................................... 59
Learning Objective 2 ............................................................................................................................................... 60
Debrief ..................................................................................................................................................................... 62
Conclusion ................................................................................................................................................................... 63
Copyright UCT
vi
6. Bibliography ....................................................................................................................................... 64
Appendix A: Informed Consent Form ................................................................................................ 68
Appendix B: Interview Questions ...................................................................................................... 69
Appendix C: Focus Group Questions ..................................................................................................... 70
Copyright UCT
vii
ABSTRACT
The teaching case presented aims to demonstrate to a cohort of operations students how Lean and Agile
principles are applied in a software development environment. Learning objectives include describing
the different methodologies, as well as the training aspects of getting new employees to assimilate into a
team utilising these practices. The case itself takes the reader through a scenario whereby a stretched
team is granted additional budget for new employees, leaving the protagonist to consider the implications
within the context of changes being experienced by the team. An overview of the relevant literature
discusses the various methodologies and training considerations for new employees.
An interview and participant-observation based approach were taken towards gathering data for the
research report. A focus group was also conducted with junior developers to consider several aspects of
how they experienced the learning process. In tandem, these methods aid in illustrating the target
organisation’s application of the software development and training methodologies.
Copyright UCT
viii
GLOSSARY OF TERMS
Many terms that are used by Agile practitioners are captured and described by the Agile Alliance, an
organisation that has been created by the creators of Agile (Beck et al., 2001). A summary of the terms
that were used in this document are given in Table 1 and is paraphrased from the Agile Alliance website
(“Agile glossary and terminology,” n.d.).
Table 1: Glossary of terms (Adapted from “Agile glossary and terminology,” n.d.)
Term Description backlog A list of tasks that must be completed for a project to be considered complete.
daily ("stand-up") meeting
A daily meeting with the goal of sharing information that is required for coordination. Meetings are meant to be short and are intended to identify blockages that are preventing team members from completing tasks.
iterations ("sprints")
A fixed period in which development activities take place. Teams determine their own iteration duration but are often between one and four weeks long.
kanban board Often a means of visualising and limiting the work-in-progress, a kanban board is a means to display the current state of a task in the development cycle
pair programming When a computer workspace is shared by two developers. One developer sits at the keyboard, while the other steers the direction. Developers will exchange roles every few minutes.
refactoring A process whereby the internal code is restructured (e.g. simplified, optimised or otherwise improved by the development team's definition) in such a way that the external behaviour is essentially the same.
source code These are algorithms that developers generate in various text files. Source code gets converted into an application that users can use by compilers or interpreters, whose function is to convert the human-understandable document into a computer- understandable language.
test-driven development
The process of developing software by first creating unit tests that fail (due to lack of functionality). As the features are implemented (or problems are corrected), the unit tests will begin to pass. Once all tests pass, development can be considered complete. This set of tests can be added to the automated test systems to ensure that future changes don't disrupt the expected behaviour of the change currently being made.
unit testing A fragment of a program that tests a very specific part of the source code that is produced. The tests are automatically run and, since each one tests a very specific code segment, can help the developers to narrow down problem areas.
workspaces Digital spaces (i.e. folders) where developers can make changes to the source code that are only seen within those spaces. This provides a safe environment for them to experiment with different extensions until the behaviour what they expect. When a feature or bug fix is complete, changes that have been made in a workspace can be integrated back into the shared source code that gets used when compiling the application.
Copyright UCT
ix
LIST OF ABBREVIATIONS CAD – Computer Aided Design
CAE – Computer Aided Engineering
GUI – Graphical User Interface
OEM – Original Equipment Manufacturer
SDLC – Software Development Life Cycle
WIP – Work in Progress
XP – Extreme Programming
Copyright UCT
x
LIST OF FIGURES
Figure 1: Team roles within ACSESim Development ................................................................................ 3
Figure 2: Typical process followed for a GUI or Solver team feature implementation .............................. 4
Figure 3: The classic waterfall method (adapted from Davis et al., 1988) ................................................ 10
Figure 4: An illustration of a typical kanban board ................................................................................... 20
Figure 5: Comparison Between Agile and Traditional Methods (Adapted from Rico & Sayani, 2009) .. 23
Figure 6: Team roles within ACSESim Development .............................................................................. 35
Figure 7: Typical process followed for a GUI or Solver Team feature implementation ........................... 36
Figure 8: ACSE GUI Team kanban board ................................................................................................. 38
Figure 9: Open plan work area (as seen from the kanban board) .............................................................. 40
Figure 10: The Test-Driven Development Cycle ....................................................................................... 42
Figure 11: The lifecycle of an issue ........................................................................................................... 46
Figure 12: Junior GUI Team members on current practices ...................................................................... 47
Figure 13: Years working on ACSESim .................................................................................................... 49
Figure 14: Years of prior work experience ................................................................................................ 49
Figure 15: Highest Qualification ................................................................................................................ 49
Figure 16: Possible sources of waste in the feature lifespan ...................................................................... 57
Figure 17: Informed Consent Form for Interviews .................................................................................... 68
Copyright UCT
xi
LIST OF TABLES
Table 1: Glossary of terms (Adapted from “Agile glossary and terminology,” n.d.) ............................... viii
Table 2: Principles behind that Agile Manifesto (Extracted from Beck et al., 2001) ................................ 12
Table 3: Summary of LeanSD Principles (Adapted from Kupiainen et al., 2015; Poppendieck &
Cusumano, 2012) ............................................................................................................................... 14
Table 4: Lean Product Development Principles (Extracted from Liker & Morgan, 2006) ....................... 15
Table 5: Comparison of LeanSD and Kanban principles (Extracted from Ahmad et al., 2013) ............... 17
Table 6: A Summary of the Kanban Method Best Practices (Ahmad et al., 2013) ................................... 19
Table 7: Extract of people-focused aspects of Agile and Lean software development ............................. 20
Table 8: Link between literature and learning objectives .......................................................................... 22
Table 9: The Ten Characteristics of Effective Cases (Extracted from Harling & Misser, 1998) .............. 24
Table 10: Suggestions for Conducting a Productive Interview (Adapted from Leedy & Ormrod, 2010) 28
Table 11: Ranking of GUI development practices ..................................................................................... 48
Table 12: Time allotment ........................................................................................................................... 58
Copyright UCT
1
1. INTRODUCTION Case Theme, Purpose and Learning Objectives
Context The 2000’s saw a large number of software development organisations transform their development
practices from traditional “heavyweight” methodologies to more “lightweight” methods (such as Agile or
Lean) (Dikert, Paasivaara, & Lassenius, 2016). Heavyweight methodologies, including the “traditional”
(Khan, Qurashi, & Khan, 2011, p. 441) waterfall or spiral methods, rely on up-front specifications,
followed by implementation and testing as a linear sequence of events (Williams, 2012). In contrast,
lightweight methodologies rely on iterative cycles of implementation that are argued to be more
adaptable to changes in requirements and have the ability to incorporate feedback earlier on (Khan et al.,
2011; Williams, 2012). Various lightweight methods have emerged, including Agile, Lean Software
Development (LeanSD), the Kanban method, Scrum and Extreme Programming (XP), amongst others
(Khan et al., 2011; Kupiainen, Mäntylä, & Itkonen, 2015).
The case of ACSE holds several examples of how Lean and Agile methods can be applied in a
commercial software development environment. A single case by no means provides an exhaustive set
of examples but will hopefully guide students to a better understanding of the principles behind software
development.
Background to the Case Narrative1
ACSE is a South African software engineering company that developed physics simulation software for
large OEM’s (“Original Equipment Manufacturers”). This simulation software helped the OEM’s with
the design and analysis of the physical performance of the equipment that they produced. Customers
ranged from aerospace firms that designed aeroplane parts, automotive design teams and even a few
defence contractors working on military projects. The company was originally founded by two fresh PhD
1 Note that details of the organisation, its products and its history have been modified to protect the
anonymity of the organisation and its employees. Everything else is factual.
Copyright UCT
2
graduates in 1991 as an engineering consulting firm. They quickly discovered that more advanced tools
were needed to help them analyse the complex environments that their customers operated in.
The founders realised that there was a market to provide such tools, as a software package, to their
customers. They consequently partnered with a student completing her research on simulation
technology and commercialised the tools developed to aid their work as a software product under the
name ACSESim in 1995. This product became the hallmark of ACSE. In 2015, more than 20 years
later, ACSE was fully acquired by AutoSolve, an American simulation software company that developed
and maintained a range of physics simulation software products. Both ACSE and AutoSolve provided
computer-aided design and engineering (or CAD and CAE) tools to engineering companies.
AutoSolve’s intent in acquiring ACSE was to round off the offering that AutoSolve could provide to
their customers. The founders of ACSE and its shareholders agreed that they could accomplish much
together and accepted the offer.
ACSESim provided both the computational solver technology (i.e. the number-crunching core that
calculated the results of a physics simulation problem) as well as a graphical user interface (or GUI)
that helped users to both configure their analyses and to view the results from the simulation. To
illustrate the nature of the role of each team, consider the analogy of a search engine. A user types a
phrase into a simple text field, which then churns out a list of possible websites that might be relevant.
The search bar would be the GUI team’s responsibility and serves to make the site easy and accessible to
use. In the background, sophisticated search algorithms would take the inputs and provide a list of
possible websites. These sophisticated algorithms would be the work of a solver team, while the GUI
would then display these sites in a way that is easy for a user to understand. Both these teams need to
work hand-in-glove as it were to develop a well-functioning, usable product.
So, although the Solver and GUI development teams worked towards the common goal of providing the
user with an efficient and accurate solution to their problems, each team was focused on a different
aspect of this goal and made use of different development processes to achieve them. In addition, a non-
development program management team (or PM Team) was involved with providing industry and
customer context. Very often, this included refining specifications that addressed customer needs that
served as inputs to the development teams. Figure 1 shows the structure of the different teams that
contributed in some way or another to ACSESim’s development efforts.
Copyright UCT
3
Figure 1: Team roles within ACSESim Development Together, these teams planned and contributed to developing new versions of ACSESim in regular
release cycles. A release cycle comprised features and bug fixes that were deemed necessary for the
stability of the product or would be useful to customer projects. The decision for what to include was
informed by input from account managers, users, development teams as well as the discretion of
management.
Each product under AutoSolve had a set of teams that coordinated the development for their product and
reported back to management. Team leaders would consider the various inputs and discuss what they
felt were feasible, with the overarching focus being to win or retain customers by simplifying, extending
or improving how customers analysed and designed their products. Major versions of ACSESim were
released on a roughly annual cycle, with two or three minor feature releases in between and additional
bug fix releases on an ad hoc basis. Customers would normally receive an update to ACSESim once
every one to two months.
Copyright UCT
4
Figure 2: Typical process followed for a GUI or Solver team feature implementation Figure 2 shows the process for how a typical feature or bug fix would be implemented in ACSESim. At
the outset, it should be noted that the flow is not one-directional as indicated. The person responsible for
the issue during a phase could at any time transition the issue to a previous state. Typically, though,
specifications were generated by the PM Team (i.e. “To Do” à “Development Ready”) and prioritised
for a release cycle in small, logical groupings. A feature release would contain a set of such groupings,
with major releases containing the changes that may have major implications for how customers use the
product. Ad hoc bug fix releases were shipped when they were deemed necessary and seldom contained
new features or interface changes.
Issues that were ready for development got placed onto the GUI team’s backlog and waited for a
developer to become available. Developers were limited to working on two issue groupings at a time, so
could only start on a new grouping (i.e. “In Progress”) once one of their active issue groupings were
completed. To complete an issue grouping, an automated set of regression tests were run to ensure that
their changes didn’t cause unintended problems in other parts of the application (i.e. “Validating”). Once
these automated tests passed, a quality assurance tester could review that the feature had been
implemented as specified (i.e. “Testing”).
GUI Team activities included development and testing. QA would send an issue back to a developer
when they felt that the specifications weren’t adhered to, that the change was difficult to use, if other
aspects of the application were inadvertently broken or if there was a deterioration in performance.
The focus was on the GUI team’s approach to Agile and Lean software development techniques. The
decision to hire more employees on the GUI team provided the catalyst in the narrative that has lead to
To Do Development Ready
•Specifications complete
•Waiting for developer capacity
In Progress Validating Testing
•Waiting for specifications
•Pending queries
•Information gathering
•Writing tests (TDD)
•Development •Progress in
daily standup •Progress in
weekly meeting
•Local acceptance tests
•System integration tests
•Feature complete
•Usability •Pushes to
updater
Copyright UCT
5
the management dilemma for the GUI team manager to reassess which processes were appropriate in the
new environment.
Learning Objectives The case provides an example of how Lean and Agile software principles are applied in a commercial
software development environment. It serves as a typical working example where students are expected
to see the benefits of current practices, room for improvement and be exposed to some of the
complexities that are present when making changes to development practices. The managerial problem
that needs to be present for the teaching case (Harling & Misser, 1998) is that of evaluating whether,
after the change in company ownership, current development and people management practices need to
be amended to adjust to the priorities of the new parent organisation.
Students are expected to gain insight into the following learning objectives (LO’s):
LO1 [Concepts]: To gain an understanding of how Lean and Agile principles can be applied
in a software development environment.
LO2 [Training]: To consider the best way to manage new hires so that they can become
productive in a Lean or Agile software development environment.
Case Theme and Focus By looking at ACSE, students are expected to learn about how Lean and Agile software development
practices manifest in a commercial environment. Rigorous academic studies on the matter are scarce
(Pernstål, Feldt, & Gorschek, 2013), although case studies such as the experience of BBC Worldwide
give an indication of commercial practices (Middleton & Joyce, 2012).
The teaching case explores the Lean and Agile software principles that have been applied to ACSESim’s
development processes. The theme of the case is to introduce Lean and Agile principles and to identify
how the principles manifest in the operations of the team (LO1 [Concepts]). Students are expected to
consider the implications of hiring new employees and coaching them into and Agile and Lean mindset
(LO2 [Training]).
The focus of the case is for students to consider how they would respond when placed in a similar
situation and how they would manage the complexities involved with teaching the philosophy of
development to new hires. Complexities include a lack of formality in the fundamental definition of the
Copyright UCT
6
principles. As a construct, agility is “highly multifaceted and has been used by many different people to
refer to very different phenomena” (Conboy, 2009, p. 330). Another is the fact that training new people
involve time and energy from managers and other senior developers, who serve as coaches in the process
(Liker & Ballé, 2013). A study by Mellon Financial Corp. concluded that for professional workers, up to
20 weeks was required before a new employee would be working at capacity (Rollag, Parise, & Cross,
2005).
Limitations, Assumptions and Ethics
Case studies are a “reflection of reality” (Harling & Misser, 1998, p. 125) that, while making it topical to
a class of students, implies that real issues are being considered. As such, ethical concerns such as
organisational approval and fair research practices need to be carefully considered. A single case may
also be limited in scope, seeing that it is effectively a research analysis conducted on a single sample
point. Additional limitations specific to the ACSE case are also considered and the assumptions
stipulated.
ACSE and AutoSolve products focused on computer-aided design (CAD) and engineering (CAE)
applications. The software development industry or CAD is involved with applications ranging from 3D
modelling, 3D printing, augmented and virtual reality, simulation, manufacturing, to name a few
(“Worldwide CAD trends 2016 survey results,” 2016). Furthermore, CAD software is then itself a
subset of the full range of software development industries which have become ubiquitous along with the
use of computers in daily life. As such, one limitation of the case in the greater context of software
development is that it merely represents a subsection of a subsection of the software development
industry. Different organisations often find a different mix of methods that is deemed appropriate for
their context (Ahmad, Markkula, & Ovio, 2013) and as such this case should be seen as an example, not
a guideline.
The research that was conducted was confined to operational aspects of software development, despite
the understanding that culture plays a role in the adoption of various practices (Al-Baik & Miller, 2015;
Lindgren & Münch, 2016; Trimble & Webster, 2013). This was in part to limit the scope of the research
to a manageable level, although an ulterior motivation is the lack of formal permission from the
organisation to conduct research regarding cultural aspects. It is assumed that any cultural impacts
Copyright UCT
7
resulting from ACSE’s acquisition had a negligible impact on the development practices of the software
development teams.
The main ethical concerns with respect to case research are to avoid bias and to protect human subjects
(Yin, 2014). A test for whether a researcher is biased is the degree to which they are willing to consider
opposing views and evidence. However, this teaching case merely illustrates how a variety of principles
manifest in practice, without the need to advance any particular argument. This neutrality reduces the
risk of bias and the need to defend or promote the researcher’s view. Participant-observation does,
however, introduce the risk of unintentionally manipulating the unit of observation (Yin, 2014) or to
become too vested in the case to make an accurate assessment (Leedy & Ormrod, 2010).
Additional data was collected by means of shorter semi-structured interviews with individuals who either
forms part of the design of the software development processes or who participate as resources in the
process. To protect the interviewees from harm, care was taken to ensure that the following held true:
• Permission was granted by each interviewee to conduct the interviews after clarifying the purpose
of the research;
• The anonymity of their identities had been ensured;
• Tentative organisational permission was granted with the understanding that, should the research
be deemed harmful to individuals, permission could be revoked.
No personal or sensitive information was collected, ensuring that the focus of the research remained on
the learning objectives rather than the people involved in the process. This limited the scope of the
teaching case entirely to the operational processes of software development and may omit the influence
of cultural or individual circumstances on such processes. It should also be noted that the concept of
“culture” is flexible. Cultural aspects that specifically pertained to how software developers perceived
and practices the principles of development were included. Aspects of culture pertaining to employee
satisfaction or the impact of non-development aspects at the organisation were strictly omitted.
In summary, the limitations, assumptions and ethical considerations considered were those that are
fundamentally associated with case study research. To an extent, concerns were mitigated by the nature
of a teaching case, which lends itself to reduced bias and less focus on reporting empirical data. Ethical
Copyright UCT
8
concerns were mitigated by the nature of the teaching case itself, which was focused on illustrating
practices rather than highlighting individual failures or sensitive information.
Copyright UCT
9
2. THEORETICAL OVERVIEW Introduction
The learning objectives require that an understanding of Lean (including the Kanban method) and Agile
software development principles be cultivated. Students and managers are encouraged to use their
increased appreciation of both the benefits and limitations of the principles to make informed decisions
regarding which methods would be the most appropriate for their environment. When introducing new
employees into this environment, consideration should be given as to how they can be taught to adopt the
best practices of the organisation and getting them to a productive level as quickly as possible.
Decisions need to be made based on, among other considerations, whether managers believe a strategy
will fit their organisational culture, whether it will be scalable and whether it will be sustainable in the
long term (Gregory, Barroca, Sharp, Deshpande, & Taylor, 2016; Lindgren & Münch, 2016). The
descriptions of the various methods will support LO1 [Concepts], while the discussions surrounding the
training of new employees will support LO2 [Training].
Software Development Methodologies
The software development life cycle (SDLC) refers to the set of processes that carries a project from a
point of conception to a point of delivery and/or maintenance (Khan et al., 2011). Two broad categories
of methodologies are used to classify methods, namely heavyweight and lightweight methodologies.
The term “lightweight” was applied to frameworks that were being explored in the 1980’s and 1990’s
that were more adaptive, had fewer rules and were generally simpler than the traditional practices used at
the time (Rigby, Sutherland, & Takeuchi, 2016b). Heavyweight methodologies (possibly retroactively
named as the opposite of “lightweight” methodologies) include methods such as the waterfall or spiral
methods, which relied on up-front specifications, long SDLC’s and large internal project handovers that
resembled a “relay race” (Rigby et al., 2016b, p. 3). Lightweight methods strive to shorten the SDLC
and incorporate customer feedback. Agile and Lean methods form part of the “lightweight” category of
development and emerged to provide an alternative to their heavyweight predecessors (Kupiainen et al.,
2015; Middleton & Joyce, 2012).
Copyright UCT
10
Classic Waterfall Method Until the mid-1990’s, the classic waterfall method was prevalent throughout the software development
community (Davis, Bersoff, & Comer, 1988; Williams, 2012). Davis (1988) reports that this method has
been defined as early as the 1970’s and was designed to help organisations manage increasingly complex
development projects. Due to the waterfall method’s prevalence and a quintessential example of a
heavyweight method, it is worth commenting on its attributes for comparison to the more lightweight
methods are considered. It is summarised as a development method “in which detailed requirements and
execution plans are created up front and then passed sequentially from function to function.” (Rigby,
Sutherland, & Takeuchi, 2016a, p. 7).
Figure 3: The classic waterfall method (adapted from Davis et al., 1988) With the waterfall method, each phase depicted in Figure 3 is completed sequentially. An analogy for
the waterfall method might be an industrial assembly line, where each part of the process is well-
understood and defined before production starts and equipment is designed to facilitate the creation of
the product. A large focus is placed on the early requirements and design phases (i.e. the first four
‘waterfalls’), resulting in a large body of detailed documentation and planning (Khan et al., 2011). Such
Copyright UCT
11
plan-driven methodologies encourage an up-front specification of precisely what the system is required
to do, before implementing the design (Davis et al., 1988). The authors argue, due to the plan being
fixed before commencing with implementation, that managers had a means to track progress and
timelines. This enabled them to detect deviations and slippages and to rectify problems where necessary.
It is argued that heavyweight methods such as the classic waterfall method are still best suited to larger
projects within organisations that have rigidly defined processes (Sommerville as cited in Perkusich,
Soares, Almeida, & Perkusich, 2015).
Criticisms of heavyweight methods are that they tend to run behind schedule, cost more than anticipated
and often fail to meet customer requirements (Davis et al., 1988). An example from industry was
BBC Worldwide that implemented a Lean approach to development, which focused on releasing smaller
features more often. In their case, they managed to reduce the average time to develop a feature by 73%
(which is expected due to the smaller feature size), but also the variance of developing features by as
much as 78% over a nine-month period (Middleton & Joyce, 2012). This was as opposed to their
traditional plan-driven methodology that is presumed to have been a variant of the waterfall approach.
Agile Software Development At a time when heavyweight methodologies were prevalent, the problems related to a plan-driven
approach were equally prevalent in the software development community (Williams, 2012). Williams
reported that a smattering of “rogue” consultants was deviating from the norm and helping to rectify
problems by varying the commonly accepted best practices. In February 2001, seventeen such
consultants convened in Snowbird, Utah at a ski resort. Their various approaches were discussed and
debated in depth. What resulted from these discussions were that they published the Manifesto for Agile
Development (Poppendieck & Cusumano, 2012; Williams, 2012).
The Agile Manifesto consolidated the principles that the group deemed important for software
development. Their values are listed below and the twelve Agile principles are given in Table 2 (Beck et
al., 2001):
“We are uncovering better ways of developing software by doing it and helping others do it. Through this
work we have come to value:
• Individuals and interactions over processes and tools
Copyright UCT
12
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.” (Beck et al.,
2001)
Table 2: Principles behind that Agile Manifesto (Extracted from Beck et al., 2001)
Agile Principle 1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software 2 Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage. 3 Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale. 4 Business people and developers must work together daily throughout the project. 5 Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done. 6 The most efficient and effective method of conveying information to and within a development team
is a face-to-face conversation. 7 Working software is the primary measure of progress. 8 Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely. 9 Continuous attention to technical excellence and good design enhances agility. 10 Simplicity – the art of maximising the amount of work not done – is essential. 11 The best architectures, requirements, and designs emerge from self-organising teams. 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behaviour accordingly.
When one considers the Agile Manifesto, it should be noted that no specific practices, techniques or tools
are suggested. Quite the contrary, the first value is to value individuals and interactions instead of
inflating the value of specific practices. As such, it was up to practitioners to interpret the principles into
implementable techniques such as Scrum or Extreme Programming (XP) (Poppendieck & Cusumano,
2012). Another point to note is that many lightweight methods were in existence before the 2001
promulgation of the Agile Manifesto. The developers from these different schools came together and,
Copyright UCT
13
after the Agile Manifesto, agreed that all methodologies that conformed to the values of Agile would fall
under the umbrella of Agile and be recognised as an Agile technique (Rigby et al., 2016b).
The practice of Extreme Programming was of the first to gain widespread recognition (Williams, 2012).
XP leveraged practices including automated unit testing; pair programming; continuous refactoring;
collocated teams (Kupiainen et al., 2015). A glossary of terms has been provided for clarification of the
concepts (see Table 1 on page viii). In addition, development took place in close collaboration with the
customers, ensuring that the software adheres to the customer’s requirements and that the customer can
contribute to trade-off decisions that will add the most value. Although evoking much interest after
inception, XP was eventually supplanted by Scrum as the dominant Agile method of interest (Dikert et
al., 2016; Dingsøyr & Lassenius, 2016).
Scrum is comprised of a set of practices that include daily stand-ups, sprint iterations, demonstrations of
working software and sprint reviews (Kupiainen et al., 2015). It was introduced by Schwaber (1995),
designed specifically to compensate for the shortfalls of other methodologies that were available at the
time. These included the inability of methodologies to respond to the environment, a lack of team
flexibility, a lack of team creativity, limited knowledge transfer and poor success rates. The term was
borrowed from Takeuchi and Nonaka’s comparison of product development with the game of rugby in
their Harvard Business Review article titled “The new new product development game” (Takeuchi &
Nonaka, 1986) and extended to software development (Rigby et al., 2016b).
A criticism of Agile methods is that it is limited to the practices of managing software development.
However, as with the origins of Scrum as an adaptation of product development methodologies, these
methodologies can be shown to have borrowed from other disciplines ranging from product development
to the game of rugby. Even so, user interaction and system architecture design are commonly considered
to be outside of the scope of Agile methods. This lends Agile methods to being well-suited to the
management of software development projects but may be insufficient with respect to the design of
software (Poppendieck & Cusumano, 2012).
Lean Software Development Taiichi Ohno formalised the Toyota Production System (TPS) with the publication of “Toyota
Production System: Beyond Large-Scale Production” in 1988 (Pernstål et al., 2013). A large number of
modern manufacturing organisations utilise some measure of Lean principles or have a “Lean initiative”
Copyright UCT
14
(Liker & Morgan, 2006). Despite the widespread adoption of Lean in the manufacturing, it was only
after the publication of “Lean Software Development: An Agile Toolkit” in 2003 by Poppendieck and
Poppendieck that Lean was popularised as a methodology in the software development industry
(Poppendieck & Cusumano, 2012). Interestingly, the title suggests that Lean and Agile are closely
related, where one can be considered a subset of the other. Wang et al. (2012) summarise that there are
varying viewpoints within the literature. While some believe that Lean provides the foundation as to
why Agile works, others believe that they are distinct philosophies. The latter group consider Lean to
provide the tools necessary for Agile to be scaled from a team to an organisational level.
Within the Lean Software Development (LeanSD) methodology, seven principles are widely recognised
and summarised in Table 3 (Kupiainen et al., 2015; Poppendieck & Cusumano, 2012).
Table 3: Summary of LeanSD Principles (Adapted from Kupiainen et al., 2015; Poppendieck &
Cusumano, 2012)
Lean Principle 1 Optimise the whole; See the whole picture 2 Eliminate waste 3 Build quality in 4 Learn constantly; Amplify learning 5 Deliver fast 6 Engage everyone; Empower the team 7 Keep getting better; Perfection
Arguably the most notable of the principles is that of eliminating waste (Middleton & Joyce, 2012),
which naturally leads to the question of how one defines waste in a software development environment.
The activities of a development team can be divided into value adding tasks, required but non-value
adding tasks, as well as non-value adding tasks (Wang et al., 2012). For the purposes of this discussion,
waste will be defined as those tasks that do not add value to the customer or expand the knowledge base
of the team (Poppendieck & Cusumano, 2012). Examples of waste in this context include unrequired
features, idle waiting, work in progress (or “WIP”), defects (informally referred to as “bugs”), rework or
underutilised creativity of the development team (Wang et al., 2012). It is worth noting that waste is
defined differently than it would be within a manufacturing context. This is interesting because it
Copyright UCT
15
illustrates how the principles are applied in a metaphorical sense and can manifest in various abstract
ways (Middleton & Joyce, 2012).
More broadly, Lean principles are also being applied to knowledge work in general (Liker & Morgan,
2006). The authors reframed the principles from Lean manufacturing into a product development
paradigm (as opposed to the production system paradigm) and summarised key findings. Table 4
summarises these principles in three broad categories, namely: processes, people and tools. These
principles are presented in a format that is distinct from those provided in Table 3, although on closer
inspection they can be seen to be roughly equivalent. Liker and Morgan’s presentation does lend itself to
more direct interpretation due to a higher granularity breakdown. Note that even though the authors
intended the article to focus on physical product development, that Table 4 makes no specific reference
to the type of product being developed.
Table 4: Lean Product Development Principles (Extracted from Liker & Morgan, 2006)
Process Principles
Determine what value means to the customer.
Once the value is defined from the perspective of the customer, waste can be defined as all activities that fail to add value. Lean is a continuous effort to reduce all waste and maximise value to the customer.
Spend time on exploring alternatives while you have the time to do so.
When rushing through the divergent thinking phase, one runs the risk of defining the problem incorrectly or to not explore sufficient solutions to the problem. By spending enough time defining the problem up front, the benefits compound throughout the remainder of the cycle.
Level the product development flow. Once a processed has been stabilised, one can predict and plan for changes in workload. Such planning would strive to ensure a consistent and sustainable workload throughout the development cycle. With flexible labour pools, unavoidable peak times can be managed.
Standardise processes. Continuous improvement hinges on the principle that processes can be standardised and refined. By utilising standardisation, benefits including a reduction in variation, increased flexibility and increased reliability can be obtained.
Copyright UCT
16
People Principles
Cultivate a “Chief Engineer System” This individual is the confluence for all product and process interactions. They take responsibility for the entire product development process and have the final say in what may or may not be changed.
Find a balance between deep expertise and cross-functional integration.
Finding a balance between having employees cultivate a deep expertise and coordinating goals across functional lines ensures that skilled resources are working in tandem towards a common goal. This direction is provided by the chief engineer, who always has the “big picture” in mind.
Cultivate a high level of specialised expertise in employees.
Through exposure to the gemba, employees should be supported to cultivate a deep level of understanding of the processes that they are involved in.
Extend the product development processes into supplier networks.
Suppliers that have a similar set of capabilities and culture can more fully integrate into one’s own processes. The supplier becomes a partner and an extension of the organisation, which reduces barriers to communication and efficiency.
Continuous improvement should be built in.
Continuous improvement is only possible if the organisation can retain lessons learned from previous experiences.
A culture of excellence and improvement should be cultivated.
Employees at all levels should be invested in relentlessly improving themselves, the products and the processes that drive product development. This kaizen culture leads to excellence in all areas.
Tools and Technology Principles
Technology should be adapted to serve the people and processes in the organisation.
Technology should be continually refined to serve the needs of adapting processes and employee needs. Through continuous improvement, the tools that serve people and processes should be customised to the extent that it better serves the improvements being made.
Communicate visually. The more simply information can be communicated to the organisation, the more easily goals can be aligned. Problems can be identified sooner and multiple perspectives can be employed to address them.
Copyright UCT
17
Facilitate standardisation and organisation by leveraging the most powerful tools that are available.
Standardisation of processes is key to continuous improvement and organisational learning. Use tools that are simple, sustainable and powerful to achieve this.
Wang et al. (2012) suggest that Lean software development principles speak to the basic concepts behind
Lean thinking itself and that these principles manifest through specific practices. A principle is defined
here as “underlying truths that do not change over time or space” (2012, p. 1290), while a practice is “the
application of principles to a particular situation and should differ from one environment to the next and
change as the situation evolves” (2012, p. 1290). To summarise, the authors define practices as the
application of principles that speak to the concepts of value, the value stream, flow, pull and the
continuous strive for perfection.
Use of the Kanban Method in Software Development
In 2009 Cory Ladas published “Scrumban: Essays on Kanban Systems for Lean Software Development”
which explained how kanban can be used in software development to track work and more specifically,
limit the work in progress (WIP). In 2010 David Anderson published “Kanban” which concentrated on
creating flow in software development (Poppendieck & Cusumano, 2012). The term “kanban” has its
origins from the Toyota Production System and means “signboard” (Ahmad et al., 2013). Due to its
origins, it can be seen as an element of the set of Lean principles and forms part of a “pull” system which
is designed to facilitate flow (Wang et al., 2012). Within software development, the Kanban method has
emerged as an approach for implementing Lean principles. The set of Kanban principles is summarised
Table 5 and compared to those of LeanSD principles (Ahmad et al., 2013; Al-Baik & Miller, 2015).
Table 5: Comparison of LeanSD and Kanban principles (Extracted from Ahmad et al., 2013)
LeanSD Principles Kanban Principles • Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimise the whole
• Visualise the workflow
• Limit work in progress
• Measure and manage flow
• Make process policies explicit
• Improve collaboratively (using models and the scientific method)
Copyright UCT
18
At first glance, it appears there is little overlap between the principles. However, the Kanban principles
speak to waste, quality, creating knowledge, respecting the input of people and optimising the whole. It
could also be reasoned that limiting the work in progress (WIP) could serve as a deference of
commitment and that by eliminating waste, faster delivery is possible. This observation supports the
argument that the Kanban method of software development could serve as a mechanism through which
to implement Lean principles.
The Kanban method relies on the fact that WIP is limited. When this is done, it becomes possible to
determine whether distributed flow is achieved and where potential bottlenecks are forming
(Poppendieck & Cusumano, 2012). To facilitate this, a kanban board is used. A kanban board represents
the value stream of the software development progress, where each value adding step is represented by a
column on a board. Kanban boards can either be physical or digital but serve to make the value stream
visible and give a visual overview of the state of development (Middleton & Joyce, 2012; Poppendieck
& Cusumano, 2012). As a communication tool, Kanban boards are similar to Scrum boards. However,
where Scrum boards are time-boxed, Kanban boards limit the WIP (Al-Baik & Miller, 2015). This
makes the Kanban board a tool to facilitate a “pull system”, whereby work is only conducted when there
is the capacity to do so (Al-Baik & Miller, 2015; Kupiainen et al., 2015). This subtle distinction
illustrates the notion held by various authors that the Kanban method can be used as a supplementary tool
to improve the flow of existing methodologies, rather than necessarily being a unique methodology in
itself (Ahmad et al., 2013; Kupiainen et al., 2015).
Kanban boards can also be extended to beyond the software development environment to include
upstream or downstream value processes such as marketing or business analysis (Al-Baik & Miller,
2015). In the example posed by BBC Worldwide, the “ideation pipeline” was also made visible to the
team to help trigger creative suggestions from the team (Middleton & Joyce, 2012). This Kanban board
contained a summary of customer proposals that needed to be divided into deliverable units. Once work
transitioned from one side of the board to the next, these units fed into the development Kanban board
and processed by the development team. Figure 4 is a depiction of a typical Kanban board. In practice,
these boards are often created on a physical whiteboard or by using an electronic equivalent (Rigby et al.,
2016a). For physical boards, sticky notes are used to represent tasks, often using different colours to
denote the task type. Columns can be given a maximum number of items, which is known as a WIP-
Copyright UCT
19
limit. These boards are consulted on a daily basis and any bottlenecks or problems discussed and
rectified (Ahmad et al., 2013; Middleton & Joyce, 2012). To this end, the Kanban board again serves to
make problems and flow visible so that the team can identify and fix problems as early on as possible.
Table 6: A Summary of the Kanban Method Best Practices (Ahmad et al., 2013)
The Kanban Method Best Practices Protect teams from external tasks during the actions phase.
Consider ways of eliminating work in progress.
Create a culture of collaboration on solving tasks and problems.
Use a visual board to make low team orientation visible and improve the shared mental model.
Encourage team members to provide feedback to each other.
To create value, note that all non-value added work is not waste and that some non-value added waste is necessary.
Have senior managers constantly work on value creation for the organisation, allotting time to teach and solve technical problems with teams. In short, provide technical leadership.
Provide a clear vision for the whole team.
Ahmad et al. (2013) summarised the best practices as they interpreted the literature for applying the
Kanban method (see Table 6). The Lean heritage of the method is strongly represented throughout
themes that include creating a continuous learning environment, of eliminating waste, of seeking ways to
maximise value adding activities and to make faults visible.
Copyright UCT
20
Figure 4: An illustration of a typical kanban board
Training
In operational terms, the software methodologies demonstrate different attributes that may be of benefit
when applied in the correct context. What is interesting to note, is the focus on people in an Agile or
Lean environment. Table 7 extracts several of the principles from the development methodologies that
focus on the people doing the work. It concentrates on empowering the team, continuous learning and
the focus on learning. While abstract and not confined to a specific set of practices, this does emphasise
that software developers need to be trained to think in a manner that is commensurate with the
methodological environment within which they operate.
Table 7: Extract of people-focused aspects of Agile and Lean software development
Method People aspect
Agile The best architectures, requirements, and designs emerge from self- organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
LeanSD Cultivate a “Chief Engineer System” Find a balance between deep expertise and cross-functional
Copyright UCT
21
integration. Cultivate a high level of specialised expertise in employees. Extend the product development processes into supplier networks. Continuous improvement should be built in.
Kanban Method A culture of excellence and improvement should be cultivated. Protect teams from external tasks during the actions phase.
When newcomers join a team, a key challenge is that they can be “a net drain on productivity, drawing a
salary, incurring training and orientation expenses, and consuming co-worker’s time without providing
much in return” (Rollag et al., 2005, p. 35). The authors continue to describe several common
misconceptions with respect to “onboarding” and conclude that much of the organisational knowledge is
not transferred through documentation, training or mentorship. Instead, they argue for helping
newcomers develop a “network of information relationships” where they can learn from several
employees in a variety of contexts. To facilitate this, they propose that a manager helps to cultivate a
relationship with a “buddy” that can help them assimilate into the culture and use this social anchor in
developing their own networks.
Many companies have attempted to replicate the success of companies such as Toyota by copying their
practices, but by neglecting to understand why the practices are effective (Liker & Ballé, 2013). In
summary, the authors suggest developing people through active listening, effective verbal and written
communication, building a culture of trust, teaching core competencies to others, challenging
perspectives by questioning and to follow up by coaching. When considering these views in conjunction
with those from Rollag et al. (2005), it might appear that there is a disjoint in common wisdom. While
one argument suggests that managers develop newcomers by helping them to build a network within the
organisation, the other suggests a much more personal interaction. However, it could be argued that an
effective manager should consistently be developing their team and not just the newcomers. This means
that the effective manager will have trained their team to be able to facilitate the mentorship and
coaching that a newcomer would require. In short, teach the team to teach the newcomers.
A study on the problems that are experienced by fresh university or college graduates that are placed in a
software development concluded that the newcomers had a sufficient level of training when it came to
development and design acumen, but were lacking in their ability to effectively communicate,
Copyright UCT
22
collaborate with others and to orientate themselves (Begel & Simon, 2008). This insight has implications
for the university education system, but also gives a starting point for approaching hiring developers
straight out of university from a firm perspective. For instance, considering communication and
collaboration skills during the interview process could help to choose candidates that demonstrate these
strengths in addition to the technical skills that are expected. A reliance on social skills (such as
communication skills) was also highlighted as a key challenge by Conboy et al. (2010), who
recommended that training material should be developed specifically to enhance social skills, based on
applicable situations faced by developers in the team.
When considering the success at Toyota, it has been observed that they “teach workers to develop
solutions, not just to solve problems” (Soliman, 2015, p. 28). They believe in hiring people who have
demonstrated a commitment towards self-improvement and then developing these people by letting them
learn by doing the work. In the pursuit of teaching new employees to principles behind Agile, it has been
recommended that multiple members of a team get sent to conferences or training events (Conboy et al.,
2010). Where an organisation has multiple teams or departments practising Agile methodologies, the
core values can also be learned by observing one another.
Conclusion
From the discussions, there is conceptual overlap between the various software development
methodologies, especially between the more contemporary lightweight methodologies. In practice,
organisations often employ a hybrid that combines elements from the lightweight methodologies that is
customised for their needs (Kupiainen et al., 2015). Table 8 summarises how the concepts that have
been discussed link to the learning objectives.
Table 8: Link between literature and learning objectives
Learning Objective Link to the literature To gain an understanding of Lean, Agile and Kanban software development
LO1 how Lean and Agile methodologies were discussed. Their origins, differences
[Concepts] principles can be applied in and similarities were considered. These were contrasted a software development to the classic waterfall method, which represents the
Copyright UCT
23
environment. “heavyweight” family of methodologies.
LO2 [Training]
To consider the best way to
manage new hires so that
they can become productive
in a Lean or Agile software
development environment.
Common challenges to integrating new employees were
considered. The struggles that are experienced by
graduates straight out of university/college was explored.
Strategies to overcome these difficulties were explored
and focused on the ability of a manager to teach team
members to teach one another.
The relationship between Agile (including Lean) and more traditional methodologies such as the
waterfall method is given in Figure 5 (Adapted from Rico & Sayani, 2009).
Figure 5: Comparison Between Agile and Traditional Methods (Adapted from Rico & Sayani, 2009)
The teaching case that was presented demonstrated an organisation that utilises elements from Agile,
LeanSD and the Kanban method. The classic waterfall method is described as an illustration of a
traditional heavyweight methodology, although elements of the plan-driven concepts are also present in
the case of ACSE. Students are expected to be able to make an argument for what they would modify,
remove or add to existing practices and understand the trade-offs and complexities of implementing their
proposals. In particular, the case placed the protagonist in the position to take stock of the people, tools
and practices to use and how to go about onboarding additional newcomers in the most efficient manner.
Copyright UCT
24
3. CASE METHODOLOGY Introduction
The learning objectives outlined previously aim to introduce contemporary software development
methodologies to students. Literature in the field is predominantly case-based and the research has been
considered to be in a nascent stage (Ahmad et al., 2013; Wang et al., 2012). However, an increase in
formal research and an increase in quality has been reported (Dingsøyr, Nerur, Balijepally, & Moe, 2012)
indicating that the research field of lightweight software development practices is maturing. This
foundation can be used in a teaching case context to illustrate how Agile and Lean principles are applied
in a commercial context and the challenges associated with its implementation.
This chapter discusses the merits of using ACSE as a teaching case. It continues to describe which
methods were used to collect information and how the data was analysed. The limitations of the research
will also be considered, as will any ethical considerations that are pertinent to the research methodology.
Applicability of the Case Harling and Misser (1998) highlight ten characteristics that they deem to be important for a teaching case
to be effective. These are summarised in Table 9 and largely agree with sentiments by other authors on
the subject (Balakrishnan, 2010; Farhoomand, 2004). In particular, the authors agree on the notion that a
teaching case must tell a story that is compelling to the student and that places them in the position of a
manager who needs to make a managerial decision, although this is not an absolute requirement
(Sjoblom, n.d.). The situation need not be factual and the details may be disguised, although there must
be sufficient similarity to a real situation to be effective as a practical learning tool (Balakrishnan, 2010).
Table 9: The Ten Characteristics of Effective Cases (Extracted from Harling & Misser, 1998)
1 The case tells a story 2 The case issues arouse the readers’ interest 3 The case situation is accessible to the readers 4 The case teaches a managerial skill 5 The case requires the solution of a managerial problem 6 The managerial problem in the case has a history 7 The case includes quotations 8 The case permits empathy with the central character
Copyright UCT
25
9 The case is set within the past five years 10 The case is short and simple
For the case of ACSE, the position of the manager of the graphical user interface development team (or
GUI team) was used. This is because the Lean and Agile principles being discussed would typically fall
under her or his responsibilities, placing such a manager in the decision-making role for the narrative. In
addition, the manager of a GUI team is assumed to be mostly concerned with operational concerns and
be less influenced by strategic or cultural concerns of the organisation. The decision to hire new
developers for the team, within a changing corporate ecosystem resulting from the AutoSolve
acquisition, served as the catalyst for the manager to reassess and consider their current practices. The
learning objectives have been discussed and are summarised in Table 8. Both Agile and Lean
development processes are considered, in addition to the Kanban method which is considered as part of
the Lean way of thinking (Wang et al., 2012).
Data Gathering
The ACSE case required a single-case design. This section will discuss the case design for a single-case
and the various considerations that ensure its validity. Leedy and Ormrod (2010) and Yin (2014)
highlights the importance of considering the internal and external validity of a case, in addition to
considerations such as reliability. The sources of information and how it was utilised will also be
considered.
Internal validity Internal validity refers to the ability to draw a cause-and-effect conclusion from a study (Leedy &
Ormrod, 2010; Yin, 2014). This can be stated more formally as “conclusions are unambiguously drawn
from its premises” (Christensen & Carlile, 2009). Christensen and Carlile (2009) expand on the criterion
by including the need to rule out plausible alternative variables that may have contributed to a given
conclusion.
While internal validity is more critical in explanatory case studies (i.e. where such causal relationships
are the focus of the research), it could be argued that a descriptive teaching case is less affected (Yin,
2014). Nevertheless, Leedy and Ormrod (2010) suggests several countermeasures that may be used to
increase the likelihood of higher internal validity. The methods include controlled laboratory studies,
double-blind experiments, unobtrusive measures (i.e. where people do not know that they are being
Copyright UCT
26
studied) and triangulation of data sources. Laboratory studies and double-blind experiments do not lend
themselves to the descriptive nature of the ACSE case. Unobtrusive measures lend themselves to ethical
concerns and are impractical in cases where data is collected by means of interviews. This leaves
triangulation of multiple data sources as the primary argument supporting the internal validity of the
research.
Data triangulation refers to using multiple sources of data to evaluate the validity of a conclusion, as
opposed to investigator triangulation, theory triangulation or methodological triangulation (Patton as
cited by Yin, 2014). More broadly, this is the ability of the researcher to “examine the phenomena from
as many perspectives as possible” (Christensen, 2010, p. 245). The sources of data will be discussed in
more detail in the relevant section.
External validity External validity refers to the ability to generalise the findings of a case to different contexts (Christensen
& Carlile, 2009; Leedy & Ormrod, 2010; Yin, 2014). In other words, the research must sufficiently
address whether this case is an anomalous event or whether its conclusions and learnings can be applied
in different settings.
No fewer than fourteen distinct threats to external validity have been identified by Onwuegbuzie and
Leech (2007), illustrating that it is a complex and non-trivial consideration when conducting research.
This arguably contributed to the perception amongst researchers that one is unable to generalise a case
study (Flyvbjerg, 2006). Flyvbjerg (2006) performed an analysis of the arguments for and against the
generalisation of a single case and concluded with:
“One can often generalize on the basis of a single case, and the case study may be central to
scientific development via generalization as supplement or alternative to other methods. But
formal generalization is overvalued as a source of scientific development, whereas ‘the force of
example’ is underestimated.” (Flyvbjerg, 2006, p. 228)
The conclusion helps support the argument that a single case has the potential towards external validity,
but the question remains as to how the likelihood of validity can be improved. Again we turn to Leedy
and Ormrod (2010) who suggests several strategies. One is to use a real-life setting, another is to use a
representative sample and the final strategy is to replicate the study in a different context. The nature of
Copyright UCT
27
a teaching case is to place students in the position of a manager in a real-life context (Balakrishnan,
2010), which lends itself to the first strategy. Replication and increased sample sizes are not practical for
the ACSE case but may be considered for future research on the topics of software development
practices or training new developers.
Data sources To improve the internal validity of the research, multiple data sources have been recommended. External
validity is improved by ensuring that the case is representative of a real-life context. The data sources
that have been selected keeps these considerations in mind. In addition, the recommendations for writing
a compelling teaching case as highlighted by Harling and Misser (1998) in Table 9 lends itself towards
research that increases human contact. Increased contact with the people that will be represented in the
narrative will make it possible to include direct quotes, which is reported to improve the quality and
relatability of a teaching case (Farhoomand, 2004). Leedy and Ormrod (2010) summarises that
observations, interviews, written documentation and audio-visual material are common methods for data
collection in case study design.
A participant observer role was assumed by the researcher as the “case study researcher becomes
involved in the activities of the case being studied” (Yin, 2014, p. 240). Participant-observation is
common in anthropological studies and can be used in organisational settings (Yin, 2014). A common
strength of this approach is the ability to gain insight into interpersonal behaviours, which can be
exploited to improve the narrative of the teaching case. However, the potential researcher bias of
becoming entrenched or “going native” (Onwuegbuzie & Leech, 2007, p. 242) could affect the findings.
Keeping the learning objectives in mind and triangulating data has been suggested by Onwuegbuzie and
Leech as countermeasures for this type of bias. This concern is generally confined to ethnographic
research where a culture or social construct is being studied (Leedy & Ormrod, 2010). As the focus of
the ACSE case is on operational behaviours of a software development organisation, proper planning of
data collection was considered sufficient to counteract the concerns of researcher bias.
Semi-structured interviews were the primary source of data for the teaching case. Interviews reportedly
have the benefits of being a more targeted source of evidence and giving insight into the thinking and
motives behind interviewee behaviour (Yin, 2014). However, interviews run the risk of biased responses
(Yin, 2014), or “not necessarily getting the facts” (Leedy & Ormrod, 2010, p. 151). A list of suggestions
Copyright UCT
28
provided by Leedy and Ormrod (2010) are presented in Table 10. It is recommended that, where
interviews are the primary source of data, open-ended questions be used (Hsieh & Shannon, 2005). A
transcription of the interview is then coded and categorised for further analysis. For the purposes of a
teaching case, the use of direct quotes will also become possible, albeit slightly modified to omit details
that may be too revealing of the organisation.
Thirteen interviews were conducted with a cross-section of the organisation. Team leaders and key
personnel from the breakdown in Figure 1 were interviewed on their thoughts pertaining to their
understanding of their own role, as well as their understanding of the larger development processes. The
semi-structured interview protocol is provided in Appendix B: In addition, five junior developers were
interviewed in a focus group format, providing additional insight into their perceptions around the
training that they received as well as their understanding of development practices. Appendix C: outlines
the protocol that was used for the focus group session.
Table 10: Suggestions for Conducting a Productive Interview (Adapted from Leedy & Ormrod,
2010)
1 Identify some questions in advance.
2 Consider how participants’ cultural backgrounds might influence their responses.
3 Make sure your interviewees are representative of the group. 4 Find a suitable location.
5 Get written permission. 6 Establish and maintain rapport.
7 Focus on the actual rather than on the abstract or hypothetical. 8 Don’t put words in people’s mouths.
9 Record responses verbatim. 10 Keep your reactions to yourself.
11 Remember that you are not necessarily getting the facts. 12 When conducting a focus group, take group dynamics into account.
To facilitate triangulation, opportune documentation and additional sources were considered and
incorporated where appropriate (e.g. documentation that can be used as the exhibits in the teaching case),
although the case design relied on the interview and observation sources mentioned above.
Copyright UCT
29
Limitations and Assumptions
Yin (2014) reports that case studies potentially suffer from several limitations. One such limitation is
that case study research may lack the rigour required to be useful. However, due to the explanatory
nature of teaching cases, it can be argued that in these cases the researcher “need not be concerned with
the rigorous and fair presentation of empirical data” (Yin, 2014, p. 5). This is presumed to be because
the data itself is secondary to the lesson that it conveys and is written in such a way as to “excite readers
and provoke discussion” (Harling & Misser, 1998, p. 120). This lack of formality does increase the
likelihood of the introduction of bias into experiments, which may affect the quality of any observations.
Careful design and documentation of data collection protocols are considered sufficient to mitigate this
concern.
A further limitation commonly attributed to case study research is the inability to generalise learnings
from a single case (Flyvbjerg, 2006). This is not a concern for this teaching case, as no novel
methodologies were introduced. In other words, a thorough literature review provided the generalised
foundation on which the learnings are formulated. Farhoomand (2004) likens the writing of a teaching
case to be “more similar to writing a spy thriller than a research article”, with the intent of engaging
students and to encourage them to consider lateral perspectives on a business case. The perception exists
that broad, context-independent knowledge has larger intrinsic value than a single, context-dependent
and concrete example (Flyvbjerg, 2006). Even so, Christensen and Carlile (2009) argue that case studies
are useful in an effort to co-create a learning environment around complex phenomena, with case studies
presenting a “solid foundation” for theory-building.
It is assumed that the case study approach is appropriate for the purposes of illustrating software
development practices in its real-world context. The preconditions for using the case study method are
met in that the research questions implicitly take the “how” and “why” form, control over behavioural
events are not required and that it focuses on contemporary events (Yin, 2014). The explanatory nature
of the teaching case lends itself to this line of inquiry, bolstering confidence in the assumption. Evidence
can be gathered by means of direct observation, participant observation and interviews with individuals
involved in the software development process. This access makes a case study possible – in contrast to a
history – where observation could be impossible. It should be noted that participant observation
introduces the risk of informal manipulation of the environment. Although care was taken to avoid bias,
Copyright UCT
30
it is difficult to rule out, especially due to the relationship that the author has with the organisation. A
final assumption (and limitation) is that the researcher does not have control over the processes being
studied. This is partially due to a lack of managerial control over the processes, but also due to
restrictions in the time available to conduct research. For instance, a case study conducted on BBC
Worldwide (Middleton & Joyce, 2012) spanned more than a year while this workpiece spanned only
several months.
Conclusion
In this chapter, the practical aspects of the research were considered more detail. The applicability of the
selected case as a teaching case was considered. A review of various aspects of the validity of
conducting research was performed, where the internal and external validity of the holistic single case
was analysed. Based on the analysis, the practical and appropriate data sources were selected and
discussed. Finally, the limitations and assumptions of the research were reviewed.
Copyright UCT
31
4. TEACHING CASE ACSESIM2: AGILE AND LEAN SOFTWARE DEVELOPMENT IN PRACTICE
“Hmm… Well, that’s nice. Right?” – Mark thought to himself as he left the manager’s meeting. The
thought was only half sincere, the other half left Mark with niggling uncertainty. It was an April 2016
budget meeting and the graphical user interface (GUI) team – his team – was budgeted to get another
two team members next year. That was a good thing, right? Given the tough workloads the team was
facing, Mark ought to have been elated, but two new people presented the prospect of surfacing many
issues that were bubbling beneath the surface. “At least they could have chosen the timing a little
better…” he thought to himself as he made his way to the kitchen for a much-needed cup of coffee.
Mark started working at ACSE ten years ago fresh from graduating as an engineer and applied his
training in a software development role. Four years ago, the GUI Team leader position opened and Mark
was given the opportunity to apply. Mark’s experience in the development environment made him a
solid candidate for the job. Since he was already proficient with the development practices and had
proven himself to be a creative problem solver, he was given the job. The previous team leader was a
good manager and did a wonderful job of establishing processes and best practices, but Mark was keen to
add a developer’s perspective to them.
He pumped the urn in the kitchen a few times to refill his mug with coffee, still thinking about this latest
challenge. ACSESim was a simulation tool that was used by engineers in several equipment
manufacturing firms to help analyse and design the physical behaviour of new products (e.g. the physical
stresses on structures, temperature, airflow and many other physical considerations that needed to be
considered when creating a product). But the team had been bogged down doing a lot of necessary
maintenance to the source code, which added little visible value to their customers. Certainly, two more
people would have helped to eventually speed up the process, but we just couldn’t afford to take the time
to train them.
2 Note that details of the organisation, its products and its history have been modified to protect the
anonymity of the organisation and its employees. No changes were made that are considered relevant to
the learning objectives of the case.
Copyright UCT
32
The thing with new employees is that it takes time to teach them the coding standards, to teach them how
the version control software works, how the issue tracker works; all of which keeps other developers
away from the task of implementing the features that are in the backlog. Could they afford the luxury of
two new employees and would something else consequently suffer? Sipping on his now lukewarm
coffee, he went to join the others at the daily stand-up meeting by the kanban board.
A Brief History
ACSE is a South African software engineering company that developed physics simulation software for
large OEM’s (“Original Equipment Manufacturers”). This simulation software helped the OEM’s with
the design and analysis of the physical performance of the equipment that they produced. Customers
ranged from aerospace firms that designed aeroplane parts, automotive design teams and even a few
defence contractors working on military projects. The company was originally founded by two fresh PhD
graduates in 1991 as an engineering consulting firm. They quickly discovered that more advanced tools
were needed to help them analyse the complex environments that their customers operated in.
The founders realised that there was a market to provide such tools, as a software package, to their
customers. They consequently partnered with a student completing her research on simulation
technology and commercialised the tools developed to aid their work as a software product under the
name ACSESim in 1995. This product became the hallmark of ACSE. In 2015, more than 20 years
later, ACSE was fully acquired by AutoSolve, an American simulation software company that developed
and maintained a range of physics simulation software products. Both ACSE and AutoSolve provided
computer-aided design and engineering (or CAD and CAE) tools to engineering companies.
AutoSolve’s intent in acquiring ACSE was to round off the offering that AutoSolve could provide to
their customers. The founders of ACSE and its shareholders agreed that they could accomplish much
together and accepted the offer.
Software Development – Then and Now
Software development is the process of creating programs that can be executed on computer systems
(e.g. for the use of performing complex calculations, storing data, communicating information, etc.). In
general, it involves a programmer writing source code (instructions that they would like the computer to
execute); compiling (converting those instructions into a format that a computer can understand); testing
Copyright UCT
33
(ensuring that the program does what the programmer intended to do) and shipping (distributing the
program to people to use on their own computers).
In the early days of computer software development, the process of writing source code was laborious
and error prone. The capacity of computers was also limited, meaning that programmers spent a lot of
time up front planning their code before trying to execute it on a real computer. In other words, it had to
work correctly the first time! In the late 20th century, personal computers changed the landscape of
software development by making computers available on a much broader scale. The tools became
increasingly sophisticated and enabled programmers to see their programs in action at increasing speed
and reduced cost. However, the processes in companies that developed software weren’t as adaptive.
Programmers, processes and the culture of developing software remained fixed in the notion that up-front
planning and fixed specifications were required for programs to be developed.
Projects spanning several years often ran over budget, fell behind schedule and resulted in programs that
were out of date by the time they were completed. Several philosophies emerged in the 1980’s and
1990’s to counter these problems. While they varied in many respects, patterns started to emerge. In
2001, seventeen consultants practising these philosophies gathered at a ski resort in Snowbird, Utah. The
gathering resulted in The Agile Manifesto, which became the foundation of Agile software development
methodologies.
While not initially represented at the gathering in Snowbird, Lean software development practices
appeared throughout the 2000’s and were later accepted as part of the Agile family. While not every
project is well-suited to Agile methodologies, others are unfeasible without them. At ACSE, the GUI
Team adopted those Agile and Lean practices that made sense for their product and adapted them over
time.
A group of junior developers that were working on ACSESim were asked to name all the practices that
they had been taught to use (see Exhibit 3); an exercise that highlighted a rich and diverse set of
practices. This alluded to a culture where knowledge was transferred quickly to inexperienced
developers. A developer who has been with the team for only a few months commented that “it’s really
cool that while you’re doing the learning, you know that you’re being kind of helpful”.
Copyright UCT
34
ACSESim Development
ACSESim provided both the computational solver technology (i.e. the number-crunching core that
calculated the results of a physics simulation problem) as well as a graphical user interface (or GUI)
that helped users to both configure their analyses and to view the results from the solver simulation. To
illustrate the nature of the role of each team, consider the analogy of an online search engine. A user
types a phrase into a simple text field, which then churns out a list of possible websites that might be
relevant. The search bar would be the GUI Team’s responsibility and serves to make the site easy and
accessible to use. In the background, sophisticated search algorithms would take the inputs and provide
a list of possible websites. These sophisticated algorithms would be the work of a solver team, while the
GUI would then display these sites in a way that is easy for a user to understand. Both these teams need
to work hand-in-glove as it were to develop a well-functioning, usable product.
So, although the Solver and GUI development teams worked towards the common goal of providing the
user with an efficient and accurate solution to their problems, each team was focused on a different
aspect of this goal and made use of different development processes to achieve them. In addition, a non-
development program management team (or PM Team) was involved with providing industry and
customer context. Very often, this included refining specifications that addressed customer needs that
served as inputs to the development teams.
Figure 1 shows the structure of the different teams that contributed in some way or another to
ACSESim’s development efforts. In the GUI Team, Mark was in the company of junior developers (two
of which had less than a year’s worth of experience at ACSE) up to senior developers with more than a
decade of experience working on ACSESim and held master’s degrees in their disciplines. Exhibit 4
shows a breakdown of the experience and qualifications of seven of the team members.
Copyright UCT
35
Figure 6: Team roles within ACSESim Development Together, these teams planned and contributed towards developing new versions of ACSESim in regular
release cycles. A release cycle comprised features and bug fixes that were deemed necessary for the
stability of the product or would be useful to customer projects. The decision for what to include was
informed by input from account managers, users, development teams as well as the discretion of
management.
Each product under the parent company at AutoSolve had a set of teams that coordinated the
development for their product and reported back to management. Team leaders would consider the
various inputs and discuss what they felt were feasible, with the overarching focus being to win or retain
customers by simplifying, extending or improving how customers analysed and designed their products.
Major versions of ACSESim were released on a roughly annual cycle, with two or three minor feature
releases in between and additional bug fix releases on an ad hoc basis. Customers would normally
receive an update (be it a major, minor or an ad hoc bug fix release) to ACSESim every one to two
months.
Figure 2 shows the process for how a typical feature or bug fix would be implemented in ACSESim. At
the outset, it should be noted that the flow was not one-directional as indicated. The person responsible
for the issue during a phase could at any time transition the issue to a previous state. Typically, though,
specifications were generated by the PM Team (i.e. “To Do” à “Development Ready”) and prioritised
for a release cycle in small, logical groupings. A feature release would contain a set of such groupings,
Copyright UCT
36
with major releases containing the changes that may have major implications for how customers use the
product. Ad hoc bug fix releases were shipped when they were deemed necessary and seldom contained
new features or interface changes.
Figure 7: Typical process followed for a GUI or Solver Team feature implementation
Issues that were ready for development got placed onto the GUI Team’s backlog and waited for a
developer to become available. Developers were limited to working on two issue groupings at a time, so
could only start on a new grouping (i.e. “In Progress”) once one of their active issue groupings were
completed. To complete an issue grouping, an automated set of regression tests were run to ensure that
their changes didn’t cause unintended problems in other parts of the application (i.e. “Validating”). Once
these automated tests passed, a quality assurance tester could review that the feature had been
implemented as specified (i.e. “Testing”).
Mark was responsible for the GUI Team activities, including development and testing. Thabisa, one of
his senior quality assurance (QA) engineers, often referred to this as a “ping pong match” between the
testers and the developers to make minor changes until everything became stable enough to be released
to customers. QA would send an issue back to a developer when they felt that the specifications weren’t
adhered to, that the change was difficult to use, if other aspects of the application were inadvertently
broken or if there was a deterioration in performance.
AutoSolve Buys ACSE
AutoSolve left ACSE to run itself much as it always did before the acquisition. Indeed, it was due to the
success of ACSESim that ACSE was such an attractive addition to the family. Even so, management at
AutoSolve saw the potential to create further value by having the products and development teams
interact more closely with one another. The American company had already made several acquisitions
To Do Development Ready
•Specifications complete
•Waiting for developer capacity
In Progress Validating Testing
•Waiting for specifications
•Pending queries
•Information gathering
•Writing tests (TDD)
•Development •Progress in
daily standup •Progress in
weekly meeting
•Local acceptance tests
•System integration tests
•Feature complete
•Usability •Pushes to
updater
Copyright UCT
37
and had grown to over a thousand employees that were actively developing more than a dozen different
products. AutoSolve management aimed to strategically expand its capabilities and would have liked
consistent branding, user experience and a more seamless integration between products that fell under
their offering.
ACSE was a company with fewer than a hundred employees before the acquisition. Being incorporated
into AutoSolve gave them an opportunity to freely exchange information that was previously unavailable
to the development teams. A team working on one AutoSolve product might already have found a
solution to a problem that another team in the group were investigating. Mark had been receiving an
increasing number of requests from other AutoSolve product teams for information about solutions to
problems that ACSESim had already solved. In return, other teams shared information on their solutions
to work that was still in ACSESim’s pipeline. Practical considerations also needed to be considered,
such as having a shared tool for installing all AutoSolve applications and having ACSESim use the same
software licensing mechanism as the other products.
From Concept to Delivery
To create a graphical user interface as complex as the one required to access the power of the ACSESim
solver, the right mix of tools, people and processes were required. At ACSE, the GUI Team saw itself as
a generally agile team, although they didn’t follow a specific set of practices rigidly.
Tools of the Trade Several tools were used by ACSESim to develop software. The capabilities and constraints of the tools
influenced the way in which developers worked and how the processes were structured.
Issue Trackers
Issue trackers provided the platform that was required for communicating specifications, assigning tasks,
discussing problems and transitioning an issue through the various states shown in Figure 2. Another
valuable contribution of these systems is that they provide a searchable history of what had been
discussed with respect to any changes that were made to ACSESim. Even years after a feature has been
implemented, it was possible to see what decisions were made and what the reasoning was at the time.
Copyright UCT
38
Kanban Boards
Kanban boards3 provided a means to visualise where issues were during the implementation phase. The
kanban board depicted in Figure 8 shows how a typical kanban board could look during the development
cycle when it included features and bugs (represented by blue and pink sticky notes, respectively). This
physical board visualised the progress that the team had made during a cycle and serve to highlight how
much effort was being spent on implementing new functionality vs. fixing critical issues.
Figure 8: ACSE GUI Team kanban board A digital version of a kanban board was also used by the various teams and formed part of the issue
tracking system. This board was automatically updated as the state of an issue was updated in the issue
tracker, making progress available to managers and other stakeholders that may have been working from
other locations.
When bottlenecks formed in the flow of development, sticky notes started to add up in a column, which
made the problem more apparent. For instance, in Figure 8 (right) there was a build-up of features that
needed to be tested, indicating that the QA team may have needed additional resources (or fewer
distractions) to help with testing, which was common at the end of a cycle.
3 The term “kanban” is the Japanese word for “signboard” and is borrowed from Lean manufacturing.
Here it is used to visualise the work in progress and to help identify potential bottlenecks.
Copyright UCT
39
Version Control Software
When many developers were working simultaneously on the same files to update different sections of the
code, it quickly became impractical to develop without the help of version control. In ACSESim’s case,
a commercial tool was used that allowed the developers to work in a software coding environment (or
workspace) that was independent of those of other developers. Once their work was completed, the
changes needed to be “promoted” into the version controlled files. Other developers that worked on the
same files would need to “merge” their changes to include everyone’s contributions without accidentally
erasing or altering the intended behaviour. Developers would be required to run a set of tests to validate
their work before promoting their code, which gave a reasonable indication of whether their changes
were compatible with what was the stable version of the application.
Automated Systems
Mark and the rest of the team understood that computers could perform certain tasks faster and more
consistently than a human being would be able to. To leverage this, they devised an automated set of
procedures that either served to reduce the risk of human error or to speed up a process that would have
taken longer if done by someone on the team. Many of these systems linked to the version control
software but also incorporated other tools. Automated systems ran automated tests, compiled the source
code into executable applications (i.e. to convert the algorithms that the developers generated into
something that a customer would be able to run on their computer), generated documentation, populated
directories that were used by the update mechanisms and even transitioned issues to different phases in
the issue tracking system.
Even though these systems were quite complex, they saved a lot of time for the developers and gave
them the peace of mind that their changes have been made safely. This also allowed the team to
experiment with new concepts with more confidence because they knew that there was a reasonable
safety net that would catch most unintended consequences of risky changes.
Meetings
The GUI Team was situated in an open-plan office format (see Figure 9) so that developers could
communicate easily when they need to. Meetings were generally kept to a minimum and were only held
when they served a very specific purpose. Several meeting types were held by the team: daily “stand-
Copyright UCT
40
up” meetings, weekly progress meetings, code review meetings and development cycle retrospective
meetings.
Daily stand-up meetings were held in front of the Kanban board at 09h45. Each developer would state
what they had achieved since the previous day’s meeting, what they intended to do that day and if they
were experiencing any risks or problems that other team members could help them unblock.
Simultaneously, the sticky notes on the Kanban board would be moved to their correct locations and the
time spent on each would be indicated.
Figure 9: Open plan work area (as seen from the kanban board) Weekly progress meetings would capture what was achieved in the previous week by each developer.
An opportunity to demonstrate any new functionality was provided so that everyone could see how the
new features (or corrected bugs) worked and so that the rest of the company could start to use the
extended version of ACSESim. The team would also review any critical bugs that were logged and
ensure that someone would take responsibility for investigating the problem for a possible solution.
Code review meetings were held on an ad hoc basis and would be scheduled by the developers. Other
team members were invited to look through the code and critique it both in terms of conformance to the
coding and style standards, but also for possible risks or points of improvement. This would serve to
ensure a consistent code quality, but also gave developers an opportunity to learn from one another and
to become familiar with parts of the code that they may be unfamiliar with.
Retrospective meetings were held after each development cycle to reflect on how effective they were in
achieving their goals. Everyone involved in the development process was invited to highlight areas of
frustration or opportunities for improvement, ideally with a suggestion for how to accomplish this
Copyright UCT
41
already in mind. The reasoning for these meetings was that changes to the system should happen early in
the next development cycle to reduce the risk of hindering value-adding development.
The Lifespan of a Feature or Bug An essential requirement to developing a commercial software product was a sound method for
communicating between teams and customers. ACSESim used a commercial issue tracking system that
allowed its employees to log and track the status of issues. Issues could be requests for new features,
bugs that had been noticed that needed to be fixed, investigations that needed to be performed or queries
to the Support Team where people requested more information on how to use the product correctly.
Other departments (including HR, IT and Marketing) also used the issue tracker for their own projects,
but utilised different issue types for tracking their work.
Features and bugs got logged into the issue tracker by employees at AutoSolve that had access to the
system. Exhibit 2 shows where an issue enters and passed through the ecosystem. Customers would
raise their requests for features or bug fixes to the Support Team or to their region’s account managers
(who would pass it on to the Support Team if they struggled to help the customer themselves). Support
would then have tried to help the customer immediately in any way that they could within the constraints
of the software version that the customer had access to. These queries often lead them to identify bugs in
the system or to request new features that could have improved the workflow for the customer in that
situation.
For both feature requests and bugs, the PM Team would have attempted to find the smallest, simplest
example that illustrated the desired sequence of behaviours (or workflow) for a new feature
implementation. For bugs, their task was to reduce the complexity of the examples and the number of
steps that were required for a developer to be able to reproduce the problem. The purpose was to make
sure that the issues were clear and self-contained (i.e. that the issue gave sufficient information for a
developer to understand the problem without the need for further clarification). Because the PM Team
went through this process for every issue that got logged, they could often also link related issues or
close issues that they knew had already been addressed.
Management, in conjunction with Jeff (the PM Team leader) prioritised and scheduled the issues for
development. Jeff’s team was the one that had the most access to customers by means of technical
support personnel, conferences and so on. It was his and the rest of the PM Team’s responsibility to
Copyright UCT
42
ensure that there was sufficient information available for the development teams to make the necessary
changes in ACSESim. Their mandate to focus on value-adding features to the customer was often part of
the trade-off with development teams to maintain the integrity of the source code.
Mark and the rest of the GUI Team usually got involved here. Critical bugs, such those that prevented
customers from completing their projects, were investigated first. The team would try to identify the
source of the problem and address it, while simultaneously looking for a way around the bug so that
customers could continue working. The availability of workarounds and the likelihood of other
customers experiencing the problem would be weighed against the difficulties of implementing a fix.
Mark and Jeff would discuss high-risk items and reschedule them for a later release if needed. Features,
on the other hand, were often only considered for major or minor releases and scheduled accordingly.
Each developer had two software coding environments (or workspaces) on their computers that they
could work in. Two workspaces were deliberately chosen to ensure that the developers didn’t work on
too many different projects at a time. A feature grouping or set of bug fixes could occupy a workspace
until it got through the testing process. Once a workspace became available, a developer could look at
issues in the backlog, which could either be critical bugs or features that had been scheduled for the
current development cycle. They could request clarification on any of the specifications or raise issues
as they progress, which would involve input from the PM Team (including Support), other developers, or
any stakeholders that could be contacted to gain the information that they needed.
A test-driven development (TDD) approach was used for development. Essentially a developer would
have added automated steps as though a new feature had already been completed. Since the code
wouldn’t have existed yet, these tests would fail. As the implementation progressed and a developer
improved the software, the tests would start to pass. A feature or bug fix was considered complete once
all the tests pass. Figure 10 depicts this cycle.
Figure 10: The Test-Driven Development Cycle
Copyright UCT
43
On completion of an issue’s implementation, the developers would have promoted their code into the
“version control software” that managed all the changes that developers made to the source code. These
TDD tests got added to the automated testing systems and were run on a regular basis to make sure that
future changes didn’t inadvertently change the expected behaviour. Once the validation passed, the
developers could move the issue over to “Testing” so that someone from the QA Team could test the
functional validity of the changes. QA would compare the implementation against the original
specifications and ensure that everything was behaving as expected.
Once a logical grouping of issues passed testing, it could be promoted into the stable stream in the
version control software. The new version of the application would be released to customers once all
feature groupings and bugs in the backlog for the release was completed. In the case of severe bugs
having been fixed, intermediate releases could have been created to give customers earlier access to more
stable versions of the application. These bug fix releases seldom included new features or changed the
expected behaviour in any way, but could improve the performance or rectify incorrect behaviour.
Changes were documented in the issue tracker and a list (sometimes numbering in the hundreds) could
be given to customers.
Mark’s Budget for New Hires
Mark’s concern with two new hires wasn’t that the team couldn’t use them. In fact, many existing
AutoSolve customers adopted the application, meaning that features and new development project
opportunities were growing. Still, the thought of training two more people in the current way of working
triggered a few concerns that have been brewing over the last few months. Were their practices still
working the way that they wanted them to? Did adjustments need to be made to cater for the changes
that AutoSolve wanted them to make to ACSESim? Were there other systems being used in AutoSolve
that they should have considered adopting?
Systems AutoSolve was using the same issue tracker, albeit in a different way than ACSE had been accustomed
to. They also used different version control software. The changes that were being suggested (e.g. to
move to a new installer or to change the licensing framework) were sensible but introduced a new
Copyright UCT
44
channel for features and bugs to be introduced. The entire ecosystem needed to adjust to learning how to
prioritise and schedule these changes.
Jeff had been doing a great job in coordinating these changes, but Mark was wondering how long the
GUI Team could continue to work as they always had been without giving the AutoSolve systems more
serious consideration. Would it have made sense to train the new developers to use the existing version
control software if they were planning to adopt the new system in the future?
Training When new developers started in the GUI Team, their first task has always been the same – to implement
and update the “initiation” project. The project was always the same and required the developer to use
ACSESim’s coding standards and infrastructures. By doing so, they familiarised themselves with all the
various tools and processes. Once the team has code reviewed the project and it has been completed to a
satisfactory level, the developer would need to update the project description itself to ensure that it
remained current and utilised the latest best practices. A next developer would then do the same and so
on.
Mark knew from experience that the project could take a new developer a few months to complete and
that experienced team members provided much of their time coaching the new person to help them find
and fix problems. This meant that there was often a dip in productivity right after new people joined the
team, which made it harder for the normal backlog of features to be completed before the end of the
development cycle.
Choices, Choices… Mark had been wondering when to take the plunge and change the tools that facilitated their efforts.
Changes to the version control software or issue tracker could have dramatic consequences for short-term
productivity, but that would have been true irrespective of when the changes are made. To couple such a
major change with two new hires and the time and effort it demanded to bring them up to full speed, let
alone the productivity dip that it would bring made him nervous. What was more important and when
should he bite which bullet? And critically, how could he maintain the high standards of service to
clients amidst all of this?
Copyright UCT
45
Exhibit 1: Glossary
Term Description
backlog A list of tasks that must be completed for a project to be considered complete.
daily ("stand-up") A daily meeting with the goal of sharing information that is required for coordination. Meetings are meant to be short and are intended to identify blockages that are preventing team members from completing tasks.
A fixed period in which development activities take place. Teams determine their own iteration duration but are often between one and four weeks long.
Often a means of visualising and limiting the work-in-progress, a kanban board is a means to display the current state of a task in the development cycle
When a computer workspace is shared by two developers. One developer sits at the keyboard, while the other steers the direction. Developers will exchange roles every few minutes.
A process whereby the internal code is restructured (e.g. simplified, optimised or otherwise improved by the development team's definition) in such a way that the external behaviour is essentially the same.
These are algorithms that developers generate in various text files. Source code gets converted into an application that users can use by compilers or interpreters, whose function is to convert the human-understandable document into a computer- understandable language.
The process of developing software by first creating unit tests that fail (due to lack of functionality). As the features are implemented (or problems are corrected), the unit tests will begin to pass. Once all tests pass, development can be considered complete. This set of tests can be added to the automated test systems to ensure that future changes don't disrupt the expected behaviour of the change currently being made.
A fragment of a program that tests a very specific part of the source code that is produced. The tests are automatically run and, since each one tests a very specific code segment, can help the developers to narrow down problem areas.
Digital spaces (i.e. folders) where developers can make changes to the source code that are only seen within those spaces. This provides a safe environment for them to experiment with different extensions until the behaviour what they expect. When a feature or bug fix is complete, changes that have been made in a workspace can be integrated back into the shared source code that gets used when compiling the application.
meeting
iterations ("sprints")
kanban board
pair programming
refactoring
source code
test-driven development
unit testing
workspaces
Copyright UCT
46
Exhibit 2: The Lifecycle of an Issue
Figure 11 shows the lifecycle of an issue. The Program Management (PM) Team is indicated in blue, the
Solver Team in orange (Solver) and the Graphical User Interface (GUI) Team in yellow. Outside
stakeholders such account managers and customers are indicated in white boxes. The influence that each
team has during different phases of an issue’s development (either new features or bug fixes) are
indicated by the lines to the different phases of the issue tracking process.
Figure 11: The lifecycle of an issue Note that even though the issue’s path is indicated as being quite linear in its development, that it is
possible for a team to push an issue further back into the chain. For example, a developer in the GUI
Team can ask for more detailed specifications, or a tester in the QA team can ask for a simpler example
to test with and add to the automated regression tests.
Copyright UCT
47
Exhibit 3: GUI Practices
Figure 12 shows the results of a brainstorming session conducted with junior developers in the GUI
Team. They were asked to list as many of the software development practices and tools that were being
used that they could think of. There are many practices not mentioned in the case, including mechanisms
to trigger developers to switch to a bug-fixing mode (crash report duty; bug-fixing day tokens in the form
of chocolates); malicious testing days where the company actively and deliberately tries to find mistakes;
user-centred design; etc. In the case of user-centred design, developers are included in the design
process earlier on, which traditionally forms part of the specification formulation process. This is a
program management function but can span over multiple teams to ensure a broad base of perspectives.
Among the items, cultural artefacts can also be observed, such as the freedom to work on projects of
their choosing on Friday afternoons, or social gatherings where the team goes for a beer when certain
milestones are met. The list also highlights a culture of ownership, collaboration, and peer support.
Figure 12: Junior GUI Team members on current practices
Copyright UCT
48
Each of them was then asked to rank the practices that they felt were the top 3 most valuable practices
that were in use. Table 11 summarises the results and shows a trend of GUI Team members valuing
coding standards, stable development streams, practices such as test-driven development and a
collaborative culture.
Table 11: Ranking of GUI development practices
PARTICIPANT 1
PARTICIPANT 2
PARTICIPANT 3
PARTICIPANT 4
PARTICIPANT 5
1 Coding standards Stable streams Collaborative culture
Collaborative culture
Coding standards
2 Test-driven development
Quick design feedback; UCD
Stable streams Coding standards Test-driven development
3 Value-adding work
Ownership of architecture
Test-driven development
Stand-up and kanban
Issue tracking
Copyright UCT
49
Exhibit 4: GUI Team Experience
Figure 13: Years working on ACSESim
Figure 14: Years of prior work experience
Figure 15: Highest Qualification
Copyright UCT
50
5. INSTRUCTOR’S GUIDE – TEACHING NOTE The teaching note has been stripped from this case.
For further information please contact the GSB Case Writing Centre.
Conclusion
ACSESim provides a glimpse of how a software development firm uses Lean and Agile principles in
developing their GUI. Various tools, processes and people roles were described to give an example of
how the principles manifest on such an environment. The management dilemma, namely the timing of
hiring and training two new employees at a potential cost of lost productivity, illustrated practical growth
pains that could be experienced in organisations outside of software development as well.
The teaching note provides the structure that could be used to carry the points across. Of particular value
were the required readings, that serve to be both topical to the case and general enough that practitioners
from non-software engineering disciplines are expected to be able to engage with.
Copyright UCT
51
6. BIBLIOGRAPHY Agile glossary and terminology. (n.d.). Retrieved November 26, 2016, from
https://www.agilealliance.org/agile101/agile-glossary/
Ahmad, M. O., Markkula, J., & Ovio, M. (2013). Kanban in software development: A systematic
literature review. In 2013 39th Euromicro Conference on Software Engineering and Advanced
Applications (pp. 9–16). IEEE.
Al-Baik, O., & Miller, J. (2015). The Kanban approach, between agility and leanness: A systematic
review. Empirical Software Engineering, 20(6), 1861–1897.
Balakrishnan, M. S. (2010). Writing cases. Retrieved August 16, 2016, from
http://www.emeraldgrouppublishing.com/products/new/pdf/teaching_cases.pdf
Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … Kern, J.
(2001). Manifesto for Agile Software Development. Agile Alliance. Retrieved from
http://agilemanifesto.org/.
Begel, A., & Simon, B. (2008). Struggles of new college graduates in their first software development
job. ACM SIGCSE Bulletin, 40(1), 226–230.
Christensen, C. M. (2010). How will you measure your life. Harvard Business Review. Christensen, C. M., & Carlile, P. R. (2009). Course research: Using the case method to build and teach
management theory. Academy of Management Learning & Education, 8(2), 240–251.
Conboy, K. (2009). Agility from first principles: Reconstructing the concept of agility in information
systems development. Information Systems Research, 20(3), 329–354.
Conboy, K., Coyle, S., Wang, X., & Pikkarainen, M. (2010). People over process: Key challenges in
agile development. IEEE Software, 28(4), 48–57.
Davis, A. M., Bersoff, E. H., & Comer, E. R. (1988). A strategy for comparing alternative software
development life cycle models. Software Engineering, IEEE Transactions on, 14(10), 1453–1461.
Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile
transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108.
Copyright UCT
52
Dingsøyr, T., & Lassenius, C. (2016). Emerging themes in agile software development: Introduction to
the special section on continuous value delivery. Information and Software Technology, 77, 56–60.
Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies: Towards
explaining agile software development. Journal of Systems and Software, 85(6), 1213–1221.
Farhoomand, A. (2004). Writing teaching cases: A quick reference guide. Hong Kong: University of
Hong Kong.
Flyvbjerg, B. (2006). Five misunderstandings about case-study research. Qualitative Inquiry, 12(2), 219–
245.
Gregory, P., Barroca, L., Sharp, H., Deshpande, A., & Taylor, K. (2016). The challenges that challenge:
Engaging with agile practitioners’ concerns. Information and Software Technology, 77, 92–104.
Harling, K., & Misser, E. (1998). Case writing: An art and a science. International Food and
Agribusiness Management Review, 1(1), 119–138.
Hsieh, H. F., & Shannon, S. E. (2005). Three approaches to qualitative content analysis. Qualitative
Health Research, 15(9), 1277–1288.
Khan, A. I., Qurashi, R. J., & Khan, U. A. (2011). A comprehensive study of commonly practiced heavy
and light weight software methodologies. International Journal of Computer Science Issues, 8(4),
441–450.
Kupiainen, E., Mäntylä, M. V., & Itkonen, J. (2015). Using metrics in Agile and Lean Software
Development – A systematic literature review of industrial studies. Information and Software
Technology, 62, 143–163.
Leedy, P. D., & Ormrod, J. E. (2010). Practical research: Planning and design (9th ed.). Upper Saddle
River, New Jersey: Pearson Education, Inc.
Liker, J., & Ballé, M. (2013). Lean managers must be teachers. Journal of Enterprise Transformation,
3(1), 16–32.
Liker, J., & Morgan, J. (2006). The Toyota way in services: The case of lean product development.
Academy of Management Perspectives, 20(2), 5–20. Lindgren, E., & Münch, J. (2016). Raising the odds of success: The current state of experimentation in
Copyright UCT
53
product development. Information and Software Technology, 77, 80–91. Middleton, P., & Joyce, D. (2012). Lean software management: BBC Worldwide case study. IEEE
Transactions on Engineering Management, 59(1), 20–32.
Onwuegbuzie, A. J., & Leech, N. L. (2007). Validity and qualitative research: An oxymoron? Quality
and Quantity, 41(2), 233–249.
Perkusich, M., Soares, G., Almeida, H., & Perkusich, A. (2015). A procedure to detect problems of
processes in software development projects using Bayesian networks. Expert Systems with
Applications, 42(1), 437–450.
Pernstål, J., Feldt, R., & Gorschek, T. (2013). The lean gap: A review of lean approaches to large-scale
software systems development. Journal of Systems and Software, 86(11), 2797–2821.
Poppendieck, M., & Cusumano, M. A. (2012). Lean software development: A tutorial. IEEE Software,
29(5), 26–32.
Rico, D. F., & Sayani, H. H. (2009). Use of Agile methods in software engineering education. 2009 Agile
Conference, 1–12.
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016a). Embracing Agile. Harvard Business Review,
(May), 41–50. Retrieved from https://hbr.org/2016/05/embracing-agile
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016b). The secret history of Agile innovation. Harvard
Business Review, 7.
Rollag, K., Parise, S., & Cross, R. (2005). Getting new hires up to speed quickly. MIT Sloan
Management Review, 46(2), 35–41.
Schwaber, K. (1995). Scrum development process. Proceedings of the Workshop on Business …, (April
1987), 10–19.
Sjoblom, L. (n.d.). How to write a teaching note. Retrieved August 23, 2016, from
http://www.emeraldgrouppublishing.com/products/new/pdf/How-To-Write-A-Teaching-Note.pdf
Soliman, M. H. A. (2015). A new routine for culture change. Industrial Management, (May / June), 25–
30.
Copyright UCT
54
Staats, B. R., & Upton, D. M. (2011). Lean knowledge work. Harvard Business Review, 89(10), 100–
110.
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Journal of Product
Innovation Management, 3(3), 205–206.
Trimble, J., & Webster, C. (2013). From traditional, to lean, to agile development: Finding the optimal
software engineering cycle. Proceedings of the Annual Hawaii International Conference on System
Sciences, 4826–4833.
Wang, X., Conboy, K., & Cawley, O. (2012). “Leagile” software development: An experience report
analysis of the application of lean approaches in agile software development. Journal of Systems
and Software, 85(6), 1287–1299.
Williams, L. (2012). What agile teams think of agile principles. Communications of the ACM, 55(4), 71–
76.
Worldwide CAD trends 2016 survey results. (2016). Retrieved August 23, 2016, from
http://www.business-advantage.com/CAD-Trends-Results-2016.php
Yin, R. K. (2014). Case study research: Design and methods (5th ed.). Thousand Oaks, CA: SAGE
Publications, Inc. Copyright UCT
APPENDIX A: INFORMED CONSENT FORM All interview participants are required to complete the consent form before the interview can
commence.
Figure 17: Informed Consent Form for Interviews
Copyright UCT
APPENDIX B: INTERVIEW QUESTIONS
LO1 To gain an understanding of how Lean and Agile principles can be applied in a
software development environment.
LO2
To consider how to assess the validity of using different techniques given changes
in the environment.
LO3
To gain insight into the complexities that managers have to keep into account
when designing and modifying software development practices.
# Question LO1 LO2 LO3
1 How does a typical feature extension process look from your
perspective? X
2 How does a typical bug fix process look from your perspective? X
3
What practices do you consider to be essential to the way that
software is developed within the context of your current role?
Why?
X
4
What practices do you consider to be interesting or unique to the
way that software is developed within the context of your role?
Why?
X
5 Describe the opportunities that you can think of (if any) for this
team within the larger organisation.
X X
6 What would need to change to unlock these opportunities i.t.o. how
software is developed?
X X
7 How would you consider improving the software development
practices specific to your role?
X
8 How would you consider improving the software development
practices for the team as a whole?
X
9 If you were to change any existing practices, what do you think
will be the biggest hurdle you might have to overcome?
X X
Copyright UCT
APPENDIX C: FOCUS GROUP QUESTIONS
# Question
1 What aspect of your job do you enjoy the most?
2 How can you tell whether the work you are doing is being valued?
3
As a group, brainstorm the software development practices and tools that you can think
of that are actually being used in your team.
4
Rank the five that you think are the most important (from top to bottom) on the piece of
paper. Do this privately and put the card face down when you’re done.
5
What software development practices have you heard of that are not being used here
(anything from gathering customer requirements to QA to deployment)?
6
In your opinions, what do you think the trickiest thing would be to keep in mind when
changing any of the current development practices?
7
To the best of your knowledge, what philosophy of software development does the GUI
team use?
8
In an ideal world – what would be the one thing you would change that would improve
the way you do your job?
Note that the learning objectives were adapted after the interviews were conducted.
Copyright UCT