Agile at IBM: software developers teach a new dance step to management

2014 ◽  
Vol 42 (2) ◽  
pp. 26-29 ◽  
Author(s):  
Robert M. Randall

Purpose – Explains how companies that are seeking to implement rapid innovation can adopt the Agile software development approach. In Agile, self-organizing teams work in short cycles called “sprints” and develop the features to enable the product to continuously evolve in the light of the experience they gain and through customer feedback. Design/methodology/approach – For insight into how Agile is being implemented at a leading software services firm with clients in hundreds of industries, Strategy & Leadership asked Rob Purdie, Agile Practice Lead for the IBM Design Lab, how Agile software development methods were contributing to the success of IBM's key digital marketing initiatives. Findings – The traditional approach to software development is to define, design, develop and test everything – before delivering anything. With Agile, managers can reduce waste by prioritizing features based on relative business value, evaluating and re-designing as the project proceeds. Practical implications – Agile requires leaders and teams to work and learn through problems, designs and options in an open and transparent environment. It places new demands on technical leaders in terms of negotiation and planning skills. Originality/value – Managers outside the software industry should note that Agile/Scrum is likely to be increasingly essential to the future of product development and manufacturing. Nowadays many products for consumers and businesses include embedded software systems, so developing products in the future will require deeper collaboration across multiple engineering disciplines and marketing teams and familiarity with the Agile approach.

2021 ◽  
Vol ahead-of-print (ahead-of-print) ◽  
Author(s):  
Carin Lindskog ◽  
Monika Magnusson

PurposeThe purpose of this study is to apply the concept of organizational ambidexterity as a conceptual lens to increase the understanding of tensions between exploitation (continuity) and exploration (change) in Agile software development (ASD) project teams, and particularly the balancing (ambidextrous) strategies utilized.Design/methodology/approachA conceptual framework was constructed from interdisciplinary sources on ambidexterity. A literature review of publications on ambidexterity in ASD was then performed, and the results from the selected publications were classified according to an extension of the conceptual framework.FindingsContextual ambidexterity in ASD is affected by the four basic coherent concepts: time, task, team and transition. The study found that most ambidextrous factors and strategies were task and team-related. In addition, a mixture of hard (performance) strategies and soft (social) strategies is needed in order for people/teams to (be able to) become ambidextrous.Practical implicationsTo provide a better understanding of ASD, it is important to identify a broader set of ambidextrous factors and strategies that can impact ASD project teams. The expanded conceptual framework can serve as a basis for future empirical research and provide insights to practitioners on how to strengthen ambidexterity in ASD projects.Originality/valueThe contribution is of great importance for ASD research and practice, as ASD methods are a popular method for managing projects within ASD and in other nonsoftware organizations. In addition, as more and more organizations struggle to deal with rapidly changing environments, interest in the phenomena of paradoxical tensions and the strategy (ambidexterity) to deal with these tensions increase.


Author(s):  
Handrie Noprisson

In recent years, the software development methodology evolves from the traditional approach to agile software development. This paper attempted to conduct a systematic literature review (SLR) regarding the improved agile software development to tackle its weakness based on recent research papers. Systematic Reviews and Meta-Analyses (PRISMA) as Systematic Literature Review Method (SLR). SLR is the review method which uses some protocols in order to minimize bias in the reviews. The improved of agile software methodology mostly regarding code reusability, usability, project quality, estimation, software delivery, usability, user responses and requirements delivery, communication between members, usability, practical activities, communication between team and stake holder, usability, workflow (learning), problem identification and effort estimation.


2022 ◽  
Vol 5 (1) ◽  
pp. 1-6
Author(s):  
Amos O. Jarikre ◽  
Yogesh Kumar Sharma ◽  
Amoako Kani John ◽  
Stercy Kwasi Bailey

The development of reusable and extensible software for business purposes has been the hallmark of the day. More developers are taking advantage of numerous approaches towards reaching their goals. One such approach is the agile approach in the development of extensible applications which has become so popular since its introduction over a decade ago. Using an agile approach that has a defined value in developing applications portray numerous benefits which have been identified by various scholars pointing out their outcomes as motivating factors of its adoption. With all such outline benefits, there exist some potential obstacles to agile developmental approach which has not been fully addressed. Hence, this article is aimed at analysing the obstacles which software developers face during agile development through a database search and also to guide them on ways to overcome such obstacles.


Author(s):  
J. Rech

Software quality assurance is concerned with the efficient and effective development of large, reliable, and high-quality software systems. In agile software development and maintenance, refactoring is an important phase for the continuous improvement of a software system by removing quality defects like code smells. As time is a crucial factor in agile development, not all quality defects can be removed in one refactoring phase (especially in one iteration). Documentation of quality defects that are found during automated or manual discovery activities (e.g., pair programming) is necessary to avoid wasting time by rediscovering them in later phases. Unfortunately, the documentation and handling of existing quality defects and refactoring activities is a common problem in software maintenance. To recall the rationales why changes were carried out, information has to be extracted from either proprietary documentations or software versioning systems. In this chapter, we describe a process for the recurring and sustainable discovery, handling, and treatment of quality defects in software systems. An annotation language is presented that is used to store information about quality defects found in source code and that represents the defect and treatment history of a part of a software system. The process and annotation language can not only be used to support quality defect discovery processes, but is also applicable in testing and inspection processes.


2018 ◽  
Vol 8 (2) ◽  
pp. 149-160
Author(s):  
Oliver Götz ◽  
Yin Wai ◽  
Sandra Klein ◽  
Michael Gras ◽  
Michael Werner ◽  
...  

At Gothaer Insurance Group, a long-term program to introduce a new policy system was terminated without the desired outcomes. A new program, GoSMART, was introduced to buy a policy system instead of developing it in-house. A team responsible for modelling insurance products decided that the waterfall approach was no longer suitable for this specific task. Intrigued by the possibilities that agile software development appeared to hold, the team adopted Scrum, hoping to improve efficiency. With no other project changing the development approach, the team was left as an agile island in a waterfall environment.


2015 ◽  
Vol 32 (3) ◽  
pp. 214-235 ◽  
Author(s):  
Subhas C. Misra ◽  
Virender Singh

Purpose – Software development life cycle (SDLC) has always been the core methodology for any software engineer that depicts the entire development process which an organization is bound to utilize to achieve successful software. The purpose of this paper is to bring forth a conceptual model after analysing the best practices in SDLC, and extracting the best out of agile methodologies and the open source software, thereby bringing forward an optimised structure. Design/methodology/approach – The OASDLC is hypothesized specifically for “Brihaspati” project and is formulated keeping in mind the gaps and limitations posed by existing SDLC models. OASDLC is further put to test for achieving lower costs and efforts involved. The tests are further substantiated by means of hypothesis validation through execution of a survey based research. Findings – It has been observed that the present conceptual model further optimizes the efforts involved while adopting such a practice. Originality/value – This paper proposes a novel SDLC model so as to achieve a best practice for a software project. On analysing the issues involved such as tight budget and timelines, it led the authors to formulate a newer concept “Open Agile Software Development Life Cycle model” (OASDLC).


2018 ◽  
Vol 2 ◽  
pp. e25580
Author(s):  
Markus Englund ◽  
Mikko Heikkinen ◽  
Lisa Sundström

In order to ensure long-term commitment to the DINA project (“DIgital information system for NAtural history data”, https://dina-project.net), it is essential to continuously deliver features of high value to the user community. This is also what agile software development methods try to achieve by emphasizing early delivery, rapid response to changes and close collaboration with users (see for example the Manifesto for Agile Software Development at http://agilemanifesto.org). We will give a brief overview on how current development of the DINA collection management system core is guided by agile principles. The mammal collection at the Swedish Museum of Natural History will be used as an example. Developing a cross-disciplinary collection management system is a complex task that poses many challenges: Which features should we focus on? What kinds of data should the system ultimately support? How can the system be flexible but still easy to use? Since we cannot do everything at once, we work towards a minimum viable product (MVP) that contains just enough features at a time to bring value for selected target users. In the mammal collection case, the MVP is the simplest product that is able to replace the functions of the current system used for managing the collection. As we begin to work with other collections, new MVPs are defined and used to guide further development. Thus, the set of features available will increase with each MVP, benefiting both new and current users. Another big challenge is migration of legacy data, which is labor intensive and involves standardizing data that are not compatible with the new system. To address these issues, we aim to build a flexible data model that allows less structured data to coexist with more complex, highly structured data. Migration should thus not require extensive data standardization, transformation and cleaning. The plan is to instead offer tools for transforming and cleaning the data after they have been imported. With the data in place, it will be easier for the user to provide feedback and suggest new features.


2018 ◽  
Vol 31 (1) ◽  
pp. 41-62 ◽  
Author(s):  
Uta Schloegel ◽  
Sebastian Stegmann ◽  
Alexander Maedche ◽  
Rolf van Dick

Purpose Research on agile software development (ASD) has so far primarily focused on processes and tools. Recently, researchers have started to investigate the social dimensions of ASD. The authors contribute to this and examine the largely invisible psychological factor of age stereotypes as one important social dimension of ASD. Driven by demographic change, employees of different age groups will need to work closely together in ASD in the future. However, age stereotypes can hinder many aspects of communication, cooperation and coordination in these self-managed teams. The purpose of this paper is to identify and differentiate age stereotypes in ASD. Design/methodology/approach A quantitative survey at the individual level was conducted with 464 employees in two software development companies. The authors developed an age stereotype model for ASD and developed two scales to measure performance expectations (PEs) in ASD. Findings Employees in ASD show a bias in general PEs, favoring middle-aged employees over both younger and older employees. The perceived PE of a developer decreases over working life. Furthermore, the data show a complex interplay of age and job role in both the research participants and the group evaluated. Younger developers hold the strongest negative age stereotypes and older developers suffer most from stereotypes. Practical implications Management should enact formal or informal measures against stereotypes when an older or younger employee joins a team of members of other age groups, or when a new team is formed. In addition, the authors propose human resources to create permeable career paths. Originality/value The study extends the stereotype content model by adding additional age groups and including job role as a moderating variable. It identifies obstacles in daily employee interactions in agile development, and proposes ways of incorporating invisible psychological aspects in ASD-specific theories.


Sign in / Sign up

Export Citation Format

Share Document