Agile Enterprise Engineering: Smart Application of Human Factors: Models, Methods, Practices, Case Studies (Smart Innovation, Systems and Technologies, 175) [1st ed. 2020] 3030409880, 9783030409883

Citation preview

Smart Innovation, Systems and Technologies 175

Sergey V. Zykov Amitoj Singh

Agile Enterprise Engineering: Smart Application of Human Factors Models, Methods, Practices, Case Studies

123

Smart Innovation, Systems and Technologies Volume 175

Series Editors Robert J. Howlett, Bournemouth University and KES International, Shoreham-by-sea, UK Lakhmi C. Jain, Faculty of Engineering and Information Technology, Centre for Artificial Intelligence, University of Technology Sydney, Sydney, NSW, Australia

The Smart Innovation, Systems and Technologies book series encompasses the topics of knowledge, intelligence, innovation and sustainability. The aim of the series is to make available a platform for the publication of books on all aspects of single and multi-disciplinary research on these themes in order to make the latest results available in a readily-accessible form. Volumes on interdisciplinary research combining two or more of these areas is particularly sought. The series covers systems and paradigms that employ knowledge and intelligence in a broad sense. Its scope is systems having embedded knowledge and intelligence, which may be applied to the solution of world problems in industry, the environment and the community. It also focusses on the knowledge-transfer methodologies and innovation strategies employed to make this happen effectively. The combination of intelligent systems tools and a broad range of applications introduces a need for a synergy of disciplines from science, technology, business and the humanities. The series will include conference proceedings, edited collections, monographs, handbooks, reference books, and other relevant types of book in areas of science and technology where smart systems and technologies can offer innovative solutions. High quality content is an essential feature for all book proposals accepted for the series. It is expected that editors of all accepted volumes will ensure that contributions are subjected to an appropriate level of reviewing process and adhere to KES quality principles. ** Indexing: The books of this series are submitted to ISI Proceedings, EI-Compendex, SCOPUS, Google Scholar and Springerlink **

More information about this series at http://www.springer.com/series/8767

Sergey V. Zykov Amitoj Singh •

Agile Enterprise Engineering: Smart Application of Human Factors Models, Methods, Practices, Case Studies

123

Sergey V. Zykov Higher School of Economics National Research University Moscow, Russia

Amitoj Singh Maharaja Ranjit Singh Punjab Technical University Bathinda, Punjab, India

ISSN 2190-3018 ISSN 2190-3026 (electronic) Smart Innovation, Systems and Technologies ISBN 978-3-030-40988-3 ISBN 978-3-030-40989-0 (eBook) https://doi.org/10.1007/978-3-030-40989-0 © Springer Nature Switzerland AG 2020 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

To God, my teachers, and my family

Foreword

In their book, Prof. Zykov and Dr. Singh address human factors and provide valuable insights on harnessing these factors to foster large-scale software engineering, specifically in the areas of technology and knowledge transfer. Surprisingly, many of present-day tech leads and project managers tend to neglect the impact of these mostly irrational and typically uncertain human-related factors on software development processes, treating these processes as a purely technical matter. This careless underestimation often results in what the authors call a “crisis,” i.e., a situation when the project resources in general and human factors in particular go beyond the managers’ control. In such critical circumstances, agile methods seem an evident solution and an instant remedy. However, a straightforward or blunt application of these trendy and much discussed agile frameworks, without proper product design and disciplined development, would clearly lead to the same “crisis” trap, triggered with, perhaps, the same root cause. Therefore, the book systematically approaches the problem of taming human factors in a “peeling an onion” way. It starts from discussing technical and rather formal models and methods, and then proceeds to more practical patterns and case studies. The latter include two environments, similar in purpose, yet clearly distinct in location and ownership: the Indian Chitkara and Russian Innopolis ecosystems. Importantly, these distinctions reveal a vast spectrum of varieties, including cultural and regional ones, and provide a deep insight on managing human factors, in order to promote large-scale project efficiency and their eventual success. The broad focus of this concise book makes it a handy guide for software developers, while the case studies may serve as a troubleshooting reference in

vii

viii

Foreword

project management. The authors are experts who have firsthand experience in software engineering. Their integrated expertise will definitely contribute to better managed large-scale software production in the future. Alfredo Cuzzocrea, Ph.D. Professor of Computer Engineering, DIA Department Head, Big Data Engineering and Analytics Lab University of Trieste, Trieste, Italy Research Fellow ICAR Institute Italian National Research Council

Preface

The subject of this volume is agility in large-scale systems development. The term “systems” embraces not only software, but also IT-intensive businesses, i.e., enterprises. These are international, distributed ventures, which typically incorporate a number of diversified companies. However, what is agility? An intuitive understanding would give a naive instantiation of a puma or cat. Interestingly, these creatures were worshiped and praised in many ancient cultures, including Egypt and Peru. In Egypt, the cat was associated with supernatural powers. In Peruvian culture, the puma was the patron of the living creatures (the snake was the same for the dead and the condor for the immortal). In our case of large-scale systems, one of the hampering factors in their development is complexity. Commonly, this is represented in terms of the number of components multiplied by the number of their interconnections. The larger the system, the more is its complexity. Obviously, this problem of complexity dramatically complicates large-scale system management, as the Babylon Tower effect is very likely to happen. One way to conquer this complexity factor is the “divide-and-conquer” strategy. However, if applied too formally or carelessly, this strategy alone may be insufficient. The reason is that complexity has a number of aspects, the two principals of these being technical and managerial. The first one is often manageable by means of classical optimization and concern separation methods. To manage the second one, the above-mentioned approaches would not suffice, as they are rather formal and, therefore, rigid. Surprisingly for many technically oriented experts, in the enterprise systems, and even in the software ones, the managerial aspect of complexity is often predominant and is the most likely reason for system development crises. Naturally, after the disaster has happened, the managers tend to blame the technologies, as they often do not realize (and sometimes neglect or even ignore) the so-called human-related factors.

ix

x

Preface

Therefore, in this critical event of crisis, which often originates from the human factors that hinder the information transfer between the client and the producer (and inside their teams, which are complex systems by themselves), agility comes into play. Informally, we can understand agility as adaptability, flexibility, and responsiveness. Following the agile way is particularly important in case of development crisis that manifests itself as process uncertainty of different origins (such as quality attributes, budget gaps, or team “storming,” i.e., fluctuating project parameters or product requirements). This agility way incorporates multiple aspects of communication (e.g., negotiation, teamwork, self-reflection, etc.), often referred to as “soft” skills as opposed to the “hard” skills required for the system development managers. Proper application of these human factor-based management techniques and practices usually improves project communication and, therefore, helps to manage (i.e., avoid or mitigate) development crises. A recent use case of agility in business and technology is the digital transformation. This kind of crisis has been triggered by the Industry 4.0 paradigm and affects any present-day enterprise. In this scenario, process agility is often the critical indicator, which tells whether a business is going to succeed or die out as the ancient dinosaurs that could not accommodate to rapid environment changes. Hence, we systematically address agility in this book and provide a “survival kit” that includes a set of models, methods, practices, and case studies. As such, the formal (i.e., technological) side of the complexity problem is discussed thereafter to a less extent, as that was the focus of our previous books, “Crisis Management for Software Development and Knowledge Transfer” (Springer, 2016) and “Managing Software Crisis: A Smart Way to Enterprise Agility” (Springer, 2018). Instead, we specifically address the human factor-based communication problems related to knowledge transfer and diversity. Therewith, we illustrate the agile practices and present case studies of large-scale and IT-intensive ecosystems, in their digital transformation crises. We hope that this book will become an essential “first-aid kit” and successfully assist in agile enterprise management. Moscow, Russia Bathinda, India

Prof. Sergey V. Zykov Dr. Amitoj Singh

Acknowledgements

I would like to thank the colleagues of mine who significantly contributed to this book. They clarified my initially vague concepts and assisted in a number of processes including translation, copyediting, diagramming, etc. These are the students who did their master/Ph.D. theses under my supervision. A few of their takeaways were transformed and included in this book as case studies on agility improvement. They are: Kamila Agayeva, Ali Akbari, John Dadzie, Dilara Dilber, Ramis Gabeydulin, Sergey Korobin, Joseph Lamptey, Nikita Morgun, Hanieh Mortazavi, Dinara Nikolaeva, Lyubove Smirnova, Sabina Supibek, Ella Tyuryumina, and Svetlana Zlobina. I would like to thank the Springer Executive Editor Dr. Thomas Ditzinger, the Springer Senior Editor Mrs. Aninda Bose, the Springer Senior Executive for Production Mr. Ashok Kumar, and the Springer Project Coordinators for Books Production, Mr. Daniel Joseph Glarance and Mr. Ravivarman Selvaraj, for their continuous availability and prompt assistance. In addition, I would like to express my deep appreciation and sincere gratitude to the Editors in Chief of the Springer Series in Smart Innovation, Systems and Technologies, Prof. Lakhmi C. Jain and Prof. Robert J. Howlett, for their tireless efforts in supporting my ideas. I would like to extend my thanks to the entire Chitkara team, and particularly to Dr. Archana Mantri and Mr. Sanjeev Sahni for their enthusiasm and cooperation.

xi

Introduction

Why Agility Matters This book focuses on agility engineering in large-scale systems. To do this in a smart way, we suggest a multifaceted approach that carefully blends models and methods, and includes patterns, principles, and practices. This approach would be incomplete if it did not address the human-related factors. Booch explained that in architecting large-scale systems (including enterprise ones—see Fig. 1), there are a number of dimensions of complexity. Of these, managerial and technical dimensions are essential. However, depending on a particular system type, one of these dimensions may dominate. The simplest system in both dimensions is an Excel spreadsheet. A typical example of a very technically complex system is a large telecommunication switch. Surprisingly for many technical experts, the enterprise systems are complex in terms of management. Of course, this does not mean that they are technically simple. However, it is their managerial complexity which is mission-critical and, therefore, it often is a root cause of system development crises. We have discussed these crises in our previous books [2, 3]; they typically result from imbalance between available resources, business requirements, and technical constraints. We stated that “in software development … a crisis is … a disproportion between client’s expectations and the actual product behavior.” How can this disproportion happen? Very often, this happens as a result of miscommunication in a complex system of multi-sided project participants (at a minimum, including client team, developer team, and their management teams). Lack of resilient and responsive communication with proper (timely, focused, and goal-directed) feedback often results in distorted product vision and consequently wrong product development and delivery. In case we treat an enterprise as an “adaptive socio-technical large-scale system” [4], it includes such sub-systems as social and technical. As such, the social sub-system operates by means of messaging. Consequently, “organization is communication” [2]. Therefore, the focus of this book is the managerial aspects of the agile development; these are related to the so-called human factors. To determine the complexity of the management

xiii

xiv

Introduction

Fig. 1 Technical and managerial complexity in large-scale systems (Booch, G.: Software Architecture and the UML, 2006)

framework, we provide a brief outline of the lifecycle models and methodologies. Our idea is to provide guidelines for flexible (i.e., agile) adjusting the project parameters “on the move.” As such, we analyze the model-and-methodology frameworks to explain the ways of their smart tailoring and agile adjustment by means of trade-off optimization of the managerial dimension of complexity based on the human factors. To deeper understand and master agile adjustment techniques and practices, we suggest a set of case studies, which we believe are a powerful approach to develop analytical and decision-making skills. Gill argues that case studies are especially suitable for conquering complexity in large-scale systems and better informing [5]. He also states that “… case studies … are likely to be the most rigorous form of research in many—if not most—settings where the fundamental test of our research value is its applicability to practice” [5]. Moreover, case studies address the higher levels of Bloom's taxonomy such as analysis, synthesis, and evaluation [1]. The case studies this book presents include enterprise scale systems which are either IT intensive/dependent or which focus on IT development/training. These are: Chitkara University Innovation and Research Network (India) and Innopolis Ecosystem (Russian Federation). One mission-critical human factor that we address is diversity. We systematically address this factor in aspects such as: • culture, • mentality, • production process maturity.

Introduction

xv

Therefore, we include comparative studies of the same domain in diverse conditions and analyze their similarities and comparative differences. Our case studies contain the stories of innovative ecosystems. The domain is university training. This is generally known and, therefore, easily comprehensible. Our approach to diversity embraces locations such as India and Russia; these are combined with predominantly state vs. private ownership, and different timelines. Our systematic approach includes a multi-context case study analysis. The case studies are multifaceted by themselves as they include multiple interpretations [5]. However, their smart application, in our view, requires comparative SWOT analysis that we include in this book. Based on that, we provide an agility checklist in the form of do’s and don’ts. This book is organized as follows. Chapter 1 summarizes the key concepts, such as agility and human factors. It outlines flexible strategies for smart software development and process improvement. Chapter 2 analyzes diversity in terms of culture, mentality, organization structure, development stage, and process maturity, relating these to system agility. It discusses large-scale software development in certain domains. Chapters 3 and 4 address Agile Knowledge Management and provide retrospective and context-specific examples, which make a solid basis for the following case studies. Chapter 5 investigates agile development at individual and team levels. Chapter 6 cross-examines the case studies on large-scale innovative and IT-intensive ecosystems. These are analyzed in terms of agility in different and diverse contexts including human-related factors. The conclusion summarizes the key findings of the book. It suggests ways for smart and agile large-scale software development. Specifically, we consider the process and quality improvement approaches and lifecycles. Concerning the process frameworks for software development, we briefly discuss certain aspects of the “5A” model, DSDM, and DAD (Chaps. 3 and 5), and a number of other approaches such as: • RUP (Rational Unified Process initiated by Rational Co. and later acquired/updated by IBM Corp.), • MSF (Microsoft Solutions Framework, their de facto corporate standard), • Scrum (a pioneering agile methodology incorporating techniques from sports and movie making), • XP (Extreme Programming that originally failed for automobile production but was surprisingly successful in IT), • Agile (one of the recent approaches that incorporates the merits of its predecessors). These approaches received more coverage in [2, 3]. Our survey concludes that for each software product lifecycle and its individual stage, agility essentially assists in improving development patterns and practices. However, for every software project the developers must align this agility level with the key performance indicators, which are unique. Therefore, for the project success the developers should systematically approach this agility by means of multifaceted

xvi

Introduction

and multi-contextual parameter prioritization and adjustment. This adjustment should focus on the agility improvement techniques and practices that optimize the critical lifecycle stages. Further, concerning the case studies, we follow the approach suggested by Gill, the case method guru from Harvard Business School who successfully defended over 900 of such assignments while being a student and later developed his own case method-based teaching framework [5]. This includes: • • • •

the story narrative, walk-through, discussion, takeaways.

As these case studies deal with diverse environments (in terms of culture, mentality, religious beliefs, funding sources, and a number of other aspects), we conclude that environments often critically matter as a business success factor. The other finding is that the choice of a lifecycle pattern (such as waterfall, evolution, scrum, extreme) should be well aligned with a number of parameters, which include the functional and quality attributes of the future product, high-level project goals, and human-related factors that include multi-dimensional diversity. This book will recommend lifecycle adjustments and process improvements that will help to establish and maintain agility in the competitive software development market. These recommendations are based on real-world case studies. This book does not contain a “silver bullet” agility recipe. Instead, it recommends patterns and practices that assist in crisis-responsive and agile large-scale software development.

References 1. Bloom, B. S. (1956). A taxonomy of educational objectives (2nd ed.). Addison-Wesley Longman Ltd. 2. Zykov, S. V. (2018). Managing software crisis: A smart way to enterprise agility (p. 153). Switzerland: Springer International Publishing. 3. Zykov, S. V. (2016). Crisis management for software development and knowledge transfer (p. 133). Switzerland: Springer International Publishing. 4. Gromoff, A. (2010). A study of the subject-oriented approach for automation and process modeling of a service company. S-BPM ONE, 2010 (pp. 192–206). 5. Gill, G. T. (2011). Case method informing with the case method: A guide to case method research, writing, & facilitation (p. 562). Informing Science Press.

Contents

1 From 1.1 1.2 1.3

Ad Hoc to Agility: A General Framework . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . Engineering in Software Development . . . . . . . Causes of the Crisis—The NATO Conference, the Birth of Software Engineering . . . . . . . . . . 1.4 Crisis: Myths and Reality . . . . . . . . . . . . . . . . 1.5 Software Development Lifecycle . . . . . . . . . . . 1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

............. ............. .............

1 1 2

. . . . .

. . . . .

. . . . .

. . . . .

4 8 13 15 16

2 Sociocultural Aspects of Agility . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Culture in Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Cultural Challenges in Implementing Agile Methods . . . . . . . 2.4 Cultural Challenges in the Global Market . . . . . . . . . . . . . . . 2.5 Cultural Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Power Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Individualism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Masculinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 Assumed Relationship Between Agile and National Cultures . 2.10 Egalitarian Power Distribution, Collectivism, and Agile Self-organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Individuals and Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 2.12 Goal Setting and Sustainability . . . . . . . . . . . . . . . . . . . . . . 2.13 Lessons Learned from Global Agile Implementations . . . . . . 2.14 Accessible Communication Channels . . . . . . . . . . . . . . . . . . 2.15 Context for Openness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16 New Communication Channels . . . . . . . . . . . . . . . . . . . . . . 2.17 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

19 19 20 22 22 24 26 26 27 27

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

28 29 30 32 32 32 33 34 35

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

xvii

xviii

Contents

3 Agile 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Knowledge Management . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Epistemological Perspectives on KM . . . . . . . . . . . . . Knowledge Management in Practice . . . . . . . . . . . . . Challenges in Agile Software Development . . . . . . . . Managing Knowledge in Agile Development Process . Agile Knowledge Management Theories . . . . . . . . . . Agile Knowledge Creation Theories . . . . . . . . . . . . . . Knowledge Management Strategies in Agile Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Knowledge Involved in Agile Practices . . . . . . . . . . . 3.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Agility at Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Understanding the Scale . . . . . . . . . . . . . . . . 4.3 Leading Agile by Being Agile . . . . . . . . . . . . 4.4 Getting Agile Rolling . . . . . . . . . . . . . . . . . . 4.5 Create Taxonomy of Teams . . . . . . . . . . . . . . 4.6 Sequence the Transition . . . . . . . . . . . . . . . . 4.7 Roll-Out Agile in Steps . . . . . . . . . . . . . . . . . 4.8 Master Large-Scale Agile . . . . . . . . . . . . . . . 4.9 Building Agility Across the Business . . . . . . . 4.10 Values and Principles . . . . . . . . . . . . . . . . . . 4.11 Operating Architectures . . . . . . . . . . . . . . . . . 4.12 Talent Acquisition and Motivation . . . . . . . . . 4.13 Annual Planning and Budgeting Cycles . . . . . 4.14 Best Practices . . . . . . . . . . . . . . . . . . . . . . . . 4.15 Failure of Agile in Large Organization . . . . . . 4.16 Lack of Clarity . . . . . . . . . . . . . . . . . . . . . . . 4.17 Continual Reliance on Legacy Methods . . . . . 4.18 Inadequate Experience with Agile . . . . . . . . . 4.19 Looking for Testing Strategy . . . . . . . . . . . . . 4.20 Lack of Alignment in Areas of the Enterprise . 4.21 Larger Teams and Pyramid Structures . . . . . . 4.22 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

37 37 39 42 42 44 46 46

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

48 50 51 52

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

55 55 56 57 57 58 59 59 60 60 61 61 62 63 65 67 67 68 68 69 70 70 71 71

Contents

5 Mastering Agility . . . . . . . . . . . . . . . . . . . 5.1 Introduction . . . . . . . . . . . . . . . . . . . 5.2 Disciplined Agile Delivery (DAD) . . . 5.3 Agile for People . . . . . . . . . . . . . . . . 5.3.1 Individual Competence . . . . . 5.3.2 Team Competence . . . . . . . . 5.3.3 Build Effective Relationships 5.4 Conclusion . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . .

xix

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

6 Developing and Fostering Smart Ecosystems . . . . . . . . . . . . . 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Case Study: Chitkara University Research and Innovation Network (CURIN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 History and Achievements . . . . . . . . . . . . . . . . . 6.2.2 Chitkara Structure and Projects . . . . . . . . . . . . . . 6.3 Case Study: Innopolis University and Ecosystem . . . . . . . 6.3.1 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 The University of Innopolis . . . . . . . . . . . . . . . . 6.3.3 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.4 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.5 Innopolis Ecosystem: Conclusion . . . . . . . . . . . . 6.4 Case Study: Comparing CURIN and Innopolis . . . . . . . . . 6.4.1 Project Timelines . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Research Centers . . . . . . . . . . . . . . . . . . . . . . . . 6.4.4 Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.5 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.6 Salaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.7 Student Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.8 Arts and Culture . . . . . . . . . . . . . . . . . . . . . . . . 6.4.9 SWOT Analysis of the Innopolis University . . . . 6.4.10 Questions for Discussion . . . . . . . . . . . . . . . . . . 6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

73 73 80 86 87 87 88 89 90

..... .....

91 91

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

92 92 96 104 105 107 108 117 119 119 119 121 123 124 125 125 126 127 128 128 129 129

Conclusion. Reaching Agility in Diverse Environments . . . . . . . . . . . . . . 131 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Acronyms

3D 6D ACDM AKM API ASD ATAM BI CAD CAE CAM CASE CMM(I) CMS CMU CoPs COTS CRM DAD DBMS ERP FDD GDP GSD GUI HR IBM ICT IEC IP

Three dimensions Six dimensions Architecture-centric design method Agile Knowledge Management Application programming interface Agile software development Architectural trade-off analysis method Business intelligence Computer-aided design Computer-aided engineering Computer-aided manufacturing Computer-aided software engineering Capability Maturity Model (Integration) Content management system Carnegie Mellon University Communities of practice Commercial off-the-shelf Customer relationship management Disciplined agile delivery Database management system Enterprise resource planning Feature-driven development Gross domestic product Global Software Development Graphical user interface Human resources International Business Machines (Corporation) Information and communication technologies International Electrotechnical Commission Intellectual property

xxi

xxii

ISO IT KLOC KM LC MSF MSIT-SE NATO NPP PLM PSP ROI RUP SCADA SE SEI TEP XP

Acronyms

International Standards Organization Information technology Kilo lines of code Knowledge Management Inductor, represented by the letter L, and a capacitor, represented by the letter C Microsoft Solutions Framework Master of Science in Information Technology–Software Engineering North Atlantic Treaty Organization Nuclear power plant Product lifecycle management Personal software process Return on investment Rational unified process Supervisory control and data acquisition Software engineering Software Engineering Institute Teacher education program Extreme Programming

Chapter 1

From Ad Hoc to Agility: A General Framework

1.1 Introduction This chapter begins with the effects of human factors on software development and continues to discuss the crisis in software systems, the birth of software engineering, crisis myths and reality, and the crisis factors and methods of their management. The first part of this chapter elaborates on how the crisis sprung up, and it shows that with suitable team building, appropriate team selection, and discipline we are able to resist the crisis. The crisis is a result of the disparity in the resources such as time, budget, and labor. The developers need to ensure the quality of software products. Therefore, the interaction between the customer and the developer becomes essential. Further, this chapter presents the causes that led to the crisis in the software industry of the 1960s. One of these causes was the contradiction between the resources and the constraints of the industrial products. These issues detected in software engineering were very similar to the drivers of the industrial revolutions that happened earlier in history. Software engineering as a discipline appeared in 1968 at the NATO conference where it was decided to move to a more systematic and efficient development of the software products. This chapter studies the crisis phenomena that emerged in the development of complex and large-scale software systems. Also, the chapter focuses on the trade-off between the high complexity and the mission-critical features of new hardware systems. This chapter further considers how the idea of crisis in software engineering arose and what misconceptions or myths appeared. It concludes that the software industry is in crisis and suggests developing a specific technological discipline that would ensure a more systematic way for the production of software. Further, this chapter discusses how we can conduct software development in crisis in order to meet time and budget. Additionally, it addresses the myths that arise from developers, customers, and their management. It discusses the similarities and differences between a software and a material product.

© Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0_1

1

2

1 From Ad Hoc to Agility: A General Framework

The final part of this chapter considers how software is developed in terms of the lifecycle stages. Regardless of the model and methodology used, these include requirement analysis, requirement specification, design, implementation, and maintenance.

1.2 Engineering in Software Development Let us discuss the crisis in software development, concerning a human factor perspective. This standpoint focuses on the interaction of the development and the customer teams. The interaction of these teams can result in development crises of software systems. First, we consider how the crisis started and how software engineering emerged as a response to this crisis. We discuss how development and customer teams work as self-adaptive systems. Such systems are largely self-managed, especially when implementing flexible methodologies (or agile approaches as opposed to the formal ones). The aim is to demonstrate how a proper team building and selection of the team members form adaptive management of the software product development and help to resist the crisis. Let us recall the crisis in the development of software systems in the 1960s. In fact, any software crisis is a consequence of the imbalance in the three kinds of resources: • the time, • functions that we need to implement in our software system, • other resources, primarily human factor-related. In this view, we will focus on the human resources, an imbalance of which may lead to a crisis. In the case of the crisis in the development of software systems that happened in late 1960s, in many ways it did. Therefore, let us focus on the product attributes; the scope and scale of the product; time, financial and other kinds of resources; and the related factors of the interaction of developer and customer teams that typically lead to crisis. The primary goal of the software developers is to avoid these crisis phenomena. Let us recall the scheme in the shape of a triangle [1], which shows how a crisis can occur (see also Fig. 1.1). It has the inner zone also known as the comfort zone, where a significant imbalance between the resources is not observed and the development continues normally. However, problems may arise in case of product priority changes, project budget constraints, or due to a misunderstanding between the developer and the customer. It is still possible to reach a compromise, to balance the parameters of the project triangle, and to avoid a crisis. Conversely, as soon as the project parameters get into the next zone, which is the crisis zone, in certain cases, the crisis is unavoidable. As the answer to these crisis phenomena, the discipline of software engineering emerged, aiming to build large, complex, and replicable software products. These products are typically constructed by a single or multiple development teams for the customer’s team. The mission-critical aims are to develop the software product

1.2 Engineering in Software Development

3

Fig. 1.1 Project management triangle

under a limited budget, time, and other resources of the developer and customer teams, ensuring an acceptable quality of this product. At the same time, it is essential to adopt predictable planning and management practices, which largely assist in efficient application of the “soft skills” that include communication, negotiations, and teamwork. Let us note that in software engineering the process of coding itself is not so important, because it constitutes about 5% of the total cost of developing a software product. However, a significant part of the development success relates to the human factor. Therefore, the quality of interaction between the developer and the customer becomes extremely important. With large-scale development, it is missioncritical to keep undistorted the original idea (vision) that the customer desires to see as the final product. For productive interaction with a customer, the development team needs these above-mentioned soft skills. What was the key problem in the software crisis of the 1960s? First, it was the high complexity of systems created, and the high computational power of the new generation computers. There was a problem of how an individual can contribute to this complex scheme, in which huge teams work on the systems with a large number of powerful computers. Another issue was managing the software development process so that it becomes more reliable and better predictable, and eventually yielding a quality product. To achieve this, it was required to adjust the human factor, which was actually the root cause of the massive crisis failures in the development of the software systems (see also Fig. 1.2).

4

1 From Ad Hoc to Agility: A General Framework

Size Labor costs

Complexity LimitaƟons

Development

People

Cost Schedule

Environment Fig. 1.2 Constraints in software development

1.3 Causes of the Crisis—The NATO Conference, the Birth of Software Engineering Let us consider in more detail what caused the crisis in the software industry and draw certain parallels with the economy situation and the industrial production of material products. In the USA, the phenomenon that followed the crisis is well known and referred to as the Great Depression. The crisis trigger was a huge gap between the resources and the capacity of the production, including industrial products. Those products were of either inadequate quantity (i.e., overproduction) or inadequate quality to meet the demand of their customers. The consequence of this crisis was the Great Depression, that is, a relatively long period of stagnation. It took the production many years to return to the pre-crisis rates. Similar software product-related phenomenon occurred in software engineering, which came into being as a response to that crisis. However, it was not a panacea as it was a means of solving crisis problems, rather than a guarantee that these problems would be solved. Similarly, the current global economic crisis is a certain imbalance between production and consumption. At this point, it makes sense to establish relationships between: • software engineering, • the process of production of software systems, and • the process of production of material systems. These material and software systems were discussed at the NATO conference in 1968 [2]. What are the systems that are similar to the software systems in terms of production? Let us recall analogies between the construction of buildings and bridges, i.e., the structures where a large number of heterogeneous teams are responsible, say, for laying wires, communications, and the construction of buildings made of concrete blocks (or monolithic construction), welding, modeling this rather complex design in terms of aerodynamics and hydrodynamics, etc. It turned out that the wind can cause critical consequences in certain cases. We know about bridge collapses in the 1940s due to hurricanes, which “modeled” system operating in crises [3]. This kind

1.3 Causes of the Crisis—The NATO Conference, the Birth …

5

of crises often arises in the environment where multiple teams work and which is complex to manage. What was the software development like in the 1960s? What kind of teams, tools, and technologies were used? How the software production evolved? Let us note that software development was somewhat similar to the progress of the material production. First, these were the pioneers, innovators, and revolutionaries, who produced custom software products using unique resources and capabilities. In fact, a large number of the early software systems were developed in the 1940s, including military applications, which were created by talented individuals. Few of these gifted minds that used specific programming languages had a development environment, specifically intended for military systems and particular instances of the military equipment. Most of these software products and tools were unique. Some of these products were unable to interact with the others, as they were often based on completely different approaches, principles, and technologies. At that time, it was hard to talk about unification, standardization, and compatibility. The endeavors of the 1940s and 1960s were aimed at coordinating the silos of these products within the framework of army management. For the products developed by these skilled individuals, the ultimate purpose was creating and managing the national military system. Due to their low compatibility, discussing any coordination appeared challenging. This early stage resembles the old fine arts of creating unique, high-quality products crafted by individual inventors. Further, “guilds” appeared. These were the groups or teams with certain patterns of specialization and cooperation. For instance, some team members did more testing while the others did more coding. However, in terms of lifecycle and established software process with clear quality criteria at the end of every stage (such as requirements specified, product tested, product is ready for transfer to customer), this was still premature. This stage can be qualified as the manufacturing. That is, machines partially automate the production process. In case of software production, compilers and standard programming languages are the tools for component-based production of the extendable software systems with the standard interfaces. However, the manufacturer’s manual labor was still there. Therefore, the software production was not fully automated yet. The next stage was a conveyor production. One kind of such tools was akin to the IBM Rational product line. These supported individual lifecycle phases (such as testing, coding, design). Such tools also supported multitasking in individual lifecycle phases and even development teams as a pipeline; that is, the output of one of these tools served as the input of the next tool. For example, the software modules developed with one tool were integrated and tested by another tool. Microsoft takes a different approach of a common .NET platform and the Visual Studio development toolkit, which coordinates the processes associated with the design, coding, debugging, and testing. Therefore, the processes of integration, transfer to commercial operation, and maintenance and development of new product releases happen on a common basis of this same platform.

6

1 From Ad Hoc to Agility: A General Framework

Certainly, a few similarities regarding the progress of economic development can be identified for the software and material products. However, such similarities do not mean identity as the lifecycle of a software system is significantly different from that of a material product. Let us consider the processes of software systems development. An evident trigger for the software crisis of the 1960s was increasingly high complexity of the software systems, which had both technological and managerial aspects. This complexity required coordinating a large number of parallel processes and implementing relatively complex functions in the software products. Typical examples of such products included management and coordination of fronts and armies within the framework of the military control systems. To manage such a complexity, software engineering came into being. However, this was a great challenge, regardless of those large and powerful software and hardware systems (such as the famous B-5000 computer). Another challenge was the contradiction between the complexity of software products and the performance of the hardware systems available; therewith, the human resource management methods were insufficiently effective. The NATO conference experts decided to move to a more systematic and productive design, implementation, and maintenance of the software systems. That decision required a new theoretical and technical basis for the development of software systems, later known as software engineering. Which aspects of complexity are critical for large-scale and agile software systems? Currently, software systems often operate with terabytes and petabytes of data, which are 1012 and 1015 bytes, respectively; sometimes, we can speak about exabytes, or 1018 , of data bytes. The other aspect of complexity is the number of system components. This often amounts to thousands of files, hundreds of interacting modules, and dozens of large-scale software systems. One example of a complex enterprise software product is the Oracle E-Business Suite, which combines a number of systems for accounting, planning, and managing resources, including financial and human resources, documents, projects, time, etc. To manage high complexity, it is necessary to ensure the proper level of quality. This often includes criteria for measuring the software product quality, which must be prioritized. In addition to time, cost, labor, and functionality, these criteria often include specific attributes, such as bandwidth, accessibility, system response time, usability, security, reliability, portability, and a range of other features, determined by the industry standards. The software project managers should also consider intensive use and strategic reuse of the previously developed larger modules (or smaller components) for the future software products. They should also take into account the architectural complexity of the software systems. One example is an enterprise portal, which aggregates a large number of interacting systems of various types. These systems provide decision support, planning and managing resources, operation management, data acquisition and control, and database management. Another example is a set of heterogeneous systems, typically implemented under different architectural patterns, which support both well-structured data (such as

1.3 Causes of the Crisis—The NATO Conference, the Birth …

7

relational tables) and weak-structured data (such as audio, video information etc.). Software engineering methods and tools coordinate all these systems. To study the crises phenomena in the development of software systems, let us discuss the subsequent stage of a crisis, which is called depression. Schach states that software engineering is in many ways still in a state known as post-crisis depression [4]. What is this post-crisis depression characterized by? In the 1970s and later, a number of research and development centers established standards for high-quality software production. One of them was collocated with the Carnegie Mellon University. It was the Software Engineering Institute. Meanwhile, the crisis was still protracted, despite a large number of such centers developing various methodologies. Currently, software dominates in terms of cost in software projects. Conversely, in the 1950s and 1960s, paramount attention was paid to the hardware [4]. At present, software is the dominant and driving force, while hardware is often less important, except such individual cases as specific clusters, grids, and clouds. The lack of a universal development methodology suggests that the software crisis as a phenomenon will never end, neither will be defeated. That is, this contradiction, which stems primarily from different points of view of developers and customers, has not been resolved, and thus this software crisis is systemic, both technological and managerial. To manage this crisis, we recommend optimizing the lifecycle in order to achieve a more predictable and reliable development of high-quality software systems that meet the deadlines and budget. What conclusions can we draw from the above review? First, the crisis trigger was the imbalance between: (i) high complexity of the new generation hardware, software development, and team management processes, and (ii) clearly limited number of skilled individuals and their abilities to support these new components and processes. At the dawn of the software industry, the unique software products were made by a few extremely talented developers who were “all-in-one” experts, i.e., designers, testers, coders, etc. Next, “guilds” appeared. These were teams of developers, which did not quite follow the fragmented and rather vague software production standards of that time. Further, there were manufactories. That is, software systems were created by manual labor or rather primitive development tools, such as compilers and debuggers. These systems were relatively simple and small. After that, there were conveyors. These were machine tools, which allowed to separate the lifecycle stages (such as testing, integrating), and connect these stages into a single production pipeline [5, 6]. Finally, there was software engineering, which assisted in integrating models, methods, and tools for software production (including large-scale and optimized development). This optimization is based on the constraints and resources available (i.e., HR, time, and functions). It also includes business, technological, and managerial restrictions for customer and developer perspectives. Let us recall that large-scale software systems typically have a rather high managerial complexity, whereas their technical complexity is relatively low. Therefore,

8

1 From Ad Hoc to Agility: A General Framework

within the framework of the software engineering, which emerged as a response to the crisis, team management and other “soft skills” (such as communication, negotiation) become mission-critical [7–9]. A professional software engineer should have a well-balanced combination of technical and managerial skills in order to act efficiently in crises, and develop the software product in an agile way.

1.4 Crisis: Myths and Reality Let us consider how the concept of crisis in software engineering arose, what misconceptions or myths appeared before this crisis happened, how this led, so to speak, to a new reality, and methods of dealing with this crisis. Let us recall that in 1968, in the small town of Garmisch-Partenkirchen located in the German Alps, a conference later known as the “Software Engineering Conference” was held [2]. The above name was introduced by Professor Bauer later at the same event. The conference attendees were the leading experts from NATO countries, who primarily addressed the issues of defense software systems. The participants represented the USA and Europe. Bauer also coined the term “crisis of software engineering,” during a meeting with the NATO experts from Europe, including the famous Professor Dijkstra, who dealt with the problems of concurrent execution of a large number of software systems. As a result, it was decided that the software industry was in crisis, and the experts suggested developing a special discipline or approach, to assist in a more systematic and predictable software production process. This discipline was later known as software engineering, and therefore, the event was referred to as the historical “Software Engineering Conference.” The experts were invited, so to speak, to a closed meeting; this was not an open conference for the leading researchers and practitioners based on their publication lists and report topics. The event was an “invitation only” NATO conference, also attended by the selected representatives of IBM and a few other IT leaders [2]. The B5000 mainframe computer built shortly before the conference was designed to solve the problems of high complexity, which were associated with military operation management. The main issue discussed at this event was developing useful and effective software constrained by limited project resources such as time, budget, and labor. The software development methods which existed at that time did not match the rapidly increasing problem concurrency and system complexity, and the rocketing performance of the emerging computers. Bauer from the Technical University of Munich, a leading research center for business processes, which are very important to consider together with software development processes, came up with the term “crisis.” This term was later used by Dijkstra in his Turing Award Lecture, where he said that this NATO conference initiated the discussion of what was later called the “software crisis” [2].

1.4 Crisis: Myths and Reality

9

In a crisis, what are the typical changes that affect the software development processes? The budget is often significantly reduced, in order to match the shrinking resources. Development teams storm, people move from team to team or quit, etc. Customer’s priorities in functional requirements frequently change; however, the developers have to establish and maintain reliable and predictable processes to deliver a quality software product even under these circumstances. Let us consider certain myths or misconceptions of the customer and the developer, based on the analysis of their previous projects, as there is a number of challenging issues in software development. One of such issues is that a project often requires more time than initially expected; however, the defects are still found long after the product delivery. If we look at, say, how we build architectural structures, we can clearly outline business processes and estimate the time it takes to erect a house or build a bridge, and in general, the process is straightforward. For example, constructing typical building levels or bridge piers is a linear process. Multiple errors are unlikely found in a delivered material product; a bridge seldom collapses and becomes unusable after being built. However, such cases happen. For example, in the 1940s there was a bridge that was completely destroyed by a hurricane, in the USA. This is a classic case found in the textbooks on architecture [3]. Another case happened with Swiss and German engineers, who, around the same period, were constructing a bridge over the Rhine, building from each side. They found at least a half-meter height difference when they tried to join the two parts of the bridge. In general, such inconsistencies occur quite seldom in traditional engineering. In software engineering, it is the crisis that triggers these issues. In a crisis, time to market is often mission-critical. For any software-producing company, this is a vital indicator. Unfortunately, if a start-up company comes out with a software product later than expected, due to high competition, it is almost equivalent to the death of this company. In a crisis, the above issues of residual errors and time to market are paramount in terms of product adjustment to fit the shrinking and storming project resources. Similar issues involve both the developers and customers of the software. These happen in more and more new projects. In fact, these issues relate to the complexity, and the project triangle delimiters. Why is the software product so expensive? In the earlier projects of the old days, the lion’s share of the cost of hardware and software systems was given to the hardware. These were huge machines, which often occupied large rooms or even entire office buildings and consumed a significant amount of electricity. Currently, this situation has changed dramatically. Software dominates, in terms of contribution to the project and its financial component. However, today the big question is: “Why is this software so expensive?” In previous times, even a 30% saving on the software part of the project did not make a significant difference to the budget. Today, this would make a tangible difference, which is important in crisis. Further, why does this software take such a long time to produce? Is it possible to hire twice as many developers (or architects, testers, etc.) to speed up the progress? Why is this speed-up slower than even linear? Why is it difficult to measure the

10

1 From Ad Hoc to Agility: A General Framework

project progress? That is, to determine when, for instance, the developers should stop testing and deliver the product to the customer. Why is it so difficult to complete a certain specific part of the product and start assembling it? Why is it impossible to detect all critical defects before acceptance? Why are there so many bridges (or architectural structures) without critical defects, whereas the software products often face massive collapses due to issues such as “Y2K problem,” and it is not clear how to deal with these? All these questions are difficult to answer, as each project is unique and involves many sides (such as developer, customer, and their management). The number of developer’s roles exceeds a dozen, and this is only a rough approximation of the team structure. These roles have different expectations and different preferences, and therefore, the software production process looks complex from the managerial viewpoint. As such, even reasonable negotiating on terms, cost, or the critical product functions to implement can take considerable time and lead to significant contradictions. A number of misunderstandings between developers and customers gave rise to what can be called myths that circulate among the customers, and which are common among the developers [4, 5, 10, 11]. Thus, each side has formed its own misconceptions and myths. One typical myth of the customer says: “A general description of the development goals is enough to start product development. We’ll fill in the details later.” Another myth says: “Product requirements continuously change; however, the software is flexible, and we can easily adjust them on the fly.” Yes, on the one hand these are true. Changing a software product is often easier and much cheaper than rebuilding a bridge or another material product. Let us consider the resources required to rebuild a bridge. It is a challenge to blow up a bridge and reuse the material, such as concrete. However, the changes in a small component of a software product can affect the adjacent modules and even the neighboring systems. For example, a human resource management system may affect the financial resource management by means of payroll, bonus funding, etc. This effect can propagate further to the neighboring systems, and such induced errors can be very expensive to fix. In their turn, the developers have their own myths associated with the software product artifacts. One common myth says that a working code is the most important and in fact, the only deliverable of the project. Nothing else is required but the code itself, and the documentation is less important. Since the code well describes itself, and it is reliable, fast, safe, ergonomic etc., the project is complete as soon as the code works. Hence, it is always possible to transfer the code to the customer, and they will be able to work with it, as it is operational. The other myth says: “It is impossible to assess the quality of the product, that is, while it is in progress, we are uncertain of the time required to complete it and to deliver a quality product” [4]. On the one hand, this is true: a working product is a very important artifact. This is probably the main deliverable of the project; however, this is not a software product as it has no documentation and is not maintainable. The customer will make corrections and recommend certain improvements, particularly

1.4 Crisis: Myths and Reality

11

important in a crisis. Without documentation, it is difficult to adjust the code in terms of modification or maintenance. Nevertheless, it is possible to evaluate a future digital product, based on historical data of previous projects, their complexity, and other metrics. These include number of objects, functions, and lines of code to implement. Based on the number of components and their complexity, it is possible to evaluate the size and quality level of the software product. We have considered the myths that originate from developers and customers. However, the management may have their own myths related to development of software products. Let us consider a few examples of such misconceptions. One popular myth says that large corporations have already developed regulations for all occasions; therefore, developing special regulations for software products makes no sense. They understand how the other product types are built, and they produced all the standards required and follow these. Although there are many regulations (including local, federal, and international standards), the software development standards from local to international differ from their counterparts in business. Another misconception says: “We purchased the best hardware, the best computers, the most powerful servers, and the software product will easily change and adapt to the equipment requirements.” At first sight, this is true. Quality hardware will likely promote the robustness and performance of the software. However, the other critical ingredients of the software project include team communication, development discipline, product standards, and proper technologies, which are often expensive. One more misconception says: “If we violate the schedule, we will hire more programmers, or more testers, that is, more workers, and build this software product on time. No problem, this is just the same as building a house.” In part, this is true. Teamwork can accelerate the development of a software product; however, it takes time to adapt the newcomers to the team. Newcomers are not always junior developers; these are the people who have just joined the team with already established traditions, rules, and regulations. Therefore, time is required for their orientation, and this will inevitably affect the productivity and the project deliverables. Moreover, hiring a large number of programmers or testers is not always possible, and it does not guarantee even a linear increase in performance. Let us return to the concept of the crisis and the NATO conference, where the question was raised whether a software product was similar to a material product and software production similar to that of a bridge or a large-scale building. The answer was negative as there were a large number of points of difference. In fact, the lifecycles of these two kinds of products differ significantly in their cost distribution [4, 12, 13]. Let us consider the key differences between these two product categories, the software product and the material product. First of all, after software prototyping, the code does not have the exact parameters of a real and operational product. However, for a material product, such as a bridge, the developers still need to guarantee certain operational characteristics; that is, the prototype of the bridge must be sufficiently reliable to withstand some load. For a software application, the prototype may look

12

1 From Ad Hoc to Agility: A General Framework

and behave in a completely different way to the product. The prototype can be built in a different programming language than the full-scale product itself; they often use different platforms and are written in different languages. Only certain operating characteristics of the software prototype, which are actually tested (e.g., usability or an external interface), will mimic the product [14]. That is, a software prototype is like a paper tank, but it is very different from a real tank, as it does not actually shoot, drive, etc. The second point of difference is that even a serious fault in a delivered software product does not necessarily result in disaster. Conversely, a significant error in performance of a material product (such as a bridge) would lead to a disaster. In case of a software product, just restarting the computer and making minor updates often suffice, as this does not critically affect the lifecycle. Restarting a software application is much cheaper than reconstructing a building. Therefore, the lifecycles of software and material products differ significantly. Unfortunately, errors in software products accumulate over time. In physics, there is a concept of “metal fatigue.” This is similar to what happens to a software product when, as a result of intensive use (such as a large number of requests), a memory overflow or another cumulative effect occurs. In physics, this only happens with metals; therefore, the users of many material products do not observe such an effect. However, in software production, intensive use effects (e.g., a large number of concurrent users, complex or multiple queries to large-scale databases, etc.) will be noticeable. In general, the effect of such intensive use can have a critical impact on a software product; however, restarting is often a cheap, instant, and efficient remedy [15]. Software defects are often harder to detect; however, methods and software tools, based on formal models, often help to identify, analyze, and fix these errors in software products. Often, to detect a defect, it is sufficient to inspect the code rather than running it. The state-of-the-art methods and tools allow cheap defect detection and correction in the early development stages, avoiding costly reconstruction of the software product. Building error-free software requires other methods than those used in material production. With software production, the approach of increased strength is not acceptable [16]. That is, a bridge twice thicker will probably endure a double load. However, a software product, even after being tested twice, may still contain the same number of critical defects. Instead of using an approach of increased strength, developers should consistently check the scenarios that the users perform when operating the software product. Developers can also analyze the error reports to identify the most problematic or complex components of the software product. Another possible option is restoring an application after a failure to its previously operational state, so that it is utilizable again. One more notable point of difference between the lifecycle of software and material systems is that the software products are often complex, they quickly change and become obsolete. For instance, Microsoft Windows system is very complex in terms of the number of files, interacting modules, and code size; however, a change for the new generations (e.g., version 8 to version 10) takes a few years only.

1.4 Crisis: Myths and Reality

13

The lifecycles of the software and material products are quite different in their maintenance phase, that is, the operation at the customer’s site. The software product is created to satisfy the business requirements of client, and therefore, its transfer to the customer does not indicate the end of its lifecycle. Redesign and reimplementation of the software product are often incremental; that is, developers improve its functionality by modifying selected product components only. As a rule, the construction workers would have to completely rebuild the bridge, after destroying its foundations. With a software product, this is not always the case. Due to the rapid obsolescence or environment issues (such as the “Y2K” problem), developers have to replace software, because it is no longer operational, and replacing it is cheaper than maintaining it [17]. The above considerations suggest that the software product has a completely different lifecycle than the material product, and this is largely due to its maintenance phase. Let us draw a few preliminary conclusions. By the end of the 1960s, the software industry came to the point where the increasing complexity of the software products and the supporting hardware platforms did not allow efficient use of human resource potential, and these technological and human components required coordination. To satisfy these needs, software engineering appeared as a disciplined and systematic approach to software product development. This discipline included a set of rules and standards that allowed dealing with the software complexity crisis, which was caused by different points of view of developers and customers for the software product. This discipline dismantled a number of myths that originated from developers, clients, and their management; it improved project predictability and product quality. Software engineering systematically addresses project resources (i.e., time, cost, labor, etc.), product functions and features, and technical and managerial factors, and assists in conquering complexity and assuring quality [4]. Software development, especially in a crisis, is a multifactor optimization that requires prioritization in terms of project resources and product quality attributes. Software products behave similar to material ones in certain aspects; however, there are a few notable differences, including the maintenance stage [6, 18]. Therefore, building software products requires specific approaches, which are developed by software engineering.

1.5 Software Development Lifecycle Let us consider the software development process, in terms of the lifecycle stages. The lifecycle unites processes, roles, and artifacts. During their multifactor optimization, software developers determine the processes, i.e., the steps according to which the roles (such as testers, architects, coders, designers etc.) produce certain artifacts (such as code, documentation etc.). These artifacts, in turn, serve as the input parameters of the artifacts generated later in the lifecycle. Additionally, developers determine the methods (either agile or formal) required to build, test, and

14

1 From Ad Hoc to Agility: A General Framework

maintain the software product. These can be flexible methods, rigorous methods, or methodologies considered previously [16, 19, 20]. Let us outline the stages of the software development lifecycle, which are independent of the models and methodologies. The lifecycle starts with an analysis of requirements and development of specifications that determine the functions and quality attributes of the software product. The lifecycle stages typically include design, implementation, integration, testing, maintenance (or operation), and retirement (or decommissioning). In a crisis, developers determine the sub-processes and individual artifacts that they can reasonably sacrifice, without significant loss in product quality. The first stage of the software development lifecycle is requirement analysis. This is perhaps the only stage where, regardless of the model and methodology used, the developer and the customer work in close contact. They arrange a meeting (or a series of meetings), often held informally. These may include on-site interviews and video recording to capture the specific details of the mission-critical business processes to be automated by the software product. These videos help to understand the workplace arrangements, their relations to the key business processes and artifacts produced, and developing the use cases for the software product [15]. The developer and the customer often have different points of view on the software product to be developed, different priorities and expectations. From the customer’s point of view, the product should solve a specific business problem [21, 22]. From the point of view of the developer, the product development is often reduced to the use of existing knowledge and skills of the development team, to the use of known technologies, composition or adjustment of certain modules, and production of a few new functional modules. As a result, the developer and the customer arrive at a common vision of the aims and scope of the software product, the tasks to implement, and the functions to produce. In this case, the result is a document, which is either a Technical Specification Document or simply a checklist of requirements, which is approved by the developer and the customer. This document marks the transition to the next stage; therefore, the lifecycle in software production is document-driven. When developing agile requirements, this formal Technical Specification Document can be optimized to a simpler requirement checklist in order to save project resources. However, in this checklist it is still critically important to correctly identify and prioritize the key functions of the software product, in order to provide a value-add, and satisfy customer’s business needs [23]. The next stage of the lifecycle is the development of requirements. Naturally, this is based on the document with the specification of requirements, which was developed in the previous stage. Agile customers often participate in the project team and interact with the developer. However, it is the developer and their team who prepare a detailed list of requirements. This document should include a complete, unambiguous list of the functions required, provide a sufficient level of detail, and use standard notations (such as UML for diagrams) [13, 14].

1.5 Software Development Lifecycle

15

At this stage, developers also determine the lifecycle model. That is, they plan the development either in one pass or in cycles (the latter may include incremental product releases with gradual functionality growth). In addition, the developers estimate project time and cost, and then follow this assessment. Therewith, at this stage the developers restrict the project triangle in terms of time, cost, and functions of the software product to be developed. As such, they form the optimal area of comfort and evaluate the expected product add-ons in terms of time and cost. The next stage of development is detailed design of the software product. The output of this stage is the high-level code of the components of the software product. That is, the developers produce the product architecture, i.e. the definitions of the key software modules and their connections. The code is written at the next stage; here, developers also determine the technologies and the implementation languages. This is another step of agile optimization. Naturally, the optimization basis is the document delivered at the previous step, which contains the description of the architecture of the future software product. As a deliverable, developers produce a detailed view of the software product modules, including the algorithms and data structures, in order to initiate the process of implementation or coding [23]. The next stage in the software product lifecycle is implementation or coding. At this stage, the basis is the description of the modules (or classes, in the case of object-oriented development), which were delivered at the previous stage. The output is a set of individual modules or classes of the software product. This includes the code of software product modules (or classes) and their inline documentation, which describes their structure and behavior, including the algorithms, data structures, and connection points. For coding, the developers use the documentation of the previous lifecycle stages. By the end of this stage, each module is coded and tested individually by its author.

1.6 Conclusion In this chapter, the software development crisis was discussed from the human factor standpoint. The causes and effects of this crisis, and the advent of software engineering were considered. Also, the chapter discovered that a software engineer must combine technology and management skills. The crisis myths and the differences between software and material products were presented. These points of difference included cost distribution and product behavior.

16

1 From Ad Hoc to Agility: A General Framework

References 1. Zykov, S. V. (2018). Managing software crisis: A smart way to enterprise agility (153 p.). Cham: Springer International Publishing. 2. Naur, P., & Randell, B. (1968). Software Engineering: Report on a conference sponsored by the NATO Science Committee. Garmisch, Germany, October 7–11, 1968. 3. “Galloping Gertie” bridge: https://www.wsdot.wa.gov/tnbhistory/connections/connections3. htm. 4. Schach, S. R. (2010). Classical and object-oriented software engineering (8th ed., 688 p.). Science Engineering & Math. 5. Schmidt, T. S., & Paetzold, K. (2017). Challenges of agile development: A cause-and-effect analysis. In G. Fanmuy, E. Goubault, D. Krob, & F. Stephan (Eds.), Complex systems design & management. Cham: Springer. 6. Sambamurthy, V., Bharadwaj, A., & Grover, V. (2003). Shaping agility through digital options: Reconceptualizing the role of information technology in contemporary firms. MIS Quarterly, 27(2). 7. Lu, Y., & Ramamurthy, K. (2011). Understanding the link between information technology capability and organizational agility: An empirical examination. Management Information Systems Quarterly, 931–954. 8. de Albuquerque, P., & Christ, M. (2015). The tension between business process modeling and flexibility. The Journal of Strategic Information Systems, 24(3), 189–202. https://doi.org/10. 1016/j.jsis.2015.08.003. 9. Kumar, R. L., & Stylianou, A. C. (2014, March). A process model for analyzing and managing flexibility in information systems. European Journal of Information Systems, 23(2), 151–184. Available at SSRN: https://ssrn.com/abstract=2405401 or http://dx.doi.org/10.1057/ ejis.2012.53. 10. Roos, G. (2015). Servitization as innovation in manufacturing—A review of the literature. The handbook of service innovation (pp. 403–435). London: Springer. 11. Schmuck, R. (1997). Practical action research for change. Arlington Heights, IL: IRI/Skylight Training and Publishing. 12. Gromoff, A. (2010). A study of the subject-oriented approach for automation and process modeling of a service company. In S-BPM ONE, 2010 (pp. 192–206). 13. Overby, E., Bharadwaj, A., & Sambamurthy, V. (2006). Enterprise agility and the enabling role of information technology. European Journal of Information Systems, 15(2), 120–131. https:// doi.org/10.1057/palgrave.ejis.3000600. 14. Jensen, R. W. (2014). Improving software development productivity: Effective leadership and quantitative methods in software management. Upper Saddle River, NJ: Prentice Hall. 15. Turban, E., & Aronson, J. E. (2001). Decision support systems and intelligent systems (6th ed.). Upper Saddle River, NJ: Prentice Hall. (Copyright 2001). 16. Rigby, D., & Bilodeau, B. (2015). Management tools & trends 2015. London: Bain and Company. 17. The ESB in the Land of SOA. (2005, December 7). Information technology research: Enterprise strategies. Boston, MA: Aberdeen Group. 18. Mathiassen, L., & Pries-Heje, J. (2006). Business agility and diffusion of information technology. European Journal of Information Systems, 15, 116. https://doi.org/10.1057/palgrave.ejis. 3000610. 19. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276. 20. Rivera, J. (2015).Gartner identifies the top 10 strategic technology trends for 2015. Gartner. http://www.gartner.com/newsroom/id/2867917. 21. van Oosterhout, J., Heugens, P. P. M. A. R., & Kaptein, S. P. (2006). The internal morality of contracting: Advancing the contractualist endeavor in business ethics. Academy of Management Review, 31, 521–539.

References

17

22. Nagel, R. (1991).21st century manufacturing enterprise strategy: An industry-led view. Darby, PA: Diane Pub Co. 23. Lattanze, A. (2008). Architecting software intensive systems: A practitioners guide. Boston, MA: Auerbach Publications.

Chapter 2

Sociocultural Aspects of Agility

2.1 Introduction Culture can be seen in two different classifications—culture of an organization and culture of the person—which is all about the work process, for instance software development process. The impact of social/cultural differences is often ignored when software development projects are premeditated. Multicultural project teams are normal these days and have been known as an effective project management perspective. Other than resource, abilities, framework, tools, and innovation, social variables too play a key part in terms of setting up a great working relationship, whereas the presence of sociocultural differences among software teams found in different parts of the world is undisputed, what is more relevant is whether these sociocultural differences are an obstruction to fruitful software development and usage. There are many definitions of culture. Each of these definitions meaningfully increases the understanding of culture, and choosing an all-around acknowledged definition of culture remains a troublesome errand, but all definitions, in general, relate to identifying with the shared mindsets, feeling, shared meaning and characteristics, shared socially developed environments, common ways in which innovations are utilized, and commonly experienced events. Issues are related to various factors involved in the behavior of human beings that ultimately affect the end product. These factors can be characterized into three categories: individual, interpersonal, and organizational variables. Individual variables are connected with the characteristics of the individuals working in the team which may be represented by personality, whereas interpersonal factors are linked with individual variables present among people who are in the influence or influenced through techniques used in the development of the software, for instance participation, learning in the group and working as a team. The variables which are related to organizations are identified with organizational issues, for example, decision-making process. People are the most essential factor when driving advancement inside an organization. It is compulsory to urge your staff

© Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0_2

19

20

2 Sociocultural Aspects of Agility

to seize the opportunity of its imaginative potential if you desire an inventive culture is effectively infused into your organization.

2.2 Culture in Agility An agile culture is dependent on self-organizing and cross-functional teams. The colleagues in a team feel comfortable and welcomed to participate in the decisionmaking process in a modified and custom-made environment. Organizations that initially pursue conventional software development culture supplement a couple of difficulties in adopting agile culture. Some of these are overdemanding teams, documentation prerequisites, unforeseen difficultly in execution agile procedures, and so forth. Sometime, it is proposed that agile practices utilized on little, co-located groups should be rethought while implementing in large or distributed agile projects. Agile software development underlines the importance of groups and the elements of team interaction. Agile and conventional frameworks have clashing authoritative cultures and the execution styles, while agile practices support and propel social actions in software development lifecycle; there is yet a restricted understanding of how social powers come into existence in project teams during the development of the product. Agile strategies emphasize on “people”-centered approach to deliver software and in reality, and the “people”-centric approach of agile strategies is seen as a fundamental character in their accomplishment and developing a reputation among software development fertility. Software through motivated individuals is one of the principles of the agile manifesto [1]. Organizations working in agile culture have the following characteristics: open and differential environment, team bond and whole team participation, welcome change, and constant refinement. One of the values of agile manifesto focuses on individuals with an esteem explanation “individuals and interactions over process and tools” and a principle to “developing projects around motivated individuals” providing friendly conditions and positive environment to the team’s members help in getting the job done efficiently [4]. Actualizing agile strategy does not simply manage process and system; it additionally manages individuals and culture. People-related activities like culture, staffing, communication, and desires of the management have been given top priority and are important for effective software development. Core values for agile methodologies are human centric, which alludes to the dependence on individuals and the interaction between them, and technical expertise, which suggests the utilization of techniques and philosophy that deliver and maintain the quality of code and project management. Agile techniques either used in software development or in other related fields consider individuals as one of the foremost significant components for succeeding. In light of this, agile strategies can be used as a source of motivation, and adaption of practices and techniques can help in the innovating the development process. One of the key values of these strategies is to empowering the teams as compared to product-centric conventional strategies. Besides this, agile strategies propose other important values such as communication,

2.2 Culture in Agility

21

participation, responsibility, adaptability, adjustment, self-organizing, and capacity for making decisions. Culture has long been perceived as a vital aspect of describing behavioral issues among individuals. Additionally, demand to study the cultural aspects has been grown in recent years as business has become people centric chiefly when there’s a need for a business to interface with individuals, either as clients, representatives, providers, or stakeholders. The cultural difference among individuals can be seen in their behavior and values. These differences are perceived and appreciated, and it may be a starting point to translate people instinct within the social setting. Indeed, even though the curiosity of applying agility at this stage is high, it is not necessary that individuals would alter their conduct in teams including individuals from distinctive cultural societies. Understanding and acknowledging national culture with respect to preferences of agile software development methodologies can help in adjusting our way of working so that better results can be reaped. Adjustment among the people of different cultures requires attributes like compassion, which includes some traits from the learner such the providing solutions to the problem and taking the risk. The issue with cultural incompatibility increases when projects are distributed among multicultural society. It has turned out to be a regular practice to have software development teams in different locations. There are numerous reasons for this like: cost reduction, gathering talent pool, and investment prerequisites enforced by the overseas government. Growth in worldwide markets are seen as openings, expanded to get mastery, 24 × 7 service, quick reaction to requests, and reduction in travel costs. This tendency is anticipated to raise, and there is very less chance of it decreasing within the future. Globalization, multicultural and multi-location projects are seen as common practice nowadays. Sociocultural variables affect the success of software development. Differences in cultural values have an impact over people’s state of mind toward other societies. Most of the organizations these days are working in the globally distributed environment, and this has become a good practice to reap the benefits from round-the-clock development; however, this has led to serious issues related to culture and coordination. For many years, organizers gave a lot of attention to resolve problems that arise due to globalization. Expansion of organizations around the globe has given rise to the social–cultural elements affecting countries; for instance, the significance of soft skills in various societies like Asia, Australia, Europe, and America and the significance of social interactions and team structure can be viewed as basic for building teams across the globe. Organizations working with different culture and societies have turned out to be normal, and with the current worldwide market scenario, cross-cultural societies have become normal, this has led to broadening complexities face due to cultural impact, and it is turned out to be more unpredictable. By understanding the way of life of the team members, supervisors can comprehend the fundamental suppositions, convictions, and estimations of their team, so it helps in developing a better understanding of the team itself.

22

2 Sociocultural Aspects of Agility

2.3 Cultural Challenges in Implementing Agile Methods The challenge in actualizing agile, moreover, incorporates preparing the human intellect to move to the values that offer assistance to implement agile. There are two significant challenges: challenges with the procedure and challenges in handling cross-cultural issues. Culturally, assumptions are not common everywhere. Presumptions that hold true for one nation may not be appropriate for other, moreover not shared by every culture of the world. At the point when teams from various societies engaged among themselves, the multifaceted nature of work connections can result in additional difficulties. Another address that emerges is whether huge and differing countries such as Russia and India can be accepted to have one common culture? Moreover, even India does not share a common culture. The analysis must be required a reconsideration of hypotheses and agile practices that have been created in the USA for their appropriateness and generalizability to different nations and societies. The conceptual understanding of managers about such ideas may vary a lot across societies and culture [12]. Theories in general created in a particular social sitting; there is always a hope that these concepts can be transferred to other cultures flawlessly, yet this is not always that simple and easy. There are worries that agile techniques are characteristically developed keeping in mind the Western culture and may not absorb well into different cultures. In addition, foreign organizations tend to utilize their own administration control frameworks in the host nations without considering social sensitivities.

2.4 Cultural Challenges in the Global Market Global Software Development (GSD) is turning out to be a lifestyle; it brings other sets of problems related to distance and societies. Projects working with co-located teams have the advantage of working in close proximity and have developed multiple channels of communication. There is generally little miscommunication as groups share a typical local dialect just as national and corporate culture. Geographic distribution significantly influences the capacity to work together. Worldwide communication has turned into a reality for business endeavors; however, acknowledgment of these facilitation technologies is not guaranteed. The cultural contrasts that reinforce business practices must be taken as intercultural contrasts. Culture may be one of the reasons for project failure. Team culture is the absolute sum of the qualities or traditions that every partner has. A rising pattern of culturally varied project team makes it hard to share a typical “social standards.” Overseeing colleagues’ expectations on a cultural standard which are impressions of one’s national, corporate, and project backgrounds isn’t simple since the majority of their habits hidden as tacit knowledge in their brain. Identifying these social contrasts and their effect not just makes it possible to customize communication, association, and software development, yet in addition empowers managers to manage their teams. Some of the

2.4 Cultural Challenges in the Global Market

23

key social issues considered are cross-working team executives, the absence of top administration support, selection process, handling of meetings, exhibiting the team results successfully, projecting team output efficiently, aligning project plans with iterations, allotment of the project resources, and supporting team efforts in development of the project. Dualistic considering around “us” versus “them” is normal, and individuals convey opinions by disparaging the values of the other cultures or presenting their own culture as superior. It is conceivable that the reverse defense against own culture may occur. Instances of this conduct in work comprise a fact that presenting their nation as a predominant with the cultural values of work, and the outcome when contrasted with the individuals belongs to various countries working in a similar organization. Maintaining a strategic distance from social differences, giving information concerning likenesses, sharing of the requirements, targets and encouraging joint practices are the methods for building up the understanding to the next level [6]. At this stage, it is crucial for individuals to have patience, maintaining personal control, and have tolerance while working in-groups. In addition to failures of software projects, software teams working in global settings are facing more daunting problem of cross-cultural management. While communicating and handling teams in other nation, it is imperative to have a good understanding of the social and cultural way of life of the target country with the goal that it will develop workable and good connections. Understanding societies can help in knowing how to carry forward business in different cultural societies and can comprehend why individuals from these nations behave in a specific way. This learning of intercultural understanding is pivotal and can be the primary factor that decides the achievement or disappointment of a project. It is not strange these days having a huge software project with teams working in more than one location, moreover in a different continent. Many reasons have forced organizations to go global including: high cost, the need to tap worldwide pools to get exceptionally talented people, finding a proper blend of expertise with price is some of the prominent reasons. There is little hope that these reasons will mitigate in the near future, the reason being the globalization of markets and products, and pressure to distribute product quickly and globally [15]. Issues emerge when software engineers from various cultures work together and furthermore issue creates due to gaps between national culture and the theory imposed by the methodologies used for software development, here agile strategy. Worldwide financial integration is growing quickly, and the acceleration of this combination has been encouraged by technologies that permit the organization to expand its horizons internationally. In order to minimize the differences, the acknowledgment and acceptance of superficial cultural distinctions are used as each individual around the world has a profound belief, which is deeply instilled in them. If we think in context to work, working together, national behavior and differences are acknowledged in a constructive manner but differences in the value system are not considered. Advancement for next phases requires general information of own and different societies, receptiveness, listening aptitudes, and precise and non-judgmental view of other cultures. One challenge to actualizing agile practices universally is accommodating social differences. Since the agile methodology began in the USA, American social standards

24

2 Sociocultural Aspects of Agility

may assume an outsized job in how agile techniques are endorsed and completed— and that could make issues when groups in different nations embrace agile approach. For instance, straightforwardly communicating ideas and assessments to power figures, freely examining success and failure, and allotting credit or fault are frequently acknowledged practices in agile teams, yet such open interaction may not be reliable with social standards in all parts of the world [2]. Recognizing the special social characteristics of employees participating in agile projects outside the USA may be significant to the project a victory. When agile practices clash with native culture of a nation, it is vital for organizations to identify the conflict and creates a workable solution sensitive to the societal standards without obstructing agile practices. The agile strategy may be a culture-based approach, and to actualize agile, there is an ought to examine the agile procedures based on a social point of view. The agile concepts concentrate on arranging, iterative and early release of working products using collaborative and communicative techniques, such as pair programming, refactoring, and having business work on location with the team individuals. Cultural factor needs attention while implementing agile practices. The value of communication among individuals is explicit in agile software development and further mentioned in the values and principle of agile manifesto “individuals and interactions over processes and tools,” “customer collaboration over contract negotiation,” and “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” These agile practices are affected by the sociocultural context. For instance, a strategy “daily builds of a complete system” has social factors, for example, team cooperation, contribution, swift decision making, time management, and “pair programming.” This strategy requires engineers to have faith in each other, lucidity, commitment, self-organizing, cooperating, time bound, and being proactive. Another interesting strategy “knowledge sharing” is empowered by agile techniques. A procedure will be extremely hard to be actualized if functioning very well in a group and clearness is not kept up among colleagues. A captivating match was found between agile strategies and social influence. This comprehension presumed that essential social variables might be expected to relate systems to help utilize an agile strategy.

2.5 Cultural Dimension A grater perception toward the culture has an “onion” analogy shown in Fig. 2.1. This metaphor is well suited because it represents the level of society. The symbol is the most prominent and outermost layer. These may include gestures, terms, pictures, and prestige symbol used by a particular cultural set. Therefore, symbols are prominent layers of society [10]. Heroes are the individuals having special traits, which are highly adorable in society and act as an idol for conduct. The activities carried out based on the rituals have no link between the rational and the practical purpose for getting the desired outcome while these are used for the group cohesion.

2.5 Cultural Dimension

25

Fig. 2.1 “Onion” analogy [10]

The basic example of rituals is making good wishes and giving respect to each other that have different ways in a different culture. There are some occasions where three different aspects are added such as symbols, rituals, and heroes beneath exercises since it is common for the outsider. However, the social meaning of practices is undetectable for outsiders and is reliant only in a way the insiders explain these exercises. Values are the heart of culture. Values are convictions, which allude to desirable objectives, and transcend above particular activities and circumstances. The perfect example is the agile values by affirming “individual and interactions over process and tools.” When culture is inspected from the nationality point of view, sources of differences between nations are individuality, values, and institutions [11]. The individuality here implies language and religion. Institutions form the principles, associations, and rules associated with them. These facts are apparent to others. In dissimilarity, the values are being invisible and implicit, while the impact of these is on the visible institution. Agile strategies or exercises are apparent to the outsiders, and are influenced using the translation of qualities in the agile declaration. The values linked with the individuals and their corresponding nations again affect the explanation. An agile methodology can be viewed as its very own culture. Knowing these agile practices in global software development, we should comprehend the fundamental national and agile values. There can be other dimensions called diversity of cultural: conservatism, the chain of command, authority, mental independence, libertarian commitment and concordance.

26

2 Sociocultural Aspects of Agility

2.6 Power Distribution Dimension groups together various phenomenons in public that is experimentally found to happen in conjunction. Organizations where teams are working with egalitarian power distribution have more decentralized control, fewer supervisory, and fewer salary compared to teams working in less power distributed organizations. Centralized power circulated nation’s managers follow their bosses and formal strategies, whereas in egalitarian power distributed nations, managers depend on themselves and on subordinates’ experience. In centralized control societies, subordinates are being commanded to do the task. Hence, the perfect manager in egalitarian power distributed nations is a resourceful egalitarian with a practical connection to assistants. This can be very distinctive from the perfect boss in organizations having centralized control. Individuals with the high occupation and training level empower decentralized power irrespective of nationality, compared with individuals having a lower designation and education level. The value of high-status workers with respect to inequality appears to depend strongly on nationality [10].

2.7 Individualism Individualism is a feel that a person gets reelecting to a personal sense of accomplishment from work, having a work that spares adequate time for individual or for the family members, flexibility to use their own method for work. For the inverse, collectivist culture leans toward learning new skills; great working conditions, and the likelihood to completely utilize own abilities and capacities at work. In individualistic societies, employees usually rely upon to act on the way of their personal interest, and there should be a possibility in work that individual and employer correspond with each other, usually linked with the purpose and the rewards that comes from it. To differentiate the efficiency of workers, individualistic nations perform in a better way when having personal goals and recognition on priority compared to workers in collective cultures. Nations with high individualism prefer a frequent and straightforward communication where the ideas mean the asset for the organization. Indeed, in these nations, presenting an argument is acceptable which show the way to a higher truth, alternately to exceptionally collectivistic societies where conflict is evaded. Personal suppositions do not exist in nations with high collectivism, but are predetermined in groups [10]. It is expressed so that team members hesitate to express in a big group. Nations with egalitarian power distribution are collective in nature since within these societies’ individuals are reliant on in-groups. On the opposite, the societies having individuals who are less reliant on in-groups—they are too less reliant on others in the societies (Fig. 2.2).

2.8 Masculinity

27

Fig. 2.2 Cultural dimensions [11]

2.8 Masculinity Masculine characterizes gender roles: Men are to exhibit masculine characteristics and behaviors as self-confident, tough, intense, and concentrated on objective achievement, while women being more humble, delicate, and concerned with the quality of life. To decreased perplexity, “Individualism-collectivism” is regarding freedom or reliance of in-groups, whereas “masculine–feminine” concentrates on the relationship with oneself or others. In the workplace chances of lucrative salary, obtaining a reward when work is done, producing possible outcomes in progression and the work, which needs to face challenges, remains vital objectives in male dominated societies perhaps the reason why masculine societies lean toward bigger organizations than feminine societies. In the expansion, the feminine culture appreciates a good association with their seniors, group participation, and job security. In masculine cultures, competition is significant and sometimes aggressive behavior can be shown openly. Issues that arise may be solved with the strongest contestant to win in masculine culture, whereas in the case of feminine culture, clashes are settled using the negotiation and compromise. For a culture which is male predominant is frequently related to the preliminary arrangement, and it is usually in concern with work, whereas in feminine culture, its focus is on consideration and look concern for people. This also happened in the job betterment, which is apparent for more opportunities for helping each other and links in their friend circle in feminine culture but including additional and demanding tasks in masculine culture [10].

2.9 Assumed Relationship Between Agile and National Cultures The primary query arises in mind is: What is the link between the values in context with agile and the cultures of different nationalities? How agile ought to be adjusted

28

2 Sociocultural Aspects of Agility

for distinctive national societies? Subsequent suggestions are composed from the point of view where agile principles have a tendency for disagreement. It is the main reason to assist individuals to get it what is required to take into consideration if they need to utilize agile with socially differing groups.

2.10 Egalitarian Power Distribution, Collectivism, and Agile Self-organization Egalitarian control teams/organizations are participating units of individuals which increase gradually and are more productive in contrast to those who are less participating as team units. In addition to this, egalitarian power nation representatives expect counseled on work and decision taken related to work, whereas in decentralized controlled groups, the employee’s managers command the employee related to work and decisions. Agile values encourage collaboration, which closes to participative administration, the primary sign of the relationship between agile values, and egalitarian control distribution is identified. It is necessary to have a change into agile culture from conventional command and control model, and software development team should be more adaptable, self-dependent, and empowered to do choice making. There is a possibility that this may probably give rise to clash in cultures which may reinforce differences to superiors. Therefore, it takes time for the people those take initiatives to adjust themselves in this kind of culture. There is a positive connection between power distribution and agile values. The dimension of power distribution has an association with having faith in individuals more than procedures, straightforwardness, authority, fast choice making, empowering individuals, proactiveness, administration support, collective possession, blame sharing, arrangement, and clash resolution [3]. Generally, the client is higher in the chain than the supplier. Although agile has proposed principle on collaboration. It gives rise to be on the same level for the parties. The relationship at the same level is also seen in agile guideline expressing “Business people and developers must work together daily throughout the project.” It leads to presume that qualities related to agile appear to support egalitarian power distribution. This is generally a direct result of self-organizing, empowerment, and collaborationoriented administration style featured in agile. Members of self-organizing teams may change their roles, managers not guiding about the work feel chaotic and not inspiring. Additionally, it is the disadvantage of the collectivistic in which the individual in the team is restricted in giving their opinion on any new task or method for working. However, the feeling of self-organization can be forced in these cultures by facilitative and guiding kind of administration. This implies that practically authoritative control ought to be avoided by managers and team members is higher in progression as it restricts colleagues from egalitarian power distribution and collective societies to express their thoughts. It is possible to take the opinions from everyone in the meetings by having direct communication with them. It is likewise

2.10 Egalitarian Power Distribution, Collectivism, and Agile …

29

critical to indicate individuals that their recommendations are heard and followed up on as it urges them to keep proposing their thoughts. It is a good beginning, if we let the individual decide how they can achieve the task proficiently. It is a good idea to give the response to the queries of the employees with open questions, and it will help them to find the answers to the questions by their own thinking and taking responsibility for that. As the dimension of self-organization increments slowly, more opportunity and freedom ought to be assigned to colleagues by giving them a chance to pick responsibilities within the project goals. Eventually, self-organizing groups effectively take part in project planning and take self-initiative for any issue that arises in due course. There is another way for individuals to learn, let they fail in a protected way. The precise definition of fail in a protected means is exceptionally difficult, but in general, those failure ought to not cause any harm to the organization whether physically, monetary, and emotionally. Feedback channels and open atmosphere are important if a problem is surfaced, especially when there are both the members from the masculine and collectivists societies. The reason behind in these societies, falling flat conveys disgrace, and along these lines, issues may be covered up. However, falling flat is not sufficient. It is not a good practice to make mistakes repeatedly instead; they must learn a lesson from their mistakes. Reviews are valuable for encouraging the learning procedure. Again, in this procedure, giving straightforward replies, blaming, command, and control ought to be restricted because it hinders self-organization. Societies with egalitarian control distribution favor the concept of proper distribution of roles and the corresponding responsibilities. Because of this business representatives and engineers are working together, which can cause postponements and mistaken assumptions in imparting client needs to and within the development team. There is a technique which can be used to diminish the risk by encouraging the managers not to use any kind of role description and allow team members to actively take part in new tasks and duties [14]. Finally, it is a great idea to be aware of and consider in planning that egalitarian power distribution culture anticipates hierarchy, which frequently implies more individuals and cost rather than how the team structure needs to be.

2.11 Individuals and Interactions One of the principles of agile methodology is expressing “Individuals and interactions over processes and tools.” Although the communications (a feminine value) are referenced and processes are downplayed, this evidently encourages individualistic qualities. There is again a reference to people in the agile principle proposing, “Build projects around motivated individuals” [5]. In light of this, it appears that agile inclines toward individualistic qualities. Besides individualistic nations, the team would perform better if the responsibility of everyone is underlined. Interestingly, teams in collectivist nations perform better if there is no rat race in achieving objectives of each individual and furthermore are not being highlighted. It is not mentioned directly in agile values or principles that whether the goal is set for an

30

2 Sociocultural Aspects of Agility

individual or for a team. Agile principles give a hint beginning with “our highest priority” that appears to allude to group objectives and, in these manner, collectivistic qualities. For instance, “pair programming” incorporates a solid relationship with what style of communication is seen in the culture. “Individualism/collectivism” and “power distribution” are vital for pair programming to work well, in expansion to how communication is done. There are more chances of the accessibility of “pair programming” if the nature of the culture is working collaboratively and helping each other. With respect to “power distribution” if the nature of the culture is represented as leveled means that no hierarchy is followed, at that point the two individuals will have the capacity to work in the less controlled way and will be open to share and work with fewer personality conflicts. Another great illustration is “frequent delivery” for this technique, time is critical, and it should manage well. Prioritization and commitment to release are elementary to this method. In expansion to being able to provide on time, another significant viewpoint is to be able to work well with each other. Subsequently to accomplish “frequent delivery,” the colleagues should have the capacity to work in a collective manner and help one another. It will likewise be normal that the communication style is good so the delivery can be managed well and can be openly talked. In the individual culture, an opportunity to work according to own wish is acknowledging. This methodology is upheld by agile principle recommending “The best architectures, requirements, and designs emerge from selforganizing teams” and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” One can assert that these arguments may refer to collectivist qualities, as a team is also a kind of group of its own. The individualistic nations prefer one-to-one message style. The agile manifesto supports face-to-face correspondence being a standard way of conveying views to others in spite of the fact that the web and email hold solid appeal for individualistic societies. As an inference, it is quite hard to recognize at this level if agile values support individualistic or collective values than in the event of power distribution where the association is evident. The values and principles of agile discuss concerning people, and morals linked with the people yet are regularly depicted in context with the team, which focus on collectivism.

2.12 Goal Setting and Sustainability It is apparent in agile that the value of “working software over comprehensive documentation” is a process having recurring in principles of agile, “working software is the essential measure of advancement.” Moreover, agile principle characterizes that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software “ and “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” In this way, the main aspects of these principles are achieving goals and accomplishment. In feminine culture, they are adapting to changes in objective and the targets as compared to masculine culture. Change is frequently referenced in the

2.12 Goal Setting and Sustainability

31

agile with value expressing “Responding the change, over following the plan” and “Welcome changing requirements, even late in development.” For customer’s competitive benefit, agile procedures exploit change for the same. However, the latter statement can be linked, and it may take advantage of the competition. In fact, this statement can be additionally observed as an endeavor that concerning masculine culture with the adjustment to the regular amendments that come into the existence in the development of software. However, motivation of individuals/team, client’s competitive advantage may not be the reason that makes member of masculine society to tick. Instead, people/organizations oriented toward feminine cultures need to understand that their work help other people in more meaningful way. The risk may arise in the development of a global team whenever there is a competition in the local team members [3]. In the masculine culture, there is an open contest among team members, which is a motivational factor that they are convinced to give their best. On the other hand, individuals from female societies infer this conduct as attempting to progress on their profession at the price of others. Subsequently, social skills and communication are required among colleagues to keep the risk to escalate as dysfunctional conduct among colleagues. Feminine societies encourage group interactions. Face-to-face communication and visiting project sites at the starting of the project are vital because it enhances the efficiency and builds the confidence of the team. At the beginning of the project, team members feel better by talking about individual and national qualities, and these may affect the working of the team as it increases common perception, transparency, and trust. This sort of exchange ought to be organized virtually if the team does not get an opportunity of meeting each other personally [13]. After commencement, the links between them are fortified by immediate and regular communication between colleagues utilizing as much digital audio-visual communication as could be expected, being nearest to communicate personally. Digital means of communication such as voice messages decreases waiting time in communication that may arise and removes any chance of misunderstanding normal for the documentation in handwritten form and electronic mail. Casual talk in meetings such as virtual meeting and organizing informal virtual team get-together helps in creating a link between individuals of the team. It is particularly vital for collectivist societies, where knowing it is vital to acknowledge each other prior to any meeting. What is more important when making choices in the team, individuals in feminine society should be tightly involved in process? However, taking a particular decision takes much more time in these societies. Opportunity should be there for group discussion in these societies yet having strict due dates for making decisions and concurring on people who have an obligation regarding making speed up this process. “The contact negotiation is based on the collaboration of the clients” and “Businesspeople and developers must work together daily throughout the project,” refer to matter for the agreement about the competition, which could be a feminine value. In addition, “Individuals and interactions” stresses the significance of interactions once more being female esteem. In female-oriented cultures, each individual works for a living and they give preference to recreation than work. Like individualism, values and the principles of agile methodologies support masculine culture in terms of achievements and the clear objectives as well as in feminine culture interims

32

2 Sociocultural Aspects of Agility

adaptation to changes, collaborative work and from the prospective of sustainability [8]. Therefore, it is not possible to make inferences on the relationship between the agile values and the individualism.

2.13 Lessons Learned from Global Agile Implementations As we talked about the cultural difficulties faced in agile projects and how they managed them, we discovered three areas where agile practices connected with social contents in a typical way and create challenges: keeping up adaptability and speed, building a successful agile team, and generating effectual communication channels. In many cases, teams can resolve those types of challenges with flexible solutions that preserve key agile practices but accommodate a culture’s distinct norms.

2.14 Accessible Communication Channels The open and progressing correspondence is an important part of agile practice. However, interpersonal communication is regularly influenced deeply by social contents that can restrain open verbal exchange and fundamental interaction in agile teams. We propose overcoming this impediment by building a domain in which individuals can take part in open communication without conflicting with cultural norms that may discourage it. There are already available communication channels in agile practices; pair programming and stand-up meeting are few examples of it. That can be used by globally distributed teams for collaboration and communication with the help of technology available these days [7].

2.15 Context for Openness Open correspondence is a test for agile teams in the majority of the nations. For instance, a few nations stress the significance of keeping up social standing, made workers be hesitant to share data they believe may harm their own goodwill or the goodwill of others, which both stress the importance of forging strong social relationships, can have both positive and negative repercussions in agile projects. On one hand, the group cohesiveness that outcomes from such connections can be valuable, but it can likewise lead people to take part in practices that support the team over the project. These social scripts repress the open correspondence that agile techniques depend on to keep the development procedure transparent and guarantee that project data is accessible to all individuals from the team (Fig. 2.3).

2.16 New Communication Channels

33

Fig. 2.3 Agile@Global

2.16 New Communication Channels In a few nations, DOM and the institution of a social hierarchy, systematically, ingrain individuals with a feeling of respect of authority, and therefore, interpersonal communication is extremely formal and less open. This less tranquil style of communication can ruin the free flow of ideas/thoughts and make it harder for workers lower in the hierarchical to build up an understanding of client needs. In this condition, workers would stay quiet when they have disagreement with their bosses on some issues, since they trusted they were not in a situation to decide. In India, communication happened principally between individuals who were at a similar designation of the hierarchical order. In an agile team, the lack of open correspondence with the client may prompt erroneous suppositions about client needs, and along these lines, huge rework might be required when the final product is not what the client anticipated [9]. To address that issue, organizations made wikis to help community-oriented basic decision making. Through the wiki, all colleagues could share their considerations transparently yet additionally secretly, with the goal that they did not seem disrespectful. Such arrangements can enable workers to feel they are preserving their regard for authority, and at the same time give a channel to straightforwardly sharing concerns.

34

2 Sociocultural Aspects of Agility

2.17 Conclusion We could see signs that agile favors egalitarian power distribution due to selforganizing, empowerment, and delegation of control. Association with individualism and collectivism stays indistinct due to agile focuses for both the aspects such as individualism (the specification about the individual, the unique method to work which is related to each individual, type of direct correspondence) and community (collaboration). Similarly, association with the masculinity dimension is not clear because the main objective is directed in the direction of masculinity qualities; however, there are qualities which are directly linked to feminine culture are adaptation toward varying targets and cooperation. From a social angle, the traditional approach tends to form a team having similar specialization, who work together to urge superior at their expertise, but they often end doing in isolation when they are working on the part of the problem. The main idea of scrum is to concentrate on the cross-functional team, which comprised of experts from different fields to provide a value product. Cross-functional teams shift the concentration from “my” to “our.” The whole focus of the team changes to a more extensive prospective; this prompts to a more rewarding outcome. This move in the center of attention from “me” to “team” additionally requests that individuals work on their social associations. Agile in general underlines this methodology, prompting higher commitment, team satisfaction, and better business results. Introducing practices that bring agility to a team or organization can be done with cultural sensitivity. Effective agile organizations adjust their practices to suit project and organization characteristics. Adapting your agile practices to be considerate of cultural scripts will demonstrate to global teams that agile methods are not a onesize-fits-all approach and that localized nuances do matter. As one executes agile practices pioneered in one culture in nations that have distinctive social standards, it is important to consider how the requisite agile behaviors may mesh with the cultural norms of the employees being asked to behave that way. While there may arise some conflicts between agile exercises and cultural content, a solution has to be devised that may differ depending upon local context and cultural rules at play, a broad and more workable action which creates the balance between agile practices and behaviors that are present in the local can be implemented. Striking such a balance is important not only because it helps ensure that agile teams will be able to accomplish their goals, but also because it can create interesting opportunities to leverage the unique perspectives and solutions different cultures may offer. Adopting agile values to diverse national societies do not accept as a straightforward assignment taking in consideration time as well as the costs. In 2006 Fowler, who states, “Getting teams to be more proactive is an uphill battle and one that inevitably takes a lot of time,” has additionally noted this. Subsequently, there are long-term benefits in going agile around the globe; it does not provide any benefit in the short span of time. At the point when this choice is made, enough persistence ought to be practicing what should be the outcome while accepting agile. Quickly, if your deceivability and prospects are just a couple of months ahead for a small team; do

2.17 Conclusion

35

not go for global and agile. Furthermore, when the choice is made that you want to change your working environment from co-located teams to the global environment of software development, it should take shape in of sequential steps, not explosively, as it assists in balancing social imbalance and reduce risks.

References 1. Agile Manifesto. Available http://agilemanifesto.org/. Accessed 26 2019. 2. Ardichvili, A., Jondle, D., Kowske, B., Cornachione, E., Li, J., & Thakadipuram, T. (2012). Ethical cultures in large business organizations in Brazil, Russia, India, and China. Journal of Business Ethics, 105(4), 415–428. 3. Chagas, A., Santos, M., Santana, C., & Vasconcelos, A. (2015). The impact of human factors on agile projects. In 2015 Agile Conference (AGILE) (pp. 87–91). IEEE. 4. Cockburn, A. (2002). Agile software development. Boston, MA: Wesley. 5. Cockburn, A., & Highsmith, J. (2001). Agile software development: The people factor. Computer, 34(11), 131–133. 6. Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9–10), 833–859. 7. Fowler, M. (2006). Using an agile software process with offshore development. Available http:// martinfowler.com/articles/agileOffshore. Accessed 12.09.2018. 8. Gandomani, T. J., Zulzalil, H., Ghani, A. A., Sultan, A. B., & Sharif, K. Y. (2014). How human aspects impress Agile software development transition and adoption. International Journal of Software Engineering and its Applications, 8(1), 129–148. 9. Green, P. (2015). Scrum as an agent of culture change part 2. Retrieved from https://agileforall. com/scrum-as-an-agent-of-culture-change-2/, dated 22.11.2018. 10. Hofstede, G. (2011). Dimensionalizing cultures: The Hofstede model in context. Online Readings in Psychology and Culture, 2(1), 8. 11. Hoftstede, G. (1991). Cultures and organizations, software of the mind. New York, NY: McGraw-Hill. 12. Law, A., & Charron, R. (2005). Effects of agile practices on social factors. ACM SIGSOFT Software Engineering Notes, 30(4), 1–5. 13. Noor, M. A., Rabiser, R., & Grünbacher, P. (2008). Agile product line planning: A collaborative approach and a case study. Journal of Systems and Software, 81(6), 868–882. 14. Pirzadeh, L. (2010). Human factors in software development: A systematic literature review. Master of Science Thesis in Computer Science and Engineering. Department of Computer Science and Engineering. Division of Networks and Distributed Systems. Chalmers University of Technology. Göteborg, Sweden. 15. Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing agile. Harvard Business Review, 94(5), 40–50.

Chapter 3

Agile Knowledge Management

3.1 Introduction Organization’s most considerate and effective resource is its knowledge; with the help of this knowledge, any enterprise can be more productive to deliver its services and the products which are more competitive. The main attention and consideration of the organizations are toward the power of knowledge. Nowadays, most of the organizations are conscious about success and are frequently determined by one’s capacity to create, spread, and encapsulate information in services and products. Ought to these realizations, organizational thinking spectrum is broadened in analyzing the different ways in which information can be created, identified, codified spread, and retained. To achieve this necessity, the field of knowledge management has risen in multifold. Various knowledge systems portray knowledge-related activities. The organizational components such as people, strategies, processes, and products must implant organizational knowledge within them. An organization that wants to improve its performance needs to work on their workforce so that its knowledge worker improves their work every day in a form that cumulates into a significant improvement. One of the keystones of knowledge management is to improve the productivity and competitiveness of the organization by efficiently dissemination knowledge among the workers that is sometime very tedious and difficult to implement. Business intelligence (BI) is regularly mistaken for knowledge management. Gartner consultancy has clearly specified that BI acts as a set of all technologies used to collect and investigate data so that it helps the organization in the decision-making process. The particulars of BI have been often defined as the detection, clarification of hidden, embedded, and decision-relevant context in big data. Knowledge management (KM) encourages organizations to generate and understand knowledge process form its own experience. This implies that BI acts as an instrument that assists the organization in extracting and giving more knowledge to improve its position in the market with the help of information technology. There is a range of components

© Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0_3

37

38

3 Agile Knowledge Management

that KM includes such as elicitation, bundling and management, and reusing the knowledge in diverse forms, and in specifically artifacts of the software development process such as requirement, plan, code, and models. Various development trends are responsible for the rising enthusiasm for knowledge management such as globalization with the ever-expanding leadership competition; virtualization/digitization empowered by advances in innovation in information and communication technologies (ICT); and the inclination of organizations toward knowledge-based economy [1]. The central point of the knowledge management is dispersal of knowledge and does not support the development of knowledge monopoly. Its main objective is on disseminating knowledge among the representatives rather than having some master people who know about the little explicit area. Three key features must be considered for successful implementation of KM in a project irrespective of the field in which it is implemented. The first is the embedment of the necessary mechanisms that assure the total involvement of the employees in the KM program: this implies setting up an organizational culture dependent on sharing and teaming up. The second viewpoint refers to encourage the exchange of the knowledge among the representatives this knowledge may be tacit and explicit, disregarding time and geographical differences, utilization of corporate memory, as a method for clarification and swapping of important knowledge is the last viewpoint which helps in implementing the initial two viewpoints. Therefore, it is believed that knowledge is a pivotal resource for progress and survival in an increasingly competitive and open market [2]. This type of awareness in the organization prompted the exponential development of KM research (Fig. 3.1).

Fig. 3.1 Knowledge transformation process

3.1 Introduction

39

Knowledge is mostly distinguished as tacit and explicit. Tacit knowledge because it resides in the human mind being a personal asset and is difficult to classify, communicate and put it in any kind of formal procedure. Knowledge is acquired by any individual’s experiences and accommodates the factors based on someone’s perception, views, and the working methodology of the individual. It is important to convert tacit knowledge to explicit knowledge so that the organization can get benefits from the knowledge that is confined in the human mind, but it is very difficult to codify the tacit knowledge. It is very hard to pass on knowledge to the workforce of organizations as it is, whereas it is quite easy to share explicit knowledge because the meaning of it can be conveyed in a formal language. It is possible to comprehend it using grammatical explanations, numerical articulations, details, manuals, etc. Four kinds of transitions may happen between tacit and explicit knowledge [3]. • Tacit-to-explicit (externalization): It is a method for converting conceptual thoughts of your mind into explicit knowledge. • Tacit-to-tacit (socialization): It is a way toward sharing beliefs and experiences and in this manner making new tactic knowledge, for example, shared cognitive contents and skills. • Explicit-to-explicit (combination): The way toward schematizing concepts into explicit concepts. • Explicit-to-tacit (internalization): The procedure that is firmly identified with “learning by doing” in which an individual tends to integrate others’ explicit knowledge and thus changes it into own tactic learning without the need to remember the experience. The exchange of tacit knowledge to explicit knowledge is the fundamental challenge faced by KM; moreover, it shares the knowledge pertaining to explicit conveyed from people to groups working in an organization and also seems like a problematic task. Each software developer must possess knowledge relating to the development of the product, the process used in the development of the software, management of the project, and innovations. It is necessary for the development of the software to use the explicit as well as tacit knowledge and grow with the help of technology and positive organizational culture. Knowledge can enhance software development by perceiving the structure that is used and the knowledge content just as the right knowledge, and doing experiments for the planning.

3.2 Epistemological Perspectives on KM The work by Stewart on intellectual capital [4, 5], Nonka on knowledge creation [6, 7] and Davenport on knowledge management model [8] give wings to the concept of the importance of managing knowledge in 90s. To begin with, getting to be associated with the data frameworks like corporate portals, report administration frameworks, etc., and building of repositories of codified knowledge are the solid innovative implication of knowledge management. There are four noteworthy points of view on

40

3 Agile Knowledge Management

Table 3.1 Knowledge administration Information-oriented KM

Human-oriented KM

Computing-oriented KM

Strategy-oriented KM

1. Knowledge as relevant content

KM as information management, usually a set of knowledge process (e.g., identify, organize, and use)

2. Knowledge as replicable experience

KM is codification of experience and expertise of individuals and teams

1. Knowledge as social practice

KM is cultivation of shared contexts and collective engagement in action and practice

2. Knowledge as sense making

KM is an inquiry, negotiation of meaning, and organizational change

1. Knowledge as intelligent computing

KM as computation of data and information

2. Knowledge as system thinking

KM as modeling system for decision making

1. Knowledge as organizational capabilities

KM as knowledge creation, transfer, and protection for building sustainable competitive advantage

2. Knowledge as the foundation of the organization

KM as knowledge-based managerial practice

the administration of knowledge: information-, human-, computing- and strategyoriented KM (c.f. Table 3.1). A structure for classification work in KM has proposed by Earl [9]. He characterizes the different schools of the management of knowledge. He classified schools as “technocratic,” “economic,” and “behavioral.” There is a further classification of “technocratic” school into three schools: the first school is known as “systems” school, centers around innovation for knowledge sharing. The second one is the “cartographic” school, centers around tools to encourage individuals to find individuals with the correct knowledge, lastly, the “engineering” school, which centers on procedures and knowledge streams in organizations. The main impact of the economic school is about how knowledge resources identify with pay in the organization. The behavioral school comprises three sub-schools: The “organizational” school centers around systems for sharing knowledge, the “spatial” school centers around how office-space can be intended to advance knowledge sharing, and lastly, the strategic school centers around how knowledge can be viewed as the spirit of an organization’s methodology (Table 3.2). Four zones are characterized by a system developed by Davenport and Prusak [8]: Generation of knowledge, coordination of knowledge, codification of knowledge, and

Technology

Knowledge bases

Domain

Focus

Aim

Unit

Systems

Table 3.2 Earl’s school

Enterprise

Knowledge directories Activity

Knowledge flows Know-how

Knowledge assets

Income

Commercial

Engineering Processes

Cartographic

Maps

Economic

Technocratic

Communities

Knowledge pooling

Networks

Organizational

Behavioral

Place

Knowledge exchange

Space

Spatial

Knowledge

Mindset

Strategic

3.2 Epistemological Perspectives on KM 41

42

3 Agile Knowledge Management

exchange of knowledge. They provide extensive definitions and examples explaining different constructs and suggest these are the basic processes of KM.

3.3 Knowledge Management in Practice Creation, dissemination, and utilization of knowledge are the key process of knowledge management. Individuals are assisted with the knowledge to perform their job efficiently, and that knowledge comes from a range of practices used in an organization to collect and share knowledge. Learning should be identifiable, and for that purpose, it must be qualified and codified so that it can be easily retrieved and reused. To make it simpler for employees to share their learnings and, thus, to gain from one another, knowledge management can incorporate procedures to cultivate a culture of data sharing. For improving learning among the employee, the organization can implement knowledge repository. It is a database for storing information-related items, administrations, clients, business procedures, procedures, products and services [1]. The repository aids employee to locate specific knowledge about the product that helps them in learning and adapting new knowledge and skill. Knowledge worker’s minds accumulate a large portion of organizational knowledge. This valuable knowledge helps organizations in many ways and supports decision making, reusability, learning, and so forth. KM requires cooperation among individuals for implementing KM procedures more efficiently. One of the ways to implement KM successfully within the organization is by employing communities of practice (CoPs). Groups of individuals those are casually bound to each other having shared the set of problems are known as communities of practice. The individuals within the groups share their knowledge resources and learning (both explicit and tacit) among themselves so that all of them can acquire mutual benefits. Groups like these have a special formation in each organization and are typically decentralized, loosely structured, and purely based on personal relationships [10]. These CoPs helps organizations to implement the culture of KM. Each individual in this group constantly discovers and shares significant knowledge with each other. Therefore, the knowledge captured is not focused on any business objective; nor is it classified or approved or is it put away in an organization that empowers simple access to the information.

3.4 Challenges in Agile Software Development As compared to the documentcentric, conventional software approaches, agile declaration (manifesto) advocates “just enough” documentation. Agile methodologies prefer informal face-to-face communication to heavy documentation. These methodologies advocate minimum codification of knowledge. This can lead to many problems associated with implementation of agile methodologies. In the absence of explicit

3.4 Challenges in Agile Software Development

43

knowledge, much time is wasted in replying the same queries. There are some occasions when individuals discover themselves in circumstances where they know that they have had a certain issue sometime recently but cannot recall the solution that has been used then. Whenever an experienced employee left organization, loss of knowledge has to be borne by the organization. Moreover, informal correspondence has no value because it cannot be used as a record and has no contribution to organization knowledge. The two main questions where most of the agile practitioner stuck are: “By what means can knowledge management be accomplished in agile software development with least documentation” and “How to capture the tacit knowledge created from informal communication”; in agile software, development difficulties encounter while implementing KM is to convert tacit knowledge to explicit knowledge. The knowledge produced through the process should be stored in a knowledge repository for future references. The practitioner should be more responsible for sharing knowledge among peers. Organizations deal with their logical assets just as their money to remain in the race of the competitive global market. Here, the role of the KM comes into existence; it enables the organizations to disseminate the right knowledge to the correct individuals at the exact time. It is also viewed as the primary source of competitive edge for organizations when facing new chances, time-to-market requests, and regular changes in their business conditions. There may be interference of the obstructions such as sociocultural differences, lack of coordination, competition, the burden of day-to-day challenges, the absence of specialized tools, places for communication, and lack of discipline inside the organization. Managers avert from putting resources into KM activities due to issues of social and professional stability. ASD carries some issues that need to adapt to the conceptual change, primarily the organizational social change that is the principle obstruction while bringing agile software development (ASD) into software organizations. Conceptual change is required while applying ASD in an organization; to begin with, participation ought to supplant the knowledge is power perception [11]. An organizational model that empowers joint effort, communication, and the entire team idea is introduced by ASD. At the same time, the culture in software development organizations that has been evolved over years provides a sophisticated way to cope up with problems, for instance, sometimes encourages opposite value and manners as communicated by hiding of data and isolating individuals in cubicles. Secondly, a change is required in the client’s conception and association, as well as in client–developer relations. Frequent and face-to-face communication with the client is backed by ASD. Obviously, this is a significant difference from the common practice used by the client in organizations. Reports, process, practices, technologies, and project artifacts are different ways of storing software knowledge. There are different ways of managing knowledge in the methodologies of traditional and agile software development. Agile approach manages tacit knowledge, whereas in conventional software, a development methodology produces explicit knowledge that can be effectively captured. To encourage innovation, tacit knowledge is required which is accumulated in the brains of individuals as memory, aptitudes, experience, creative ability, education, and imagination. It is

44

3 Agile Knowledge Management

quite difficult to extract the tactic knowledge from the brains of the individuals; it is prominent for any organization to use that information or knowledge when required.

3.5 Managing Knowledge in Agile Development Process As per the idea of agile methodology, the best way to judge the learning outcome of the team is by analyzing the working system of the team. All the documentations are worthless if they are outdated; so, the agile manifesto suggests to create no records except if the requirement for them is instant and important. Therefore, it is wastage of time and resources to record the incomplete and inadequate reports and plans instead of being dependent in terms of tactic knowledge of the individuals. Common obstacles are seen when knowledge management and agile software development methodologies are introduced in the organizations. Knowledge management is responsible for drawing the solutions from the knowledge bases to decrease the effect of worker turnover. It is a loss to an organization when a worker leaves an organization or association; the knowledge they possess went with them. This misfortune can destructively affect the profitability and quality of the organization. Knowledge management tries to discover approaches to limit the loss of brain drain when a worker leaves an organization. One of the major problems of agile development is that knowledge generated in the agile processes is tacit in nature and exists in the mind of the individuals that are hard to express. KM practices are normally encapsulated in the agile practices, so it is obvious for the agile to find out the solution to the problems faced by the organization while implementing KM in their processes. These practices try to resolve some of the challenges encountered by knowledge management. To improve KM procedures, it is quite natural to stress the idea of Agile Knowledge Management (AKM), in light of the fact that ASD as of now includes the organizational and social infrastructure required for KM. In ASD environments, KM can be possibly and effectively accepted. Clarifications for this point of view as follows: Qualities like collaboration and knowledge sharing have been incorporated in the agile cultural framework; ASD methods incorporate a few practices that help KM, for example, taking up stand-up meetings, pair programming and the instructive work environment. Second, KM is all about learning, and ASD sets up an environment that helps to learn. The resistance toward applying KM based on the truth that the real knowledge on the application of KM does not exist although many software project managers accept the significance of KM. The above-mentioned obstacles as well as others can be reduced slightly by making KM elements more explicit in ASD environments. Furthermore, because ASD is based on knowledge sharing and communication, it also benefits from the fact that the KM elements are clearly specified. KM into ASD processes can be naturally integrated and there are several illustrations to support this point [12].

3.5 Managing Knowledge in Agile Development Process

45

• The knowledge manager’s role: Different agile methodologies offer distinct role schemes; therefore, we recommend there must be one person who is responsible to carry out the KM processes. KM in large organizations is managed by the group of people who are responsible for the management of the knowledge and can frame a KM team for the proper execution of its strategies. It is the responsibility of KM officer in each group to bring back new data and insights to his or her team about relevant issues that are discussed in the meeting. • Retrospective meetings: In retrospective meetings, there can be a special session that may be dedicated to KM. This session might incorporate subjects such as new tools utilized within the most recent release and lessons learned amid the improvement of features. From retrospective meetings, it infers that as ASDs are carried out in brief releases in the same manner, the complete KM process is to be carried out. • Planning game: In each planning game meeting, to improve the development process as well as the developed product, some of the KM practices must be introduced in the next iteration. These techniques help in managing some of the knowledge developed during the iteration process. • Informative work environment and collective ownership: Every new piece of knowledge that has been generated during the iteration is first posted on the project whiteboard. Then, these pieces are too assessed and evaluated in the retrospective meeting. If the knowledge generated is significant, then it is put into predefined place at the end of the iteration. • Metrics: There must be some measurement that takes place on a regular basis regarding different parts of ASD projects and these metrics are identified with KM. Any of the metrics observed to be pointless will be adjusted accordingly. • Adaptability: The development of Agile Knowledge Management ought to steadily include all stages and exercises of the development procedures (e.g., prerequisites and design). There will be a constant verification for the appropriateness of agile knowledge management (AKM) arrangement for each stage. Sometimes the knowledge management activities in some cases make antagonism, so we recommend that the agile spirit of the change presentation will render the AKM activities more pleasing. Knowledge management approach incorporated in the agile process discovers and disseminates crucial knowledge among the stakeholders. This knowledge is utilized for performance enhancement, learning, and choice making to accomplish the task. Agile techniques changed the manner in which engineers find out about product development, for example, agile procedures do not encourage the utilization of formal documentation. Each and every individual in the organization has the knowledge about the product but it remains in their heads and it becomes tacit as long as there is not rotation in the project whenever the rotation takes place the exchanges of knowledge occur [13]. The exchange of knowledge between engineers and clients may include interorganizational knowledge exchange.

46

3 Agile Knowledge Management

3.6 Agile Knowledge Management Theories Three schools of knowledge management (i.e., technocratic, economic, and behavioral) are defined by Earl, and out of these three, technocratic and behavioral schools are related with agile software development. The technocratic school stresses on explicating knowledge and its flows. The technocratic school is further subdivided into three schools: system, engineering, and cartographic schools. The system school focused on knowledge management policies for technological use, and some of the examples of technological components are GitHub, JIRA, and Wiki. The engineering school gives stress on business perspective of software processes and the cartographic sees exerts working in the agile teams as knowledge hub for the team. The behavioral school emphasizes on teamwork and communication to foster knowledge management strategies. Activities like developing network among teams and utilizing workplace to support team communication are assets of behavioral school. There is a basic difference between the Earls technocratic and behavioral schools, the prior one specifically identified with conventional software development, whereas the later be more related to the agile approach. Behavioral schools provide more advantage to an agile team that is utilized by organizations for developing software. There are different categories of practices used by the spatial school and by the organizational school. The spatial schools utilize data radiators and colocated teams, whereas practices such as scrum of scrums identify with the organizational school. Reviews, regular meetings, and colocated teams are powered by an agile team and have great practices for KM; however, agile techniques give slight support to KM beyond team level. Here, an important asset is organizational school. Hansen et al. [13] and, in practice, most organizational KM strategies are codification strategies or personalization strategies. Agile software development practices use personalization strategies for managing the critical knowledge. The codification strategy systematizes and stores organizational knowledge, whereas the personalization strategy supports the flow of information through the organization through fostering connections between people and supporting a culture of communication. Most imperative resource in software development is knowledge, practically speaking; most organizational KM methodologies are codification systems or personalization techniques [13]. Agile and traditional software development methodologies prefer different strategies for development of software, where traditional software development methodologies prefer codification strategy. Agile prefers personalization strategy for managing critical project knowledge. Agile practices help in cultivating tacit knowledge.

3.7 Agile Knowledge Creation Theories The most widely referred hypotheses in KM are presented by Nonaka and Takeuchi [3], based on a model called SECI (socialization, externalization, combination, and

3.7 Agile Knowledge Creation Theories

47

internalization), and the natures of the processes for the communication in explicit knowledge as well as tacit knowledge are spiraling. The transformation of the knowledge using four procedures is mentioned as the components of the agile philosophy are demonstrated by SECI. • Socialization in Agile (tacit-to-tacit) There are different aspects, which contribute to accomplishing socialization by sharing tacit knowledge on regular individual meetings: iteration audit, release arrange, review, methodology meeting, daily stand-ups, and iteration planning. The crossfunctional group is collaborated to share knowledge between different zones of software development. Association of clients (product proprietors) comes about in exchanging the knowledge between the individuals. • Externalization in Agile (tacit-to-explicit) The regular meetings held in the agile process help to achieve externalization which is the outcome of the following objects: idea, objectives, release strategy, iteration tale assignments, acknowledgment examinations, and every day growth record are key factors to accomplish. Reports are additionally made from each meeting alongside the plans. To calculate the task and the guidelines formalized for the assessment are made explicitly. • The combination in Agile (explicit-to-explicit) Exercises like the formation of the plan in coordination with iterative backlog and progress bar, the estimation for the new plans are inferred and utilized in the next iteration are being used to accomplish the combination. We can combine the created requirements with the current client’s needs and modify them accordingly. The reports, planes, estimations, and daily progress records can be used to infer rules and best practices for future projects. • Internalization in Agile (explicit-to-tacit) Guidelines as well as most best practices being obtained from globalization are tacit and utilized in future projects. Handling of knowledge suggests that production of the information, exchange, and use is supported by agile by enabling team communication on a software project. • The 5-A Model Another exceptionally prevalent system of managing knowledge in agile methods is Articulate–Appropriate–Learn–Act–Accumulate–Anticipate (five-A) models for knowledge administration. Five-A model demonstration management of knowledge is clarified with the help of advantages of extreme programming (cf. Fig. 3.2). Tuomi’s [14] model to produce knowledge is utilized for the clarification of different practices that are used in extreme programming Agile techniques give rise to new perspectives which empowers others to specific agile exercises using more non-specific way. This

48

3 Agile Knowledge Management

Fig. 3.2 5-A model for knowledge management

model suits more to agile methodologies because this model explains the creation of knowledge when more than one CoPs are involved in the process. In agile methodology also at least two CoPs are present, first is customer represented CoP. It is specific to domain of problem and second is development teams CoPs.

3.8 Knowledge Management Strategies in Agile Software Development The quick demonstration of the agile software techniques may enhance the awareness of the readers in various aspects which in turn can be utilized to gain tacit knowledge, and this can be further utilized. • Whole Team Whole team means activities that are performed by the entire team in the development process. It comprises of the clients as well as the other participants of the team. A few different ways are used to connect with whole team practice. To start with, communication among the development team is encouraged through collocation and collaboration. Secondly, individuals of the team provide a demonstration of the products to the clients, listen to the requirement of the client in context with product, and crate an appropriate plan of action to fulfill it. Lastly, conventionally, the responsibility holders related to different teams (for instance the individuals who test the code and the who makes the design) are further combined with the development team and the associated processes. • Roles and Responsibilities There are different roles that each individual of the team has to perform, in addition to be a product specialist inside as a whole team scenario. The projects which generally

3.8 Knowledge Management Strategies in Agile Software …

49

employ software development comprise the majority of the basic and complex duties, not any single individual can deal with these complexities regardless of how talented the team leader is, to supervise the tasks and responsibilities it is more convenient to divide them appropriately to handle the process effectively. In addition, it ensures that each employee is contributing to the development process from their perspective tasks and responsibilities (see [15]). • Collaborative Workspace The workplace walls act as the information radiator as the team can use to see all the time at the metrics of the projects. These areas can be used to display important data such as relevant information, data regarding current iterations, backlog, and individual’s information regarding the status of the project. In this way, all project partners can be upgraded continuously regarding the progress of project development as well as the status of the project. • Stand-up Meetings These meetings are held daily among all the members of the team for maximum 10–15 min. The name stand-up comes for the short during for which these have been planned. In these meetings, there is an interaction among each colleague exhibiting status about the task they have undertaken and what the individual in question intends to achieve in how much time span, both development assignments and the individual job. Whenever required, one sentence can be included by each colleague at his or her turn as for foreseen issues. • Measures Measures play a crucial role in agile software development, which incorporates all the project stakeholders. Measures have been chosen to explore the development procedure so that good software is produced. Agile software development processes communicate the significance ascribed to measures by “a tracker” which is a particular role. This role was given to a colleague, who is accountable for the measures. The accountability of the development process leads the team to perform better in the process of the development, which in turn effect the development of the software in a positive manner. The process of the development should be scrutinized and also being transparent throughout the software development lifecycle and it should be conveyed to all the stakeholders those take part in the process of the software development. • Customer Collaboration According to the techniques of software development in context to agile, the client should be involved in the development process. The overall objective is to get the viewpoint of the client and perform the tasks according to the customer needs. This type of regular communication draws out the actual requirement of the client, and sometimes, restricted communication may lead to incorrect working assumptions,

50

3 Agile Knowledge Management

e.g., assumption of wrong hypothesis. The team individuals relates to clients while the development phase is in progress, and this type of straightforward communication guides the clients to provide the needed requirements to the team members who in turn help them to solve the problems which may arise later. • Pair Programming The teams implementing the concept of extreme programming very frequently use this practice. The code is developed by two teammates sitting on a single computer and in interactive, communication-intensive process to develop code for a specific task. Each individual working in pair has personal responsibility for the code although they work in a pair. During this process, it is harder for the pair to be distracted and focus on the development of the code for them. Moreover, there are two ways of the perception in which a task can be divided: individual, who writes the code, focused on the lower level of abstraction, called the driver, and second the person who thinks about the development of the code and works on the higher level of abstraction called navigator. Mostly, fewer experienced person work as a driver and high experienced person works as navigator, but they communicate and interact regularly to clear the thoughts regarding the development of the tasks. The idea behind the practicing pair programming is that each individual of the team should have knowledge of what is going on with the development process and can improve their understanding of the software as a whole [16]. Capturing and keeping up the essential knowledge is the significant learning process encouraged by this methodology.

3.9 Knowledge Involved in Agile Practices Agile practices embed some of the key processes of knowledge management. It is important to know what inherit knowledge is involved in these practices and teams working with agile methodologies to manage this knowledge. In the development of software, three kinds of software engineering knowledge are generated: product, project, and techniques. There are some agile practices that are responsible for management of all three kinds of knowledge generated during the software development lifecycle. For instance, knowledge about the product is concerned in various practices like sprint panning meeting (including domain context and system requirements) and release meetings. These practices help the agile team to gain knowledge about the product and requirements of the development task. Some of the major practices of the scrum also help in generation of product knowledge. Practices like daily stand-up meeting and collaborative wall (information radiator) used to stick the information regarding the stories, tasks, and burn down charts, ultimately help in generation of product knowledge. Project knowledge is about the knowledge related to the project. Release and sprint planning, daily stand-up, sprint retrospective, and planning game used to generate knowledge related to the project and help the stakeholders for better understanding of the deliverables of the project. Stand-up meeting describes the status of the project and exchanging the related knowledge among the team members. The progress of the project can be traced

3.9 Knowledge Involved in Agile Practices

51

down with the help of the burn down charts. Retrospective meetings are another kind of meeting used to share the progress and issues faced during the development, e.g., timeline issues, uncompleted tasks, unforeseen issues, and solution generated to resolve these issues. This knowledge generated can be used in other iterations or projects as learnings and can generate value to the organization. Process knowledge is also managed by many practices of agile methodologies like iteration planning, pair programming, collective code ownership, refactoring, and sprint/release planning. These practices used to manage the knowledge generated by the process used for the development of the software [17]. Overall with regard to implementing KM strategies, teams working with agile methodologies are seen to use deliberations (sharing requirements, dedicate meetings), artifacts (user stories, code repositories), and visualizations (collaborative wall, burn down charts) to handle the product, project and the knowledge about the process. Discussion and deliberation are the mostly used and highly recommended by the plan to administer the knowledge through agile practices. Most of the process knowledge is shared during discussions in a different kinds of meeting in which the ideas and the issues are conveyed in the agile teams, hindrances in the process, prospective solutions, feedbacks, and negotiations with stakeholders in planning and decisions. These discussions also help in generation of the project knowledge which is known as blockers that can affect project deadline [18]. User stories help the gain insight about the actual requirements of the user. The knowledge about the requirements is also captured in product backlog in the form of task cards used for designing, coding, and user interface development. Metaphor development in extreme programming another kind of artifacts used for generation knowledge is related to the product. Visualization technique supports in managing knowledge in a visible and available form. This helps in sharing tacit knowledge generated during the process execution among the stakeholders. These visible techniques such as scrum notice board (information radiator) used to display the progress of the team. States of the team can be checked by knowing about the user stories that have been breakdown into tasks and have been completed in single sprint. These whiteboards also show information reading feedbacks, feeling, and action points in retrospective meetings. Other visualization aids, e.g., burn down charts used to show team progress, status, achievements, and working code of pair programmers on displays [19]. The most commonly used visualization technique for viewing user stories, the daily status of the teams and the project is scrum board.

3.10 Conclusion Agile methodologies emphasize on the delivery of working software that have value to the customer. Furthermore, team working with agile methodologies focus on applying knowledge rather than sharing it. Agile methodologies offer limited support for sharing knowledge outside team, and knowledge sharing mechanism works well in intra-team communication where most of knowledge shared is tacit in nature.

52

3 Agile Knowledge Management

This tacit knowledge is shared casually using face-to-face interactions (personalization strategy) in contrast to traditional knowledge management practices [11]. Though consideration has been paid to knowledge sharing that happen among the team members working in colocation, distributed agile teams have also proved to be successful and many large companies are now developing software with agile methodologies. The focus of knowledge sharing has been shifted from just between teams to across the organization. The lack of knowledge sharing practices beyond the team may hamper dissemination of knowledge in enterprises. Agile knowledge sharing practices can be broadly bifurcated into practices among peers (e.g., CoPs and pairing of individuals), among experts (shared experts and paring experts), and among customer and managers (scrum of scrums and review meetings). As agile methodology gain wider acceptance among organizations across industry, methods for enabling interteam and cross-organizational knowledge sharing need to be considered. Interteam personalization strategies include scrum of scrums, team member rotation, CoP, and open discussion sessions. From organizational level, knowledge is a vital asset for any organization. However, it has challenges because of the scale and complexity of environments.

References 1. Herschel, R. (2008). Knowledge management and business intelligence. Available http://www. b-eye-network.com/view/7621 on 11.08.2018. 2. Abou-Zeid, E. S. (2002). A knowledge management reference model. Journal of Knowledge Management, 6(5), 486–499. 3. Nonaka, I., & Takeuchi, H. (1995). The knowledge-creating company. New York: Oxford University Press. 4. Stewart, G. B. (1990). The quest for value: The EVA management guide. New York, NY: Harper Business. 5. Stewart, G. B. (1991). The quest for value: A guide for senior managers. New York, NY: Harper Business. 6. Nonaka, I. (1991). The knowledge-creating company, Harvard Business Review, 69(6), 96–104. 7. Nonaka, I., & Takeuchi, H. (1996). The knowledge-creating company: How Japanese companies create the dynamics of innovation. Long Range Planning, 29(4):592. 8. Davenport, T. H., & Prusak, L. (1998). Working knowledge: How organizations manage what they know. Boston, MA: Harvard Business School Press. 9. Earl, M. (2001). Knowledge management strategies: Toward a taxonomy. Journal of Management Information Systems, 18(1), 215–233. 10. Alavi, M., & Leidner, D. E. (2001). Knowledge management and knowledge management systems: Conceptual foundations and research issues. MIS Quarterly, 107–136. 11. Havlice, Z., Kunstar, J., Adamuscinova, I., & Plocica, O. (2009). Knowledge in software lifecycle. In 2009 7th International Symposium on Applied Machine Intelligence and Informatics (pp. 153–157). IEEE. 12. Apšvalka, D., & Wendorff, P. (2005). The knowledge management strategy of agile software development. Publication, 607–614. 13. Hansen, M., Nohria, N., & Tierney, T. (1999). What’s your strategy for managing knowledge? Harvard Business Review, 77(2), 106–116.

References

53

14. Tuomi, I. (1999). Data is more than knowledge: Implications of the reversed knowledge hierarchy for knowledge management and organizational memory. In Proceedings of the 32nd Annual Hawaii International Conference on Systems Sciences. 1999. HICSS-32. Abstracts and CD-ROM of Full Papers January 5, 1999 (pp. 12-pp). IEEE. 15. Dubinsky, Y., & Hazzan, O. (2005). A framework for teaching software development methods. Computer Science Education, 15(4), 275–296. 16. Cao, L., & Xu, P. (2005). Activity patterns of pair programming. In Proceedings of the 38th Annual Hawaii International Conference on System Sciences (pp. 88a–88a). IEEE. 17. Andriyani, Y., Hoda, R., & Amor, R. (2017). Understanding knowledge management in agile software development practice. In International Conference on Knowledge Science, Engineering and Management (pp. 195–207). Berlin: Springer. 18. Kavitha, R. K., & Ahmed, M. I. (2011). A knowledge management framework for agile software development teams. In 2011 International Conference on Process Automation, Control and Computing (pp. 1–5). IEEE. 19. Levy, M., & Hazzan, O. (2009). Knowledge management in practice: The case of agile software development. In 2009 ICSE Workshop on Cooperative and Human Aspects on Software Engineering (pp. 60–65). IEEE.

Chapter 4

Agility at Scale

4.1 Introduction Majority of business leaders know about agile innovating teams. The business group, which is being small, are intended to remain connected to clients and adjust rapidly to evolving circumstances. They quite often result in superior efficiency, lower risk, and less duration to introduce the product to market and provide improved quality in contrast with conventional methodologies, when executed accurately. Agile methodologies are not just bounded to simply the small and collocated group conditions that are being advocated in early literature but have been adjusted to work in a wide variety of circumstances. Agile methodologies are being used all through the lifecycle of the software development, not simply the development phase, and regularly in complex situations that require more than the small and collocated team. The overall objective of each team working in a project is to cope with unique problem, with its own objectives, capacities. The common factor among these groups is to embrace change in its own way and after that adapts agile strategies, practices, and provides the most refined way to deal with those unique situations. Normally, there are many common queries that are arising in the minds of practitioners that have experienced or heard about the agile methodologies/groups. Imagine a scenario where an organization wants to launch handfuls, hundreds, or may be a huge number of agile teams all through the firm? Is there a possibility that entire segments of the business are trained to function in this way? As coordinated techniques enhance individual group execution, would extend the agile enhanced business routine to a great deal in case of an individual team? In the present turbulent markets, where organizations are irately fighting from startups and rebellious opponent, the possibility of moving quickly and adaptation is very significant. In any case, transforming it into a reality can be demanding. It is very difficult for organizations to realize what functions ought to be recognized in multi-disciplinary agile teams. It is not advisable to initiate many fresh agile teams

© Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0_4

55

56

4 Agility at Scale

just to observe them bottleneck by bureaucratic administration. The change from conventional chains of command to increasingly agile enterprises has confirmed that there is more to gain by using these strategies. It also has considered the scaling up the agile in many organizations, including little companies that entirely work with agile methodologies. Spotify and Netflix are the examples of a large organization that was born agile and companies like Amazon as well as USAA (the company which handles the financial matters for the military) are transiting themselves from conventional to more agile endeavor. It may provide the benefits to the companies by enhancing the performance but to do so the leader should have a realistic view. There are some situations where agile cannot be implemented, as a matter of fact that not each project requires agile methodology. When you start launching some or many agile teams, though, you cannot simply leave alone other parts of the business. In new agile units, an absence of coordinated effort among operations and development groups or bottlenecks by bureaucratic strategies, a disagreement may arise among organization teams, which would prompt the poor outcomes and the differences. Alteration is essential to make sure that the function that does not work as agile teams support the teams that work in agile.

4.2 Understanding the Scale Initially in 2000s, projects developed with agile methods were little in scope and generally simple. The techniques of the agile methods (like small and colocated teams) still are able to do the tasks in these particular circumstances. In today’s era, advancement in agile methodologies is applied to the broader set of projects as the perception of the organizations has changed considerably. Organizations frequently manage issues that require large teams; distributed workforce; collaborating with other organizations; meet the terms of the policies and industrial standards; and addressing technical or social problems. Each project team has its own difficulties and different scaling factors; however, these issues add multifaceted complexities, and techniques should be discovered to overcome these challenges. The agile restrained delivery process needs to adjust, or scale to manage the numerous businesses, organizations, and technical complexities your development organization faces [1]. • Large and Distributed Teams Standard agile procedures work great for lesser groups of ten to fifteen individuals yet imagine a scenario in which the group is a lot bigger. Since the size of the team expands, the communication risks increase, and coordination turns out to be increasingly troublesome. Thus, classic face-to-face communication techniques begin to fall apart. Consider a scenario when the team is dispersed—maybe on the different story inside a similar building, diverse areas inside a similar city, or even in various nations? What occurs if you allow your employees to work from the home? What occurs if your team is distributed in various time zones? All of sudden, collaboration turns out to be all the more difficult and separateness is bound to happen.

4.3 Leading Agile by Being Agile

57

4.3 Leading Agile by Being Agile Teams working in agile methodologies are most appropriate for development where creativity is to improve the quality of the products, methods, and services or the business. It works in a modular approach in which huge and complex issue is broken into modules, produces a well-managed solution for every part through quick prototyping and time-bound responses loops, and incorporates the solution into a coherent entirety. They are adapted to change rather adhering to a particular plan, and they consider themselves responsible for outcomes (e.g., development, benefit, and client faithfulness), not for outputs (e.g., coded lines or the items produced). In any circumstance where issues are unpredictable, solutions are not clear instantly, project prerequisites are probably going to change, and these conditions are ideal for agile development. The close coordinated effort with end clients is doable, and creative groups may beat the performance of command and control teams. There are many routine tasks, which are less prolific (e.g., maintenance, purchasing, and accounting) where agile development may not prove fruitful. Agile techniques first introduced in IT divisions and are now broadly utilized in software development. With the passage of time, these methodologies have spread into different areas, for example, HR, product improvement, and promoting [2, 3]. The working method of the agile team is unique in contrast to hierarchical administrations. They are mostly self-organizing: There is always guidance available to colleagues by their senior colleagues, where to improve yet not how and the groups work closely with clients. In a perfect world, this puts duty regarding innovation in the hands of the individuals who are nearest to clients. It lessens levels of control, subsequently accelerating work, and expanding the teams’ innovation. It likewise frees up senior leaders so that they do what no one but only they can do: setting up the vision, arrangement of key needs, and fabricate the authoritative abilities to accomplish the determined goals. The moment at which leader may attempt to scale up agile development in the manner in which they have approached the other methodologies, e.g., by top-down approach or by command. This may lead to chaos in the team. The precedence is set by the executive team and corresponding chances to get better clients’ experiences and improve their success rate. To take care of issues, the leaders take the charge and remove the restriction other than assigning tasks to assistants. Leadership teams of the agile, alike other teams of the agile, has an “initiator” who is in charge of general outcomes and a catalyst who mentors colleagues and helps keep everybody effectively occupied [4].

4.4 Getting Agile Rolling In advanced agile enterprises, the visions are ambitious. However, it is not possible for the leadership to plan everything up front that may be going to happen. Leaders cannot distinguish that it is not known at this stage how many agile teams are needed

58

4 Agility at Scale

for this purpose, how rapidly they should include them, and in what context they should encounter technical limitations without putting the organization into chaos. As a result, they can commonly introduce the initial phase for the agile team, collect information on the behalf of those teams, the difficulties and the barriers they face, and afterward choose what to do, when to do, and how to achieve this. These provide a chance to determine the benefit of expanding agile (as far as budgetary outcomes, client results, and worker performance) against its expenses (regarding both monetary speculations and organizational difficulties). To implement the agile in other sections of organization the main concern is whether the benefits exceed the costs; leaders can keep on scaling up agile—deploy other agile teams, the organization has to unblock restrictions in those parts of it, which are less agile. If it is not there, they can take a break, keep an eye on the market condition, and investigate approaches to expand the charge with regard to agile teams (e.g., by giving the preferences to the task or improvement abilities for creating blueprint) and lessening the expenses of modification (by broadcasting the agile success or recruiting experienced agile devotees). To begin on test-and-learn cycle, management can regularly utilize two basic devices: a scientific classification of potential teams and a sequencing plan reflecting the organization’s key needs. Allow first to take a gander at how each can be utilized and afterward investigate what more is expected to handle extensive scale, long-term agile activities.

4.5 Create Taxonomy of Teams Similarly, as agile compile backlog of work going to implement in future iterations, organizations that effectively upgrade agile usually start by making a full taxonomy of the opportunities. Taking actions using agile’s modular approach, they can divide the taxonomy into three parts—customer experience groups, group associated with business procedures, and development systems groups—and afterward integrating all the parts. The first segment distinguishes all the issues that could fundamentally influence external and internal client decisions, behavior, and fulfillment. The second level considers at the associations among these segments and important business forms, planning to minimize overlapping responsibilities and cooperation exertion between procedure and customer experience groups. The third spotlights on creating innovation frameworks (e.g., better portable checkout applications) to improve the procedures that bear client experience teams. The people in charge of business units and product lines can be tied to the activities of agile teams. The manager in charge is responsible for the explicit parts of the product development and sees how cross-functional and self-organizing teams affect their outcomes, and it is the sole responsibility of the senior member who is working as a general manager in the company. Yet, leaders depend on client engagement, cross-functional teams to complete a significant part of the work. There is a dependency of the organization, which relies upon technical and resources based on digital technology assigned to the experienced staff; the objective can be to guarantee that

4.5 Create Taxonomy of Teams

59

the higher authorities in business possess all the required resources for providing the outcome which they have in their mind. The main aim of the taxonomy is to ascertain that the right set of people have been engaged in the right set of tasks to eliminate confusion This sort of link is particularly essential if there are many levels which do not align with the conduct of the clients.

4.6 Sequence the Transition Taxonomy ready, the management can initiate the transition process based on its priorities. There are multiple criteria for initiating transitions, e.g., ROI, availability of resources, interdependence of teams, etc. Some important issues that have been overlooked by customers/employees on the one hand and constraint of the organization on the other hand can create problem in agile transformation. These overlooked issues if given proper weightage can help set right balance between the pace of agile roll-out and number of teams that organizations can handle. Companies facing strategic threats have pursued big bang change. In 2015, the Netherlands face the same threat, including IT development, project management and abolish all the job roles. By then, it created minimal agile “squads” which requires around 3500-man force to reapply for 2500 overhauled designations of the squads. There is an extreme difference in about 40% of the staff occupying the designations expected to adjust new occupations and all expected to altogether change their mindset [5]. It is always not possible to bring change in one shot. To modify, it requires full-scale management support, an open culture, skilled and experienced agile practitioners to staff teams without draining their diverse capacities, and profoundly prescriptive guidance manuals to adjust everybody’s behavior. They similarly need a high tolerance of risks, alternative approaches to oversee unanticipated breakdowns. ING continues settling wrinkles, as it becomes lightweight throughout the enterprises.

4.7 Roll-Out Agile in Steps Many organizations adopt shortcut methods and made mistakes. The teams are managed from offsite location. They try to create a way around to systemize obstacles. This rather alleviates the chances of success for the team, but it disrupts the learning process or chances of scaling of the teams from a few too many. The agile team, which is deployed in the early stages of the organization, carries the burden of destiny. It is like a test for that team as a testing a product prototype under several circumstances. Before rolling agile, organizations have to do some groundwork. In reality, rolling agile does not mean that success is sure if things are arranged systematically. It implies that the teams should be focused on a business prospect, responsible for outcomes, trustworthy to work without dependency, guided by clear choice rights, legitimately resourced, and working in a small team having specialists in multiple

60

4 Agility at Scale

Fig. 4.1 Rolling agile

domains that are enthusiastic regarding the chance (see Fig. 4.1). Along with these teams must be dedicated to agile value implementation, standards, and practices, authorized to work together intimately with clients, able to make quick models and quick input cycles, and support from higher officials will deal with an obstacle and drive the selection of the collaboration.

4.8 Master Large-Scale Agile There is a misconception among managers in having trouble in visualizing little agile groups which can affect the projects that run for long-time duration and are of large scale. Principally, no restriction is there for creating a number of agile teams and the time span related to the activities. You can create “teams of teams” that take a related activity—a methodology that is profoundly adaptable and scalable. It is required by the organization that their leadership teams instill agile values.

4.9 Building Agility Across the Business It is a vital step to increase the number of agile teams in order to increase business agility, and however, equally important is whether the communication is taking place within a team or teams with the rest of the organization. Indeed, even the most progressive agile organizations like Amazon, Spotify, Google, Netflix, Bosch, Saab, SAP, Salesforce, Riot Games, Tesla, and SpaceX work with a blend of agile and conventional teams. The following areas guarantee that bureaucratic functions do not hamper effort by agile teams or neglect to embrace agile and market the innovation created by those teams; such organizations always push for change that is more prominent.

4.10 Values and Principles

61

4.10 Values and Principles A few agile teams sprinkled around the traditional hierarchical organizations can be used to initiate the agile within the company. There may arise clashes between the agile teams and traditional methodology of developing the software, the personal interference as well as workarounds are needed for settling the matter. When an organization launches a few hundred agile teams, then this sort of ad hoc arrangement between agile teams and traditional methodologies is never going to work. Generally structured parts of an organization maintain the status quo, whereas agile team will work hard on each front for the progression of the business. Likewise, if any change happens, the disbelievers of agile develop the antibodies and rise doubts on agile methodologies, going from refusals to work on a timeline to the retention of funds from opportunities that require developing innovative solutions. The parts of the organization that doesn’t organize into agile teams must be included by the leadership group of the organization wanting to scale up agile needs to impart agile values and principle all through the projects. Agile would be at the nucleus of the organization culture as the new management standards might be fanned out all through the organization to guarantee that everybody comprehended that things would be unique.

4.11 Operating Architectures Modularization is required for executing agile at scale and afterward consistently integrating work streams. In the company’s multifaceted frameworks, an organization can deploy software many times each day since its IT engineering was intended to enable designers to make quick, releases without any hustle. However, numerous large organizations, regardless of how quick they write the code for the programs, can deploy the software just a couple of times each day or even in a week; that is how their architecture works. In organizations that extended agile, organizations outline the support procedures and routine activities largely look the same as they did before, however, with less control hierarchies and wider range of control as a leader figure out how to trust and enable individuals. The bigger change is the way functional division works. Utilitarian needs are essentially lined up with corporate methodologies when organizations key needs are set such as improving clients’ mobile practice that cannot be used on the last of the list, e.g., at the 15 locations on the account’s funding list or HR’s hiring list (see Fig. 4.2). Furthermore, offices, for example, legal may require buffer ability to manage imperative needs from high-precedence agile teams [6]. Routine activities with various leveled structures are probably going to grow progressively toward agile over time. Obviously, it is included in the routine work of the finance divisions that they will dependably oversee spending plans; however, they do not have to continue scrutinizing the choices of the owners of agile activities.

62

4 Agility at Scale

Fig. 4.2 Agility across business

These trades-offs are hard to accept and tough to implement for a few people and organizations. If you find that individuals are more joyful and success rates triple, then it is a good decision to reducing control on the teams.

4.12 Talent Acquisition and Motivation Organizations that are scaling up the agile teams need a framework for obtaining experienced, valuable resources, and inspiring them to improve teams. They likewise require releasing the capability of colleagues and imparting responsibility, commitment, and trust to achieve results. There’s no pragmatic method to do this without altering HR strategies. An organization can never again employ only for technical skill, for example; it now needs skill in conjunction with passion for working in a self-organizing team. It is not an accurate criterion to assess individuals as indicated by whether they achieve their primal: It now needs to take a gander at their execution on lightweight teams and at colleagues’ evaluation of each other. Execution appraisals normally move from a yearly premise to a framework that gives pertinent feedback and training at regular intervals of weeks or months. Coaching and training programs support the improvement of cross-functional abilities redid to the requirements of the employees. Position in the organization matters less and changes less often with self-overseeing groups and less hierarchical levels [7]. Vocation ways show how item proprietors—organization vision and possess the repercussion of an agile group—can precede with their self-dependent, grow their impact, and increment their pay.

4.12 Talent Acquisition and Motivation

63

Organizations may likewise need to reconsider their pay frameworks to compensate the team as opposed to individual achievements. They need acknowledgment programs that praise commitments right away. Open acknowledgment is superior to secret money rewards at reinforcing the qualities—it rouses beneficiaries to improve much further, and it persuades others to imitate the beneficiaries’ practices. Leaders can likewise remunerate a team member by drawing in them in challenging tasks, furnishing them with the most progressive tools and the best conceivable opportunity, and associating them with the most capable guides in their field.

4.13 Annual Planning and Budgeting Cycles Yearly planning and financial discussions are the most substantial tools for regulating the organization and verifying commitments to extend objectives, but agilist starts with other pre-assumptions. Usually, customer needs change as regularly as would be prudent and that cognizance can happen anytime during the project lifecycle. In their view, yearly cycles restrict innovation and modification: Unproductive ventures devour assets until their financial plans ran out, while important innovation sits aside in line for the next financial cycle to raise funding. There could be different financing methodology in an organization that works in conjunction with an agile team. The financiers accept that in 2/3 of the positive innovations the underlying perception will alter amid the product improvement lifecycle. They expect that product improvement groups will drop a couple of features and deploy others without waiting for the following yearly cycle. Investor normally observes financing decisions as opportunities to purchase options for further exposure. The goal isn’t to immediately make a substantial scale business yet, rather, to locate a critical segment of the eventual solution. However, this prompts numerous failures yet enlivens and diminishes the cost of learning. Such a philosophy functions well in an agile organization, hugely improving the speed and efficiency of innovation. The majority of the agile test-and-learn techniques are dynamic and iterative in nature, and however, nobody should confuse incremental development forms with incremental thinking. SpaceX, for instance, expects to utilize agile development to start transporting individuals to Mars by 2024, with a dream of building up an independent colony on that planet. Presently, the query is how it turned into a reality? It isn’t arranged, yet the individuals working in the organization have a faith that it may be conceivable and have a dream for this. They need to lessen the expenses mostly by reusing rockets as this can be possible in case of airplanes also and improve the consistency. Following are some of the points that need to be critical thinking in planning. • Domain Complexity Some applications require the straightforward solution of the projects such as developing an application, which handles data entry of the organization or a simple website

64

4 Agility at Scale

for information. Agile methodologies can give good results where the problem statement is complicated such as measurements of a biochemical procedure. Some tasks involve varying situations such as financial derivative trading. As the field is more multifaceted, it requires huge importance on the exploration and carrying out large experimentation, as well as not confined to prototyping, modeling, and simulation. • Organization Distribution There might be conditions when a team incorporates people from different divisions, associated organizations, or from outside firms. The more hierarchically dispersed teams are, the almost certain the relationship will be authoritative in nature rather than collaboration. An absence of the administrative cohesion can phenomenally expand the risk of the project in light of the absence of trust and trust which may diminish the capacity to collaborate and can grow the risk with Intellectual property (IP). Sometimes a couple of applications are more complex than others. Sometimes, your team work with legacy frameworks and legacy data sources that are not completely perfect. Some other time, you are building a framework for heterogeneous platforms or for few distinct technologies. Likewise, at different events the sort of the issue your team is attempting to solve is complicated in its own right, requiring an intricate arrangement. • Organization Complexity and Discipline Your current association structure and culture may reflect waterfall values, expanding the multifaceted nature of embracing and scaling agile procedures inside your organization. Then again, a few teams inside your organization may wish to pursue techniques that are not superbly perfect with the way yours needs to work. The primary goal of any organization is to drop down the costs, lessen the time to reach the product to the market, improve consistency, and continuous evolvement. This can be troublesome if your development team focuses just on their immediate requirements. To use regular infrastructure, development teams need to exploit organization archetypes, business models, and portfolio management. These disciplines must work together with, and even better improve, your agile development process. Regardless, this does not come free. Agile teams need to incorporate architecture specialists as partners. The project specialists also need to make sense of how to work in an agile way, a way that may be altogether different in contrast to the manner in which they have worked. • Organizing Large Teams At the point when agile groups involve no less than 30 people, it is viewed as large team. A substantial group (large team) may be divided into subgroups. Some other explicit roles need to be added in the large agile teams especially leadership and coordination roles. These jobs for coordination are alluded to as the coordination group. Sometimes large teams require an integrator, yet this isn’t a mandatory job and not normally utilized by the administration. By and large, team coordination is taken care of by the leadership group, which is ordinarily headed up by someone

4.13 Annual Planning and Budgeting Cycles

65

in the activity of program coordinator, every so often implied as an undertaking executive, who is in generally overall in charge. The leadership team comprises of the persons in senior jobs. Together, these individuals address the aspects of team cooperation. Any issues that emerge among the teams are regulated by organization subgroups (PO, Project Management) by means of group meetings and by electronic techniques as required. Numerous agile groups find that these coordination issues have distinct rhythms. For example, requirements and technical coordination occur toward the beginning of every iteration, however, diminish later in the cycle, yet coordination is required every day and throughout the iterations of the project. An increasingly critical need exists for shared models, documentation, and plans, particularly if the group is geographically distributed. Utilization of incorporated tooling that is instrumented to give key measures, which thusly are shown on project dashboards, can give more exclusive perceivability of what’s going on inside the group and in this manner help coordination.

4.14 Best Practices It is very tricky to standardize techniques for working. It is likewise hard to perform well, however, simple to do poorly. Standard methods for working are related to making a normal way for working that makes it simpler to complete things, lessen friction, and empower collaborative effort and effective utilization of time. Joint effort and transparency must connect to customers and business stakeholders than enterprise only. Making such a communitarian organize through dynamic affiliations and collective ecosystem for value creation requires extensively higher degrees of empowering people. The question emerges here why? These forefront workers can work hands-on with clients, sellers, and other parties for the development of new solutions, services, and products. This cohesion just originates from a sound culture reinforced fundamentally through leadership role models, peer pressure, and fit-based enrollment and not through strategies, rules, or order and control chain. Job adaptability is vital. This implies your role on some random day and for some given group may change in all respects rapidly as needs change and new opening emerges. Typically, mobilization of role among team members requires an inside talent market to help match individuals with the most appealing and value-oriented roles they could play. Organizations that made inner talent markets get enormous advantages because the market regularly can match individuals and work significantly more adequately and effectively than various hierarchical decisions cascaded down the organization. The new innovations are utilized which are as proficient and versatile in nature share information. Big data and artificial intelligence will require agile organizations to keep up a practically unprecedented level of cross-functional coordinated effort among innovation, digital groups, and the business. Technology must have measured, adaptable engineering to react to quick evolving needs. It must be integrated flawlessly with key procedures, so it is simple and natural for clients.

66

4 Agility at Scale

On a fundamental note, the organization ought to be very far along its journey before scaling agility over the entire organization. That is the most ideal reason to have some successful pilots added to repertoire to help gauge the value that can achieve when you do start scaling agile enterprise. • Leverage a strategy that works for you Leading toward agile requires some extensive changes in terms of roles and responsibilities, organizing and the software development lifecycle itself. This is when firms would benefit by assessing their approach in achieving agile and guaranteeing that it accommodates their project needs. There are various choices to choose from, e.g., large-scale scrum, concerning how scrum can be connected in numerous dimensions to suit large-scale improvement—and disciplined agile delivery—which is a people-first, learning-focused mixed agile methodology. • Break down big jobs In large enterprises, there is likely going to be huge teams of individuals committed to projects. It is a challenging situation and makes things extensively complex while coordinating everyone, particularly if employees are disseminated across organization areas or work remotely. In Leffingwell’s book “Scaling Software Agility: Best Practices for Large Enterprises,” he noticed that in conventional development models, problems can be overwhelming and can affect job satisfaction across teams (see Fig. 4.3). However, the main perspective of agile is that it splits the whole work into smaller tasks so that they can be handled easily. This will enable the team to keep on the schedule list, monitor changes being made, and reduce risks. Utilizing agile test management instruments help teams stay aware of activities, regardless of whether individuals are not working at the same location. The real-time updates will ensure that everyone is always on the same page, eliminating redundancies, and helping improve overall employee satisfaction. This will help facilitate continuous development efforts and enable teams to roll out updates faster and more frequently than ever

Fig. 4.3 Best practices in agile implementations

4.14 Best Practices

67

before. “With agile, progress and job satisfaction are constant, frequent, and in real time,” Leffing well wrote. “The next opportunity to show your wares to a customer, peer, or other stakeholder is at most a week or so away” [8]. • Scale-up and Scale-out There are many significant variations that occur in agile software development in contrast with how the development team handles the work, yet it can likewise influence how the organizations advance to keep pace with competitors. Agile has the capability to answer the question regarding success and failure in the long term according to ZDNet contributor Stephen Younge. Younge gave the case of a producer that could develop from a group of 100 designers to more than 1200 by pursuing a large-scale agile transform. This enabled the organization to improve employee engagement by almost 10%, lessen the time to market and production by 20% each and decline field issue goals time by 42%. For organizations, agile should not simply scale up to help the developing number of employees; it should likewise scale out over the value chain to deliver the valuable product. That even if large enterprises cannot be supported by all values in the Agile Manifesto, taking those concepts and stretching them will help achieve agility at scale.

4.15 Failure of Agile in Large Organization Agile software development methodologies have benefited various teams and organizations regardless of their sizes but the actual effect on business depends upon how the integration of these methodologies into their operations. Agile may give a significant advantage over traditional devolvement methodologies but the journey of this transformation may not be so easy. According to Dr. Dobb’s Journal, 71.5% of agile projects succeed as compared to project build with traditional methodologies that have a success rate of around 68% [9]. It’s important to know the root cause of the difference in the success rate of the projects so that you can prepare your organization for agile methodologies. Some of the common areas that may impact the adoption of the agile development process in large enterprises are.

4.16 Lack of Clarity Large organizations are scaled organizations that mixed kind of man forces some working in colocations, some working in distributed teams, and some working remotely (work from home). However, it is important to have close collaboration and communication among everyone, if remote or distributed workers/teams cannot do this then it will be very difficult for them to contribute and hence reducing the chances of project success. A common challenge that a large organization faces is

68

4 Agility at Scale

forming complete cross-functional agile teams and making sure that these teams’ clear backlog in time. At scale in larger enterprises, it’s very difficult to figure out a pattern that permits agile groups to collaborate and sit together and held responsible and establish a steady velocity for progress. Cottmeyer wrote, “We look for places to align business process and technology and teams into these units that can ultimately become agile teams and become more loosely coupled from the rest of the organization.” A standardized process of information sharing can be brought agile teams together, and such kind of resources help in agile development efforts. Tools used for project management can provide clarity for the whole team concept especially when teams are distributed, and the leadership team needs combined information about the progress of the project in a consolidated form.

4.17 Continual Reliance on Legacy Methods Cultural shift is required when you transition to agile methods, but sometimes teams use waterfall and other traditional methodologies for certain operations that can lead to failure. As per data, 9th annual survey by VersionOne, almost 37% of participants felt pressure from leadership teams to follow traditional methodologies and 42% have a view that their organizational culture is at odds with core agile values. The worst part is, lack of leadership team support and reluctance of the team to work with agile methodologies, increase the failure rate of their agile projects. Since agile methodologies involve substantial changes like frequent releases, shorter time to market and continuous development, having resources and support is very critical for the success of these methodologies. However, the survey exposed that around 44% of the participant mentioned that bringing change in organizational culture is the biggest obstacle to increase the agile adoption, while 32% supposed that dominance of traditional frameworks creates hindrance in agile adoption [10]. “We know that agile is first about ‘how you think’ and then about ‘what you do’”. This is quoted by the Agile Alliance in response to the survey. Agile influences organizational values and enabling this change is the primary step to have a wider adoption of agile, and success with agile means, successful value delivery.

4.18 Inadequate Experience with Agile One of the reasons for the failure of agile projects in large enterprises is the fact that people lacks in the practical experience of working with agile methodologies and its integration in organizational culture. For better integration, enterprises should create a game plan and provide experience through pilot programs and coaching. Organizations often take small projects within a larger context or transform large projects into agile initiatives. Although, deprived of essential knowledge, chances of failure scaled up, this is an important aspect that is often underestimated while

4.18 Inadequate Experience with Agile

69

doing agile transformations. Finding answers to some of the quires like, how do role changes in new software development approach or what is meant by iterations can provide essential inputs to the team for transforming into agile. Training team members for different roles that can assist in building crossfunctional teams will leverage agile testing methodologies and ensure that projects succeed with a new development approach. Leadership teams may also be trained as roles and responsibilities will change radically while applying agile methodologies. This will help the leadership team to understand the working of self-organizing teams and help in creating a suitable environment for teams to excel. They have to comprehend the new metrics and how to obtain them. Another problem is a lack of collaboration among the members of different subcontracting enterprises. All the teams working in different subcontracted organizations share the same objectives and plans. There are many games that are playing in different subcontracted firms and every game has different objectives. Team members need to respond to project objectives as well as those put forth by their own organization. However, the latter may not be aligned with the goals of other subcontractors working on the same project. To make matters worse, in many occasions a company is subcontracted to fulfill all positions in an area of expertise (e.g., subcontracting a company to do the testing). Entire team is responsible for maintaining the quality of the code, but if a disagreement arises it will be between expertise and companies. But, these kinds of issues generally do not arise in agile development, but in agile settings, iterations in which all members have to interact and actively collaborate can become a major problem. For this, creating a team that shares the same objectives and where members really collaborate is a major challenge, and we know that effective collaboration is important to project success.

4.19 Looking for Testing Strategy Whenever an organization transforms from traditional to agility, it misunderstood the concept of testing in agility. There is a change in the role of a tester in agile software development, so the skills required for testing in agility also change. In agile development, testing must be performed iteratively over features that if seen from traditional software development point of view are still not fully complete. Furthermore, regression testing is to be performed continually to make sure that already built features keep working. This infers that quality assures ace team must do undergo major reshuffle and changes. Failure to understand this results in a major cause of disappointment in many agile transformation endeavors. As mentioned before, passable training for QA personnel and the selection of a good agile test management tool is of utmost importance.

70

4 Agility at Scale

4.20 Lack of Alignment in Areas of the Enterprise It is commonly seen that large enterprise works with both software development methodologies, some projects are handled in agile and other in traditional methodologies. The issues arise when these teams need to interact with each other. At the problem sight when an agile team needs some inputs from the team that do not work with agile methodologies and during the iteration if agile team demands something from other team working with some other methodology and could not provide the required inputs, as a result agile team cannot complete the work which is being committed by it during the iteration. It is a common mistake in large organizations to think that interaction between agile and non-agile teams will be possible and will work smoothly. It is worth mentioning here that agility is about removing the dependencies across entire enterprise. Aim in a large organization working with both kinds of methodologies is to get team aligned and ensure that managers of teams that are not working with agile to understand the implications of interacting with teams that do work in a new way.

4.21 Larger Teams and Pyramid Structures Size of the teams should the same irrespective of the size of the organization. The ideal number as suggested by many practitioners of agility is around seven team members. But many times, teams working in large enterprises end up being larger than a team that is required for the project. There can be many reasons for this: restructuring of teams, pyramid structures lean toward the creation of bigger teams, culture or organizations may have many employees. The problem may exaggerate if those team members are partially allocated to the project as the commitment is not the same, in addition problem of middle manager’s contribution to the project from an even more external perspective. As a result, a price must pay for overstaffed teams that include increases complexity, large meetings, and less productivity. Additionally, situation may arise that teams of big organization may have more than one boss. Though agile recommends the team to self-organize and each team member can suggest and decide the best way a task can be completed by team collaborative effort but having a boss inside the team (e.g., technology lead or architect) may create hindrance to the core values of agility. Innovative teams prefer flat structures, and this is not the case in big organizations. Large organizations, e.g., Amazon, are working with autonomous teams having less than ten members. Amazon called it “two-pizza team rule” as the model team should be small enough that its members can be fed with two pizzas. Jim Highsmith in his book on Agile Project Management raised one point that “If change, adaption and flexibility are the trademarks of agile projects and conforming to plan is the trademark of traditional projects, then why do we still measure success on agile projects using the traditional frameworks?”

4.21 Larger Teams and Pyramid Structures

71

Fundamentally, if you have changed the development approach then change in performance management objectives of the organization is also required. Otherwise, the software development group will be working around one set of objectives, and the management team will be working around another [11].

4.22 Conclusion Significant changes in the business have been seen by the organization that scaled up agile implementation. Scaling up mix of work with objective that business will do more innovation rather than routine work. This help business to examine varying conditions and requirements, make adaptable courses of action, and sidestep the constant crises that severely affect traditional structures. Disruptive innovation will come to feel not so much disruptive but instead progressively like adaptable just the same old thing new. This kind of scaling furthermore passes on composed characteristics and benchmarks to business undertakings and supports limits, paying little mind to whether various ordinary activities remain. It drives to efficiency that is logically prominent and productivity in a part of the business’ tremendous cost focuses. It improves operational building and hierarchical models to update coordination between agile teams and routine activities. Changes are consistently receptive to client needs. Finally, there will be an improvement in desire-related outcomes similarly as dynamically observable client faithfulness and authority satisfaction in the business, which passes on quantifiable updates in results. Big enterprises usually deal with problems having more complexity than smallor medium-scale enterprises, reasons behind is they have more employees, subcontracting, and different business units. At the same time, they have the pressure to deliver system continuations and frequently in an ever-changing environment. They have to be agile. Large enterprises that are transforming from traditional to agile methodologies must learn for the organizations that have already been transformed for traditional to agile and learn from their experience. Agile mindset may take time to adjust, but by understanding challenges those firms have faced may help the beginners to learn from it and mend their ways. This will help businesses plan better for their transition to agile processes and improve the chances of successful projects.

References 1. Subramaniam, V., & Hunt, A. (2006). Practices of an agile developer: Working in the real world. Pragmatic Bookshelf. 2. Embracing Agile. (2016). HBR. Available https://hbr.org/2016/05/embracing-agile. Accessed 12.11.2018. 3. HR Goes Agile. (2016). HBR, March–April 2018. Available https://hbr.org/2018/03/the-newrules-of-talent-management. Accessed 2.11.2018.

72

4 Agility at Scale

4. Shore, J. (2007). The art of agile development: Pragmatic guide to agile software development. Newton, MA: O’Reilly Media, Inc. 5. One Bank’s Agile Team Experiment. (2018). HBR. Available https://hbr.org/2018/03/the-newrules-of-talent-management#one-banks-agile-team-experiment. Accessed 02.11.2018. 6. Do you need an Architect in a Software Company? Available https://blog.rapid7.com/2015/ 09/16/do-you-need-an-architect-in-a-software-company/. Accessed 29.11.2019. 7. Layton, M. C., & Ostermiller, S. J. (2017). Agile project management for dummies. New York, NY: Wiley. 8. Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. London: Pearson Education. 9. IT Project Success Rates Survey Results. (2007). Available http://www.ambysoft.com/surveys/ success2007.html. Accessed 10.11.2018. 10. VersionOne. (2018). Available https://www.versionone.com/about/press-releases/versiononereleases-9th-annual-state-of-agile-survey-results/. Accessed 05.01.2019. 11. Highsmith, J. R. (2009). Agile project management: Creating innovative products. London: Pearson Education.

Chapter 5

Mastering Agility

5.1 Introduction No procedure is perfect. It may have some flaws. There is always a chance of potential improvement in each process. Eventually, we will likely to remove the barrier and eradicate the hindrance that comes into the way of the team, in the achievement of successful project and smoothly adjusts the approach as circumstances change. This is what agility is all about. Are there any set of principles and beliefs that correspond to agile development? Agility is a combination of methods that have been evolved and used prior to it when the term “agile” actually came into existence. It is only an umbrella term. Agile processes exchange ideology and values. It is composed of five themes: process improvement, rely on the populace, remove waste, value-driven, and technical expertise. Each of these has a direct correspondence with agile methods. The first and foremost requirement is the need for total involvement and mindfulness to have an experienced and skilled individual for improvement in the agile. As you gain experience, it causes you to perceive how agile strategies work. Mindfulness at work encourages you to understand why your experiments worked or did not work. Experience again enables you to explore different avenues regarding changes. Total involvement again enables you to ponder why your examinations worked, or not worked at all. Experience and consciousness when combined become path to mastry. To take the full advantage of the agile earlier than you can know the working of agile practices; you have to experience the working of agile methodologies. You should focus on what occurs around you. You should consider what’s going on and, all the more imperatively, why it’s occurring, raise your quires, and do the changes as per requirement. Observe the outcomes; nobody can make you understand how to become conscious about each and everything happening, to gain this you are the only one. Deeper agile values as well as the ideology are the manifestation of XP exercises. At any given time, when your conditions change, utilize the value and standards to guide you in changing your practices. The following are some of the points that can help an organization in mastering agility [1]. © Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0_5

73

74

5 Mastering Agility

• Improve the Process There could be changes that you can implement to get a better process but the effect on the organization should be recognized. Opinions can be used to take benefit— from the coding, from the team, from clients and partners—with this you have an idea of what mechanisms you could adopt and not. You must aware of the events that are occurring in the surrounding. Ask a question why do we need to adopt this practice? Why it works well or isn’t working? You can ask the views of the team members. Each objection may have a valid point so we should appreciate the open conversation. Being a team, consider what has been learned if you discover something new, be a mentor, if you have queries, ask a mentor. Every individual should enable each other to understand what is being done and why. Extreme programming (XP) utilizes an iteration-based feedback mechanism to improve the work. Underlying root cause analysis and reviews can improve the team’s understanding and the use of different agile practices reinforces learning. For instance, coordinating all a whole team gives peers opportunities to perceive and grasp data. This is a strategic feedback, and it can uncover vital issues when something unforeseen occurs. Daily review meetings (sync-ups) and knowledge intensive workspace help in creating an innovative environment. Additionally, practices like retrospective and pair programming spread valuable information in the team. At the point, when colleagues are experiencing work pressure, difficulty in thinking critically and ways to improving their work. Enlivened work and slack reduce that pressure. Pair programming provide opportunity to one individual in each pair time to rethink about the methodology. • Tune and Adapt It is always better to modify the process if there is a need to do so. Do the changes in context with your team; although you may have various teams, it is always right to implement it differently because the requirements of each team are diverse. There is always a scope for tuning. Consider them as tests; make little, confined changes that enable you to comprehend the outcomes. Be explicit about your desires and about the estimations for making a decision about progress. The feedback and learning act as an input to these changes. Utilize the after-effects of your investigations to roll out further improvements. Repeat until you’re satisfied with the outcomes. It is not possible that all the experiments run to success, but a few experiments will fail, and others may really have a bad impact and made the process worse, members of the team should be adaptable and versatile. Agile team needs to have courage to experiment and may face failure sometimes. Changing your process expects you to have an all-encompassing perspective on what you do and why. The newly formed agile team ought to be conscious about making changes in their procedure, there is less probability that they can provide holistic understandability because they have not so experienced. If you have the experience, utilize the feedback from your changes to improve your procedure and comprehension of agility. Tuning and adjusting are implicit in XP; the team should make changes at whatever point if they have a reason to do so. XP teams use reviews and retrospectives for getting explicit views to adapt

5.1 Introduction

75

to the changes. The courage to adapt to changes is not explicitly defined in any agile practice but it is a facet of agile courage value. • Break the Rules Rules are defined for a particular purpose. However, rules are not perfectly applied in every situation. It is necessary to break the rules if traditional conventions thwart your projects to succeed. How would you realize when to break the rules? To begin with, you have to comprehend them and their purposes behind existence. This comes with experience. When you comprehend the rules, practice, and practical idealism: e.g., agile practices and value-based outcomes. Embrace beliefs, but enrich them with practicality. For instance, “We want to avoid integration hell” is a practical outcome that leads to ideals of “we will never check-in the code that does not build or passed tests” with the direction of your principle, question existing traditions. Ask yourself, “For what reason do we pursue this rule? Do we genuinely require it?” Modify, workaround, or break the rule that restricts you from progress. Keep in mind; however, that organizational help is fundamental to progress. It is obvious if you break the rules, you have to face consequences of it. Be prepared to face the challenge and explain your experiments. • Eliminate Waste The requirement of agility is its adaptability and a lean procedure, stripped to its basics. Excess of anything is just wastage of recourses. Eradicate all the excess, if there are fewer things to consider which are essential, you need to do less, your work will take less time to complete, the less it will cost, and the more rapidly you will deliver. Less of it means removal of unnecessary things but you can’t simply remove any practice. What’s essential? How to consider factor which might aides or acts as a barrier for you? What really gets great software to the population who need it? Responding to these inquiries causes you to dispense with waste from your procedure and enhance your agility. “Simplicity is the art of maximizing the work not done” is the common saying of agile community. This thought is vital to eliminate waste, making the process more agile, and doing less. If your procedures do not work, you can’t get an advantage to a great extent from your procedure. As Albert Einstein stated, “Everything should be made as simple as possible, but not one bit simpler.” Many-times, this implies that you should adopt a new approach. Giving up formal structures while expanding thoroughness is a way of improving your procedure. For instance, sitting with clients diminishes the measure of formal necessities documentation you make, yet it significantly builds your capacity to comprehend prerequisites. Communication, feedback, and trust help in generating the solution. Face-to-face communication and feedback lessen the requirement of intermediate deliverables. Self-control is the ways which permit team individuals to work without any overhead of formal structures. Paring down your practices to the responsible essentials and removing bottlenecks lets you travel light. You can boost the time you spend delivering releasable software and improve the group’s capacity to concentrate on

76

5 Mastering Agility

what’s important. An agile methodology helps in eliminating waste, e.g., XP. For instance by having, the team sits together and one-to-one communication; XP eradicates the need of intermediate requirement document. XP avoid composed plan documents by having close collaboration between programmers and incremental design. By reusing extreme programming practices in multiple roles, XP helps in eliminating waste. The advantage of pair programming is that one-person code and the second person review the code simultaneously, yet it additionally extends learning all through the team, advocates self-control, and reduces distractions. Another practice of extreme programming-collective code ownership extends incremental design. • Work in Small, Reversible Steps The work you may need to discard which is useless will automatically lessen your burden of work, a natural remedy to reduce your burden. This implies dividing the work into its small conceivable chunks and checking them independently. One can found many problems and solutions eventually while going through the debugging process. Shotgun debugging is alluring; however, if you attempt a few distinct solutions parallel to fix the error, it is obvious that you may get confused about which solution actually worked for you. A better approach is to build in increments. There is a possibility that you can make changes which may seem optimum, scrutinize, and confirm its effects, and decide whether to retain or rollback the changes. These kinds of approaches help the practitioner to think better and refined results can be achieved. This may seem like making small progressions same as a baby takes, and it is. The nature of code improves if one concentrates around a little part and invests energy and time for the development of that piece before proceeding. These short and fast improvements expand on one another; as the work is done in a careful manner, one seldom needs to undo any changes. In any case, the progression does not work, get the real cause of it and can backtrack a couple of minutes to gain further improvement. If you want to achieve the goal this regular course of rectifications helps [2]. The most common issue of developers is the wish for solving big problems. Ways to maintain a strategic distance from pointless embellishments are provided by pair programming. Further, the guide focuses on the master plan with the goal that the two developers can keep up the point of view of the framework as a whole. The test-driven development is the trademark of the think-test-plan cycle of coderefractor. The successful end of every iteration delivers a steady waypoint at which the whole framework functions as planned; it is a strong checkpoint from where to continue. This checkpoint could be used for system restore at a consistent state. On the higher note, stories restrict the total amount of work to be completed in an iteration. The iteration length can be anything between 2 days and 2 weeks. The size of the iteration to be fixed and consent exceeds the predefined limit. Continuous integration spreads the working code all through the entire group. The project makes continuous progress at a constant pace and incremental design is complemented by refactoring [3]. System is planned in little strides as required. As engineers include features, their

5.1 Introduction

77

comprehension of the adequate and essential design will evolve; refactoring enables them to refine the framework to meet its ideal current design. • Fail Fast It might appear obvious, yet failure is another cause of waste. To abstain from doing anything advantageous is the best way to dodge failures. That is no real way to exceed expectations. As DeMarco and Lister [4] stated, “Projects with no real risks are losers. They are almost always devoid of benefit; that’s why they weren’t done years ago.” Rather than attempting to maintain a strategic distance from failure, embrace it. If the task is certain to fall flat, one needs to realize that as quickly as possible. Find out the approaches and its corresponding data that will enlighten regarding the project’s probability of failure. You must conduct experiments to an area that have probably high risk to check if it actually fails in practicality [4]. The less money and effort is required if you abort the doomed venture as early as possible. Failing quickly applies to all parts of your work, rather than falling late and it’s better to fall fast and early. It liberates you from worrying whether the decision you have taken in positive or negative. In case you don’t know, structure your work with the goal that you uncover mistakes at the earliest. In case you don’t know, structure your work so you uncover blunders when they happen. In the event that it comes up short, let it bomb rapidly, as opposed to waiting in limbo. In any case, contribute just as much time and the same number of assets as you should make sure of your outcomes. With these standards managing your choices, you’ll dread disappointment less. In case of a safe failure, it is ok to get failed. In such cases, you can experiment and take risks. The benefit of this opportunity is, if you have a thought in your mind, take the risk, don’t hypothesize if it is good or not just attempt it. Observe the results, it may flop quickly. This will help you in understanding the root cause of the failure and why this happened. One of the difficulties of embracing XP is that it will in general uncover issues. For instance, planning game, velocity and iterations sparkle the light of truth on projects timeline. This is deliberate: it’s one of the ways XP empowers the venture to flop rapidly. This helps in realizing if your ideal schedule is unachievable. You can alter your schedule or the capacity of the project if the project is yet worthwhile otherwise drops the project. This may appear to be cruel; however, it’s actually only a reflection of the logic behind “fail quickly.” It’s especially disturbing to firms that routinely make an unlikely schedule. At the point when XP fail quick in an organization, fault— not credit—regularly falls on XP. However, dropping a task early is anything but an indication of failure in the XP team; it’s a success. Rather than wasting a huge number of financial and other resources on it, it better to drop it early and saving the valuable resources. • Pursue Throughput In software, the waste is its unreleased software. The effort has put in to develop the software incurred cost; however, still, it has to deliver value. The project which remains incomplete shows unrealistic investment. The project in which investment has not proved any value to the customer is waste in the form of time, cost, and

78

5 Mastering Agility

opportunity. Incomplete tasks likewise harms throughput that is the measure of the time taken by another plan to become meaningful software. The less work done in more time is also a waste. The more it takes to build an idea to meaningful software, more is the probability that some differences in plans will invalidate a portion of the incomplete software. To reduce the percentage of the wasted effort and to maximize the throughput, find a way in the process that can compute the most work waiting to be done. The constraint is the one piece of the process that decides your overall throughput. You can say that often developers are the main restriction in software project development. The distribution of the work among team members depends upon the rate at which they resolve/implement user stories. To maximize throughput, the constraints in the software development process have to work at their full potential while others can keep the same pace. To reduce moderately finished work, non-constraints should produce only enough work to keep the constraint busy, but not so much that there is a big pile of undone work. Undone work has more opportunity costs and greater potential for lost productivity. Limiting incomplete work implies that all others except the constraint are working at less than maximum efficiency. Efficiency can be extended in other activities. Moreover, non-constraint must be given additional time so that the needs of constraints can be responded, and this aid in keeping constraints productive. The product should possibly provide the features, which are required by the customer. This will increase the value of the product. You get valuable feedback from your customer who is an asset for the organization. The feedback cycle helps agile project to deliver early and repeatedly. • Exploit Your Agility When code and procedures are simple then it is aesthetically satisfying. However, there is more other reason for agility creating great software: it improves your capacity to perceive and exploit new opportunities. If you can anticipate in advance the time duration for which the project will take to complete, recognize the risk that may or may not occur and if you can fully eliminate all the surprises that may come during software development lifecycle, this means you do not require agility, any other methodology can work efficiently. But in case you do not know, agility is your answer. Another crisis or cheerful discovery one week from now could totally change the standards of the game. Your client may build up another business practice that saves time and cash or you may find a splendid new procedure that improves your code. It is always advantageous if you could put into action what you have learned and change the course of action accordingly. Adjusting with the situation like changing requirements by client can give great opportunity to deliver the value to the customer, which is the most important outcome of the project. There are various factors, which enable to learn and improve the understanding of the project such as seeking after an opinion from your client, from users, from other colleagues, and from code itself as early and as frequently as possible. It likewise uncovers new probabilities as they show up. Agility requires not to work in big leaps but in small steps. A little effort at the initial stage of the project in terms of time and resources when applied properly can produce quantifiable value. This is most obvious when client plots their requirements at a high level, through stories that need further elucidation during

5.1 Introduction

79

the development of the software. In case of extreme programming one thing, which improves your agility from feedback cycle is ability of the XP to exploit agility by expelling the time between makings a move and observing its outcomes. This is particularly apparent when the entire team sits together [5]. The onsite client enables you to recognize potential misunderstandings and gives almost instant reactions to questions that help in creating features intimately. Including actual users in the process with regular delivery of the code exhibits its present value. XP permits change in short work iterations. If you work in short iterations, running some phases of the development concurrently help in putting the entire lesson learned into the project iterations immediately without waiting for the next round of requirement. • Only Releasable Code Has Value If anyone has written a code which he thinks best, matters only if that code meets customer requirements. It’s evident that the code that addresses client needs has little value except if the client can really utilize it. The product has only potential value until it reaches to the customer that actually needs it. Delivering definite value implies delivering actual software and software that is not releasable has no value. Your growth in terms of software is determined by the working code. It is always possible to pursue the project for a while to check the real-value proposition to the resources invested in the production of the software. Any software development team can alter its focus in a week or in a month: however, would they be able to do as such while maximizing their usage of time and resources to ship software normally? Agility and adaptability are the best things when combined with iterative development. Quality of the code is achieved by a reduction in the waste; not only it provides better feedback but increases the quality of the product. Just code that you can really ship to clients can give real feedback on how well you’re offering some value to your clients. For instance, test-driven development delivers a security net that gives deviations from client prerequisites. A well-performed testing can rapidly recognize faults that can decrease the value of the product. Continuous integration focuses to unclear any mistakes or errors in the early phase of product development lifecycle and makes easy to fix errors early in the development process. • Deliver Business Results Consider the possibility that you could best address your client’s needs without coding product. Would you be able to do it? Value is not generally about programming, overall. The goal of software development is to deliver something valuable to the client. The software is simply how you do that. For instance, agile team value “working software over comprehensive documentation.” Documentation is important for understanding the working of the software however first need is to address your client’s issues. Occasionally, that implies creating great documentation. Typically, it implies shipping good software. The essential objective is dependably to give the most significant business results possibly. To quantify the progress and to make decisions, XP supports close interaction and collaboration customer by inducting the real customer into the development team. Involvement of real client enables the onsite

80

5 Mastering Agility

customer to audit the values proposed by the software with the end user and keep project on tack. The most vital component to the project is their vision which gives answers to the inquiries. It is more imperative for the development team to works on the user stories stated from the customer perspective and verifiable from client testing. After every cycle, the iteration demo demonstrates the team’s status to different stakeholders involved in the product development enabling them to check that the outcomes are significant and to choose whether to proceed with development. • Deliver Frequently At a point, if you have a business issue, an answer for that issue today is substantially more significant than an answer for that issue in a half year—particularly if the answer of the query will remain same as of now and after six months. The value for the business is more than something other than the needs of the customer. It is about delivering what the client needs at when he needs it. Shipping the work product as often as possible makes the product increasingly valuable. This is particularly obvious to deliver valuable software when a client provides the most required stories in the beginning of the project. Shipping working software quickly empowers two essential feedback iterations. First is from real clients to the designers, where clients utilize the product and convey how well it addresses their issues. The second one is from the development team to clients, where the development team imparts by exhibiting the reliability and capability of the software. Clients realize their inclusion in the software development process has a good effect on their work. Software engineers realize that they are helping individuals to take care of real issues. The prime concern of any software is to deliver repeatedly and continuously and must have a value to it, this will help in fulfilling the clients need. It is important to identify early in the development process what is the need of the customer, what makes software valuable, and then the agile practices, e.g., XP practices help in building the valuable software with fast and repeated software releases. By keeping a build, less than 10 min reduce or remove the needless procedural obstructions to deliver. The less work and disappointment, and the more automation, the easier to deliver freshly build.

5.2 Disciplined Agile Delivery (DAD) The procedure that encompasses the entire software advancement lifecycle is an umbrella term is used to acknowledge for best practices of agile approaches. DAD considers the solution through the beginning of the project delivering through the point of release. When you adopt agility, you are most likely going to have a bumpy ride on the way. Therefore, it is vital to collaborate with other agile specialists to motivate people about agile practices.

5.2 Disciplined Agile Delivery (DAD)

81

• People First DAD is cross-functional groups that include cross-functional and self-organizing people. Team members are encouraged to be cross-functional in their skills and work related to discipline other than their expertise. Since teammates increase their understanding, resources are used even more effectively and formal documentation and sign-offs are not so necessary. In agile development, people are pushed out of their comfort zone. Taking on work outside their zones of capacities may not be something they are adjusted with doing. They moreover may be reluctant to surrender the work where they trust they have the most dominance, by clearing out the hierarchy and giving roles that combine cross-functional skill set helps agility with discipline. • Agile Collaboration The successful development of a project relies upon how people behave on the collaboration, connection with peers, and how they deal with their routine activities. Every individual’s activity should be pertinent the project so everybody’s activities must be significant to the setting of the task. Effective communication is always a foundation of agile methodologies. The practices will help to keep everybody included and moving toward the right way together. Face-to-face meeting is always considered as the best way of communication. Next, you need to get everybody in the playing zone. In addition, as all the team members play together, the practice of collective code ownership must ensure that every team member feels the ownership of the code. Refining and improving skills by time help individuals of the team to grow in their carriers. It might happen sometime that you know the answers of a particular thing that may be your teammate does not know. You can help to develop the team along with your development by taking all the team members along with you. Apparently, you have to alter your own coding practices to accommodate rest of the team since you are cooperating in a team. First, it is considerate to share code when it is ready to deliver so as not to hamper your colleagues with half-baked cake. When you are ready with developed code, review it with other colleagues. As the project moves along, you finish your task, and starting the new assignment, you must inform your peers about your progress, issues you’ve faced, and perfect solutions you’ve found [6]. • Schedule Regular Face Time Communication is the utmost importance for the successful completion of projects whether you may despise meetings. In addition, you need to communicate with your clients, yet as well with your teammates. If your colleague has an answer to the quires you are dealing with, you would like to know about the solution as soon as possible, not later? So you surely need to know what others are doing, Stand-up meetings are a powerful method to get the group together and keep everybody informed about what is going in the project. One can guess from its name these are the short meetings and members aren’t permitted to take a seat in stand-up meetings. As you may get too comfortable when you take a seat, and thus, meeting will in general go on forever.

82

5 Mastering Agility

To help keep the meeting focused, everybody should restrain their commitment to addressing these three inquiries: what is being done yesterday? What is to done today and what is coming my way? Every member is given less than 2 min to talk. In the event that you need to examine something more in detail, at that point get together with the suitable individual after the stand-up meeting. The correct timing for holding the stand-up meeting is generally early in the day when everybody is working on their routine task. It should not be planned the absolute first thing; you need to allow everybody to settle down in the office first and then arrange a meeting. It should be arranged in a manner that meeting gets over in time and team gets ample time for development before schedules break. It is obvious to maintain the focus of the meeting throughout so as to remain on track. They need to respond to the inquiries and ought not to get into long exchanges. The administrator writes down the issues to determine and shouldn’t endeavor to coordinate the discussion other than keeping individuals concentrated on the inquiries. These meetings have much to offers and give numerous advantages. They provide a focused perception throughout the day. If a designer is having issues with something, he can bring the issue in meeting and seek help from the colleagues. This helps in determining the area on which concentration is required and to whom depute so that work is done in an efficient manner. These meetings make colleagues aware of the progress of the project. It eventually provides a suggestion if someone is facing a problem and recognize the repetition process rapidly. Team speed is improved by encouraging the sharing of code and thoughts. Completing stand-up meetings requires responsibility and interest from the executives. Moreover, team lead can be instrumental arranging and starting the meetings. At the point, when engineers can’t inspire the board to involve, they can hold a stand-up meeting among themselves casually. Sometimes meetings eat away valuable time from development. This is the responsibility of the moderator to check the time required for the stand-up meetings. Meetings usually take 10–15 min daily. Although smaller teams need not to meet every day as they can always interact in the scheduled breaks, whereas the largest team need more face-toface interactions to keep all motivated and updated regarding issues and development process. Meeting one time in a day, or two times per week, might be adequate [7]. Watch the dimension of details to be reported into the meeting. You have to report overall progress and concrete results that are essential to share in the meeting, yet don’t get into the low-level details of it. Keep the meeting short as possible and try not to sit around ideally waiting for meeting to kick off. If you aren’t working as a team, you may feel the stand-up meeting a total waste of time. • Practice Collective Ownership Any non-trivial application requires combined effort by the team for the creation of the software. In this scenario on one own the ownership of the code, anyone in the team who understands the code can do modifications in the code and others can review it. Sometimes, it becomes very risky in keeping the code exclusively in the hands of a single software engineer. Solving issues and making the application live up to its clients’ expectations could be more important to choose who has the most splendid idea, or, so far as that is concerned, whose implementation stinks. At the

5.2 Disciplined Agile Delivery (DAD)

83

point when various individuals work with code, the code is continually checked, refactored, and maintained. In the event that a fix is required, any of the coder can contribute to complete the work. When one individual can easily work with various pieces of application code, project scheduling becomes easy. Switching of roles in agile development helps the individual in gaining knowledge and improving the team performance as well as allowing the persons to work in different capacities in the development thus improving individual’s throughput. On the other hand, knowing that someone else will be working on the code developed by you, the developer will write code with more responsibility and in a disciplined way as he knows that others will be watching him. You have to be more careful if you know others are watching. It is obvious if one developer is working on a particular part then he will finish that work more easily and efficiently. That is valid, yet in the long-run, you gain benefits by having different eyes at a watching and reviewing the code. It improves the overall quality of the code, it’s easier to maintain and understand, and the errors decrease. The expertise of an individual is a key feature and any team should not accidentally lose them from the team. It is always not possible for one person to have expertise in all the technical fields. If one person is proficient in a particular area it is advisable to keep him as an expert for that particular area and let him expose to the rest of the system. It will become messy in large projects if everyone is changing everything too frequently. Collective code ownership does not mean to hack widely. You don’t have to know everything about all aspects of the task; however, you shouldn’t be frightened off from any part of the system either. There are exceptional events when you don’t need collective code ownership. Maybe the code requires particular, specific domain knowledge with regard to a particular field, for example, in a hard real-time control system. In these cases, you may find that developers with half knowledge can spoil the code. • Be a Mentor Mentor’s job arises when somebody from the team knows more than other teammates. What would you be able to do with this recently discovered specialty?. Overall, you could utilize it to criticize others, criticize choices they make and code they compose, or, you could share what you know, improving people around you. Knowledge grows when given, regardless of what number of individuals shares it, the knowledge never diminishes. When one hear other persons thoughts, he/she gain knowledge without diminishing anything of other. Knowledge has a unique intellectual property, it increases when you work in a team and share your learning’s and experiences with others. Rather than wasting time by explaining what you know, you can have better comprehension of it by yourself. One can get a distinct viewpoint if someone poses you queries. Working with others in collaboration motivates them to improve themselves, which ultimately improves the quality of team. Working with others also let you know the area in which you required improvement. A good mentor accepts notes while offering guidance to other people. Being a mentor does not mean to put entire energy into hand-holding and spoon-feeding of the team members, let they learn in an open environment and learn while doing. Being a coach implies helping

84

5 Mastering Agility

teammates to recognize their distractions and improve their skills just as helping yourself in improving in this process. It does not require to be a heroic act; just a small improvement in the code or explanation related to some work may be valuable to somebody. Being a mentor implies sharing your learning’s and experiences with those who need it. This means increasing value of the team by seeing teammates learn from experience and mentoring. Mentorship is building you and your team members simultaneously. But sadly, the human nature is to climb up the ladder and then see the other down the ladder with disdain. Sometimes knowingly or unknowingly human creates communication barriers with peers. Therefore, others in the team either may start to fear you or might be too uncomfortable to even think about approaching you with queries. No exchange of knowledge will happen in this state. You need to be a guide, not a tormenter. Being a guide is an incredible method to put efforts into your team. Pair programming gives a natural environment of mentoring where navigator can mentor the junior programmer. There may be some cases when some individuals may upset you who are too lazy to find answers for themselves, encourage those people to find the solution themselves. • Share Code Only When Ready What could be more terrible other than not utilizing version control software? The reply is utilizing it wrongly. The manner in which version control is used can influence quality, productivity, and schedule of the product. Specifically, how frequently you check-in your code has a major effect on your software. Rather than holding code with you when you are finished, try to upload the code repository as soon as you have finish with your build. Made it available for others so that it can be reviewed and enhanced. Obviously, the version control should be implemented and checkingin code on weekly basis or monthly means you are not correctly using the version control. You may hear different reasons for such excuses from teammates. Possibly, people put a reason for that, e.g., onsite/offsite, time zone and other related issues that are hindering away the implementation of version control system. It is easier to do the wrong thing than to make the best choice. A simple technical issue should be considered. Then again, what about checking-in the code before you are finished with the assignment? Never made public the half-cooked code. This may be the case you want to return home early and thought to finish the task after dinner. The most effortless approach to get to this code at home is to register it with version control framework at work and look at it when you return home. The code in version control system is an unstable code may be it has compilation error, may have compatibility issues with existing code. This will have an effect on the code of other developers those are fetching latest copy of code. Ideally, you must maintain a log/checklist for the references of the developers related to the tasks/bug that have been fixed so that other developers those are fetching your code can figure out what have been changed and who has changed the code. It works as a guide for them in the future. Furthermore, this kind of atomic commit can be reverted whenever needed. Making a version should encompass the fact that your code should be tested and checked.

5.2 Disciplined Agile Delivery (DAD)

85

Continuous addition of the code ensures that your code in the version repository is in a consistent state. There are generally different stages that your version control framework can differentiate such as “checked-in” and “publicly available.” In this situation, working on the code which is not yet finalized you can use the provisional check-in to avoid the heat from your colleagues of uploading half-baked code (while taking that work to home and office). It might happen that some individuals review your code prior to check-in; it is all fine unless they delay in reviewing the code. • Review Code When the code is written, it is the best time to find errors in the code segment. Capers Jones writes the code reviews are presumably the best approach to find and tackle issues. However, occasionally, it is difficult to persuade supervisors to use this approach, because it’s a time-consuming effort and sometime managers worry about the times it takes as it let the team to stop writing code and indulge in extensive code review meeting. Software developers dread code audits because they feel unsecure by others reading their code. At the point when software engineers in the team finished the coding and start testing of a project, the code is altogether looked into by some other teammate before it was uploaded with version control. Many issues can be fixed in this procedure. Code review does not hold for code developed by inexperienced or junior code developer but as well useful for code developed by senior developers in spite of their experience. In extreme programming developer always code in pair. The code is constantly written in sets: First person takes a seat at the console (the driver), and other individual sits on the back seat of the driver and work as a navigator. From time to time, they switch jobs. In this way, you have a second pair of eyes that acts like a ceaseless code audit; you don’t need to plan any spate time for code review meetings. What is expected from code review meetings? The answer is, you can develop a list of explicit issues to check (all special case handlers are non-empty, all database calls are made inside the extent of exchange, etc), however, there may be a list of issues that you might want to get solved: issues regarding understandability, readability, and errors in the code. The check the unwanted effect of code on the other parts of the software. Has there any duplication of the code (inside this segment of the code itself or with different pieces of the framework)? Code audits need to effectively assess the structure and clearness of the code, not only if the names of the variables and design are consistent with some corporate standard. The style of writing the code may differ from programmer to programmer; this doesn’t mean difference is necessarily worse. Try not to condemn code except if you can improve it quantifiably. If you cannot follow up with recommendations of code reviews, then there is no point to waste resource on this activity. Try to end the iteration on code analyses; let everybody know the different steps that have been taken after review. • Keep Others Informed Every task has deadlines that must be followed by the developer when he/she has taken the task. But due to unavoidable circumstances and problems you might lag

86

5 Mastering Agility

the schedule. The due date approaches and on the demonstration day, it is expected from you that you will present the work in the meeting that is not yet completed. It’s not beneficial for your professional carrier. Rather than waiting till the deadline to convey to the management team that the task has not been finished yet, you can consult someone else about your problem there is a possibility that you get the desired solution to your problem before the schedule. Possibly, they can request that another engineer help to you out. They may also depute another individual who has a sound knowledge about that particular part of the code. By keeping others in touch with you may reduce surprises. They realize when to lend you with assistance, and you’ve earned their trust. There are various methods to keep individuals in touch, e.g., email, message on a sticky note, or a telephone call. Moreover, one can utilize what Alistair Cockburn calls “data radiators.” It is similar to a poster pasted on the wall, visible to whole team, which is gradually changing by the passage of the time. By pasting the data at them, you dispense with the requirement for others to make inquiries. Data radiators show the advancement you are making on your task and any other data of any importance to the team, managers, or clients. The best place for the poster is where it easily accessible for each individual. The entire team can utilize data radiators to communicate their status, code plans, cool new thoughts they’ve explored, etc. [8]. Presently, just by strolling around you can get more intelligent, and your managers will know precisely what’s going on. The daily stand-up meeting also helps us to informed status, bottlenecks, and issues of the project to the team members. It encourages stay up with the latest information available at high level. It is necessary for the presenter when displaying status, to ensure the dimension of detail is proper for viewers.

5.3 Agile for People Agile places emphasis on people factor for its successful completion. These skills include sociability, talent, skill, and communication. These are the most important inferences to the managers working in agile methodologies. Agile values would be primary concern for the teams implementing agile. Skill improvement is vital, so that each member of the team bring value by time. The attention to the social issues gives a feel to agile projects [9]. It is not just reducing the paperwork and believing that every other thing will automatically fall in place. To paraphrase one developer, “A small and rigorous methodology may look the same as an agile methodology, but it won’t feel the same.” The agile concept grows to span teams, organizations. It may prove problematic for people with agile mindset to function well in a rigid organization and vice versa.

5.3 Agile for People

87

5.3.1 Individual Competence Individual competency is valued as a critical success factor by agile development teams. If team members of the project are competent enough, they can use virtually any process to complete the task, on the other hand, if they are not good enough at competence level then no process can repair their inadequacy. Inadequate support can keep even competent teams from completing the task. The “CHAOS Chronicles Version II,” [10] a Chaos Report from the Standish Group outlines items that can enhance the success rate. The first three items include administrative support, user participation, and experienced project management. However, it is likewise correct that the software engineers cannot succeed in the development of the system if they lack the basic competency for the job. For problem-solving people working in groups with good communication and integration, can operate at higher level of intellect than working individually using their personal talents. Therefore, the agile project team’s emphasis on team collaboration and face-to-face communication. Extending ideas in the group brainstorming meetings help the team in developing a new more refined value-driven solution. In traditional development, rigorous processes are designed to standardize people to the organization, while in agile processes are designed to capitalize on individual and team’s unique strengths. Each process is selected, tailored, and adapted as per the need of a project team. Often software development process and rigorous process supporters confuse process and competence. Process gives you framework to the team to work together in a direction, but it can not overcome the lack of competency, on the other hand, competence can be overcome vagaries of a process. When we look under the umbrella term of agile, it covers XP, Scrum, adaptive software development, crystal methods, feature-driven development (FDD), or dynamic systems development methodology (DSDM), and all these methodologies underline the emphasis on people and their talent, skill, and knowledge. This is a competency attitude, not an elitist one. The goal is to work in close collaboration to improve the knowledge and skills of the individuals—whether it is the practices of pair programming and mentoring in XP or chief programmers and inspections in FDD.

5.3.2 Team Competence Agile is characterized by self-organizing teams and collaborations in intra and interinstructional boundaries. Do not get confused; self-organizing teams are not without leader. These teams can organize themselves in various configurations to meet the unforeseen challenges. Agility needs teams to have a shared focus, mutual trust, and respect, Agile teams work in collaboration but have a speedy decision-making process and ability to deal efficiently with ambiguity. There is a difference between collaboration and communication. Where communication is passing information

88

5 Mastering Agility

among different stakeholders, collaboration is actively working together for the successful delivery of the work product. For example, in DSDM manual, differences between traditional and agile managers have been identified: “A traditional project manager will normally focus on agreeing to a detailed contract with customers about the totality of the system to be delivered along with the costs and timescales. In a DSDM project, the project manager is focused on setting up a collaborative relationship with the customers.” Software developed with Scrum methodology daily has an intense 15–30 min meeting dedicated to issues raised during the iteration. Project teams are given the accountability for the delivery of the product, while groups like project offices, process management, and data administrators are given decisionmaking power. In order to innovate and respond to change agile teams are aligned toward accountability and responsibility.

5.3.3 Build Effective Relationships Software cannot be developed in isolation unless you are making software for your own use. You need to work with others in collaboration and efficiently. This means forming solid working relationships that are built on honesty, trust, cooperation, openness, and mutual respect. This kind of relationship cannot be forced, and agile methods can provide support to building solid work relationship. For instance, engendering healthy interaction can be created by encouraging team members to sit together and collaborate in pursuit of shared goals; unfortunately, it is easier to craft the process that discourages healthy relationships. Few examples to justify this claim are: Forcing software developers to communication with customer through business analysts only. Another example, damaging programmer/tester relationships by insisting them to communicate with each other through the bug-tracking system. Blame-oriented cultures also damage trust in a relationship. Collaboration and evading practices that fuels mistrust among team members. Instead of compelling customer to sign the requirements document, work with client for identification and clarification of the requirements and review progress iteratively. Rather than pushing developers not to produce any bugs while developing the software and testers to make sure that all the bugs have been found, both testers and developers must work together to ensure that customers don’t find any bugs [11]. It is easy for technical persons to get caught up in the details of a solution. Encourage collaboration and investigation while respecting the distinction between ideas. • In Practice Though no process can guarantee effective relationships, practices of XP support in enabling effective relationship between team and customer. One common example is the use of a cross-functional team at workspace. Team reaches out to the customer by weekly iteration demo meetings. XP stresses at the importance of including real customers in the process. Agile practices, e.g., stand-up meetings, collective code

5.3 Agile for People

89

ownership, the planning game, and pair programming help in reinforcing the idea that team members are working together to achieve common goals. • Beyond Practices Agile recommends colocated and face-to-face communication so that a solid foundation of working relation can be established. Yet some teams cannot sit together. How to deal with this distribution? One solution arises in mind is communicate virtually, but this has led to some challenges. For instance, if one software developer has an abrupt communication style, and this can lead to friction between the colleagues who haven’t met him personally and assuring him to be a rude person. May be this is because that person is not English-speaking person and is laconic by nature or it wasn’t personal, but rather an artifact of his cultural background. This kind of problem can occur in distributed teams. It is easy to assume the worst about somebody’s motivation when you cannot talk face-to-face. To minimize the occurrence of these problems, it is encouraged to meet in person as often as possible. If conducted effectively virtual meetings can help in understanding the progress of the team and on what task everyone is working. These meetings contribute to cohesiveness and shared direction and curtail unhelpful tangents. A distributed team most of the times faces communication and collaboration challenges, therefore, it’s important to address these issues and make changes that enable work and communicate better. Let the people having the right mindset to do the right things. A functioning team will not work efficiently unless the right people having a diverse range of expertise working well together. Once likeminded people have been found, trust them to do their jobs. Rather than creating a procedure that protects enterprise from its personnel, create a process that enables team members to excel. Let the team self-organize itself as they are experts in their fields that’s why they are hired. Trust them, and back up that trust by giving them authority over the project’s success. Contrary, if you do not have faith in team capability this means you don’t have hired right set of people. It is also important to share that no one is perfect, team as a whole can be trusted for results. Within the team, anyone can be a leader. Team members can be encouraged to ask person to make a necessary decision, for example, decisions related to design can be taken by senior programmers similarly experienced businessperson can take decisions. Leadership doesn’t mean pounding on the table or shouting, “I’m most senior, so we’ll do it my way!” Leadership comes by leading. If the team thinks you’re most qualified to make a decision, they’ll follow your guidance. If not, don’t act as if you have authority over them, even if you think you do. Managers, rather than telling the team what to do, let the team tell you what they need you to do to help them succeed.

5.4 Conclusion Agile is an umbrella term used by different mythologies for managing projects that can be used for virtually anything. Though, it was founded in software development

90

5 Mastering Agility

and now has been adopted by many businesses. Rather than stalling on development because the planning has not been perfect, or putting a product into production before it is ready, use agile methodologies to help guide you along the way. Developing value-based, quantifiable objectives and drive to several, sequential, and quick production releases are key to success. His method can swing production into the right track without wasting the funding and product. “Just enough” planning and shipping in small, frequent increments help team to collect feedback on each change and integrate it into the future. But it’s not just a numbers game agile is all about people. As described in the agile manifesto “customer and collaboration upon process and tools.” Collaborating with clients and team members is more important than predefined tools and delivering a working software in parts is more important than detailed documentation. The key to doing agile right is embracing a mindset of continuous improvement. Experiment with different practices and have open, honest discussions about them with your team. Keep the ones that work and throw out the ones that don’t.

References 1. Adanza, F. (2015). Best practices for scaling software agility in large enterprises. Available https://www.getzephyr.com/insights/best-practices-scaling-software-agilitylarge-enterprises. Accessed 11.11.2018. 2. Cockburn, A. (2006). Agile software development: The cooperative game. London: Pearson Education. 3. Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. London: Pearson Education. 4. DeMarco, T., & Lister, T. (2013). Waltzing with bears: Managing risk on software projects. Boston, MA: Addison-Wesley. 5. Layton, M. C., & Ostermiller, S. J. (2017). Agile project management for dummies. New York, NY: Wiley. 6. Rigby, D. K., Sutherland, J., & Noble, A. (2018). Agile at scale, Harvard business review. Available https://hbr.org/2018/05/agile-at-scale. Accessed 20.02.2019. 7. Barton, D., Carey, D., & Charan, R. (2018). One bank’s agile team experiment. HBR. Available https://hbr.org/2018/03/the-new-rules-of-talent-management#onebanks-agile-team-experiment. Accessed 01.01.2019. 8. Cockburn, A. (2017). Origin of the term information radiator. Available https://staging. cockburn.us/origin-of-the-term-information-radiator/. Accessed 5.11.2018. 9. Rigby, D. K., Sutherland, J., & Hirotaka, T. (2016). Embracing agile—Harvard business review. Available https://hbr.org/2016/05/embracing-agile. Accessed 22.12.2018. 10. The Standish Group Chaos Chronicles Version II, 2001. 11. Cappelli, P., & Tavis, A. (2018). HR goes agile, HBR, March–April 2018. Available https:// hbr.org/2018/03/the-new-rules-of-talent-management. Accessed 21.12.2018.

Chapter 6

Developing and Fostering Smart Ecosystems

6.1 Introduction Dr. Ashok Chitkara and Dr. Madhu Chitkara have been passionate teachers for many years. Later, they became the founders of Chitkara University. In this chapter, we discuss their efforts that turned this university into one of the best universities in India. Their vision to outline these innovations, aligned with a multifaceted and research-based curriculum, led to a set of methodologies, which helped to establish the Institute of Engineering and Technology. Further, this chapter discusses the advantages of the Chitkara trimester system that optimizes the training resources. The Virtual Environment 3DEXPERIENCE is another innovative strategy incorporated in the trimester system [1]. This technology provides opportunities for students to take part in extracurricular activities beneficial for the society. Afterwards, the chapter describes the Chitkara international collaborations, programs, the Punjab Government Education Policy, and its attempts to improve the quality of higher education and employability in the state. Eventually, Chitkara University became one of the best universities for placements in the Punjab region of India [2, 3]. The following part of this chapter examines Innopolis University, which is a part of a master plan to build a smart city called Innopolis. This university is located in the Republic of Tatarstan. Innopolis is going to become the first Russian city for information technology professionals and its future IT capital. The strategy of this university is to produce graduates that have excellent knowledge of information technology, thus making this smart city a thriving one. The chapter presents Innopolis and gives a brief outlook of the present day of this university. It focuses on the curricula and international cooperation. Students in Innopolis University are housed in comfortable and affordable apartments with ultra-modern facilities. The application process to this university is uniform and straightforward. © Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0_6

91

92

6 Developing and Fostering Smart Ecosystems

Finally, the chapter explains the benefits that the students get from studying in each of the universities and analyzes both ecosystems in a comparative study.

6.2 Case Study: Chitkara University Research and Innovation Network (CURIN) 6.2.1 History and Achievements In 1998, Dr. Ashok Chitkara and Dr. Madhu Chitkara (Fig. 6.1), after being passionate teachers for over 40 years, founded a private school, named Chitkara International School, located in Chandigarh, Punjab, India. Their background and expertise enabled them to create this unique training system that blended intellect, innovation, research, collaboration, and global industry connect. The formidable perspectives and combined action of students and faculty made Chitkara a dispenser of smart and inspiring education with innovation and research as paramount ingredients. Dr. Ashok and Dr. Madhu had a strategy and vision of founding the Chitkara Education Trust that comprised a kindergarten, high school, and the university. As launching all of these together would require excessive budget and labor, they decided to commence them one by one, thus conquering the crisis of complexity. Furthermore, they wanted the best infrastructure and educational system to not only compete in Punjab, but also be recognized in India. The major challenges were to become the favorite among local universities in Punjab and attract students and faculty in India and worldwide [4–6]. Punjab, located in North India, due to its bordering with Pakistan, is known as a relatively unstable state; however, it is well known for education. After successful launch of the Chitkara International High School, the innovative vision included a research-based curriculum. In liaison with Chitkara University, the school’s course of study was constructed to foster future employment and ingrain

Fig. 6.1 Dr. Ashok Chitkara and Dr. Madhu Chitkara

6.2 Case Study: Chitkara University Research and Innovation …

93

Fig. 6.2 Chitkara ecosystem: campus locations

the spirit of entrepreneurship. The research at Chitkara ecosystem promoted such advanced methodologies of pedagogy as enquiry-based training, blended learning, flipped classrooms, interdisciplinary methods, and the innovative Tek 8 modules, which included household applications, mobile development, electronics, computer science, robotics, sustainable energy, and automobile technologies. Thus, the students were engaged into a training environment filled with a synergy of learning practices. Next, the Trust applied the same “divide-and-conquer” strategy to the university (one faculty at a time) starting with the Institute of Engineering and Technology. Again, the main purpose was introducing new methodologies and a digital educational system with low budget and high quality to admit the most creative students. Chitkara sought an innovative academic system, using the facilities that would involve more students and faculty. The project started from scratch, and the complete infrastructure was to be established. This involved a very high capital expenditure. One innovative way to cut down this expenditure was to reduce the number of similar laboratories and improve their equipment. This approach would fit the courses without prerequisites (Fig. 6.2). • Trimester System The trimester system helped in applying the rotational concept of laboratory utilization, and resulted in resource optimization in the crisis. This system involved teaching for 44 weeks during an academic year [7]. The remaining eight weeks were devoted to vacations: three one-week breaks at different intervals, and five weeks of vacations after the fourth trimester. After a one-year pilot run, the following updates of the system were suggested: (a) Each academic year has three trimesters, 13 weeks each. (b) In each trimester, 11.5 week period is devoted to teaching, and the rest is for examinations. (c) The amount of teaching hours per week is constant (i.e. 35 h). (d) At least five courses are offered in each trimester. Out of these, four courses would be core engineering courses, and one would be a general course. Each

94

6 Developing and Fostering Smart Ecosystems

Fig. 6.3 Graduation ceremony

core course has 5–7 h of teaching per week. Thus, total time for teaching a core engineering course is 57–77 h per trimester. (e) Continuous evaluation system includes weekly quiz tests, midterm tests, regular assignments, and seminars. This system gives some breathing time to the faculty, and facilitates research and faculty development activities (Fig. 6.3). The benefits of using trimester system at Chitkara University are as follows: – The management of Chitkara University is confident that the new system would retain the advantages of the four-trimester-a-year model ensuring that the students are “industry-ready” when they successfully graduate. – Students are trained to work according to a tough schedule and meet stringent deadlines as practiced in the industry. – Superimposition of advanced pedagogical techniques and reduction in the number of courses ensure a better focus and comprehension. – The system facilitates optimal utilization of resources to manage financial and human-related crises (Fig. 6.4). Another strategy was to provide students with a multi-disciplinary education while encouraging initiative and entrepreneurship through projects and contest-based learning. They came up with an idea of 3DEXPERIENCE [1]. This student-centric approach has made Chitkara University one of the renowned private universities in Northern India. In addition to studies, they encourage their students to participate in extracurricular activities with special focus on those that benefit the society. The university management believes that innovation and entrepreneurship are essential to the success of every business, originating in school. Therefore, they created the on-campus “Innovation Box” to facilitate the student ideas for projects and inventions.

6.2 Case Study: Chitkara University Research and Innovation …

95

Fig. 6.4 Classroom: during lectures

The university professors have made the teaching system an innovative experience. They illustrate designs and simulations in a digital environment to show how products evolve from concepts and early sketches to operational prototypes and implementations. It is very motivating for students to see practical ideas coming to life [8]. • Chitkara collaborations Perhaps, the main concern of all students globally is their job opportunities after graduation. Since Chitkara University focuses on market-oriented learning and practice, multiple organizations regularly participate in on-campus recruitments, with intention of introducing the best talents to the market. The main challenge that Chitkara faced with their earlier talent assessment choice was the issue of cheating. They were looking for a platform with secure and easy to use proctoring capabilities. Implementing the HackerEarth Recruit system was the solution for this problem [9]: – HackerEarth Recruit had a simple interface that was easy to navigate. Tests were created in five simple steps, and multiple students were invited to take a test via email. This talent assessment platform also offered automated evaluation of programming problems. – Chitkara created various types of questions and saved these in their custom library. There was no restriction on the number of questions created and saved. The questions were reusable in other tests. – The approach was section-based; that helped the two units of Chitkara ecosystem (located in Punjab and Himachal Pradesh) to conduct tests simultaneously. By using sections, each unit could test the students with a different mix of questions. – Advanced proctoring mechanism with an IP filtering feature helped to restrict the tests to specific IP addresses only. Therefore, the applicants were unable to access the tests from unauthorized IP addresses. This brought cheating down drastically. – The platform provided detailed reports, helping Chitkara to assess the strengths and areas of improvement of their students. Reports were also downloadable in PDF and Excel formats, storable in a knowledge base, and sharable with the students.

96

6 Developing and Fostering Smart Ecosystems

Concerning Chitkara internationalization strategy, the ecosystem is working toward building a knowledge-based society. Therefore, internationalization and globalization are important assets to realize this vision. This approach has a strong impact on student and faculty exchange programs, which leads to research collaborations [4, 6, 10]. • Punjab Government Education Policy To improve higher education at Punjab, the state government undertook multiple initiatives. These included: – Promoting private participation in higher education; the Private University Bill of 2014 set up Rayat Bahra University and GNA University. – Providing scholarships to talented students: in 2013–2014, the government launched a scheme worth |150 M (Indian rupees, which is nearly GBP 1.5 M) in scholarships to support higher education for the students scoring 80% and above in their matriculation examination. – Enhancing employability: The Punjab Skill Training for Employment Potential (P-STEP) initiative to increase the employability of graduates with the help of the IT and knowledge-intensive industries. The program included training in communication, core IT, and “soft” skills. These were mission-critical in the crisis of the new ecosystem rapid development. Consequently, Punjab became an important market for the recruitment of Indian and foreign students (Fig. 6.5 and Table 6.1).

6.2.2 Chitkara Structure and Projects Chitkara Educational Trust ecosystem established its Punjab campus 30 km (around 20 miles) from the city of Chandigarh. Later on, in 2010, Chitkara University was established by the Punjab State Legislature under “The Chitkara University Act”. The university is known for their hands-on curriculum, which allows students to design and construct all-terrain vehicles; design, build, and load steel bridges; produce computer animations and video games; harness the solar power to race cars that they design, build, and test. At Chitkara University, primary importance is given to practical application of the skills mastered to gain experience from day one; this goal is supported by their mission and vision [4]. Vision: – To be a globally recognized organization promoting academic excellence through interdisciplinary applied research, and to expand realms of knowledge through innovation,

6.2 Case Study: Chitkara University Research and Innovation …

97

Fig. 6.5 Punjab location in India

Mission: – To carry out the academic process for achieving excellence through active teacher– student–industry participation, – To promote research, innovation, and entrepreneurship in collaboration with industries and laboratories, – To establish high moral, ethical, and professional standards among the students, – To contribute to building a skillful society. Currently, the university campuses are located in and around the city of Chandigarh. However, the students come from all parts of India to become a part of the Chitkara family. Their global connections get stronger as they collaborate with leading universities and education providers across the world [6]. • Overview of Chitkara Education Trust Initiatives Chitkara University—Punjab

Institution

Indian Institute of Science Education and Research, Mohali

Indian Institute of Technology, Ropar

2

3

Panjab University

Punjab Technical University

Punjab Agricultural University

PEC University of Technology

4

5

6

7

State institutions

National Institute of Pharmaceutical Education and Research

1

Central institutions

No.

Table 6.1 Universities in Punjab

1921

1962

1997

1882

2008

2007

1991

Year of est.

University

University

University

University

Institute

Institute

Institute

Type of institution

Engineering

Agriculture

Technology and management

All faculties

Engineering

Science

Pharma

Fields

(continued)

Collaborative research, student and faculty exchange are areas of interest for collaboration

NA

Interest in twining programs and student and faculty exchange programs

Interest in student and faculty exchange programs and research initiatives

The institute is looking for partnerships for faculty, student exchange, and joint research initiatives with the reputation of the institute being primary in their list of requirements

Seeking partnerships based on the research interests of faculty and students

Interest in student exchange collaborations for training on new tools and techniques, and faculty exchange programs for curriculum development

Opportunities

98 6 Developing and Fostering Smart Ecosystems

Institution

Chitkara University

Lovely Professional University

8

9

State institutions

No.

Table 6.1 (continued)

2005

2010

Year of est.

University

University

Type of institution

All faculties

All faculties

Fields

Keen on collaborating in student exchange, faculty exchange, research and curriculum development

Interest in collaborations in student, exchange, faculty exchange, and research in areas including health care and architecture

Opportunities

6.2 Case Study: Chitkara University Research and Innovation … 99

100

6 Developing and Fostering Smart Ecosystems

Offers world-class graduate, undergraduate, post-graduate, and doctoral programs at: • • • • • • • • • • • • • • •

Chitkara Business School, Chitkara University Institute of Engineering & Technology, Chitkara College of Applied Engineering, Chitkara School of Planning & Architecture, Chitkara School of Art & Design, Chitkara College of Sales & Marketing, Chitkara School of Banking & Financial Services, Chitkara College of Hotel Management & Catering, Chitkara School of Hospitality, Chitkara School of Culinary Arts, Chitkara College of Pharmacy, Chitkara School of Health Sciences, Chitkara School of Mass Communication, Chitkara College of Education, Chitkara Polytechnic.

Offers doctoral programs in: • • • • • • • •

Business Management, Computer Science & Engineering, Electronics & Communication Engineering, Mechanical Engineering, Pharmaceutical Sciences, Applied Sciences, Health Sciences, Education.

• Chitkara University Initiatives and Research Program 1. Research opportunities at Chitkara University are available through Chitkara University Research and Innovation Network (CURIN) as the students, staff, and researchers work across disciplines to extend the boundaries of knowledge. 2. Chitkara University Centre for Entrepreneurship, Education and Development (CEED) provides a conducive environment for the students to develop a mindset of being an entrepreneur. At present, more than 40 startups successfully function in the state-of-art incubators of the ecosystem. 3. Chitkara University National Excellence Awards established the excellence award as an endeavor to acknowledge and reward the exceptional work and contribution of innovations from different spheres toward education and society. 4. The university, in collaboration with companies, received a number of funded projects in research and innovation, where students and faculty contributed as researchers.

6.2 Case Study: Chitkara University Research and Innovation …

101

The trimester system devised by Chitkara University has been tried out for several consecutive academic years and refined to ensure that it meets the university goals. It was enthusiastically accepted by the students and the faculty. Hopefully, this promising approach would be followed by other engineering institutes shortly [6]. Within the recent decade, most of Chitkara University academic programs were ranked among the top 50 in the country, which is an evidence of academic heritage, committed faculty, industry collaborations, international connections, and campus facilities. Using the 3DEXPERIENCE platform, Chitkara students design and simulate their projects in a virtual environment. This provides an advantage to test the feasibility of their ideas and prepare their products for manufacturing. In recent years, these innovations resulted in several successful commercial products based on the creative ideas of the Chitkara students and faculty [6, 10] (Fig. 6.6). Due to strong industry relations, in 2016 Chitkara became one of the top Punjab universities. At that time: – 124 companies came on-campus to hire the engineering students. – Out of the batch of 992, over 20% of the students won “Dream Job Offers” from world-leading companies such as Amazon, HP Labs, Toshiba, and Cisco, to name a few. – For the Mechanical Engineering Department, the major partnering companies included Honda, ISUZU, Yamaha, Tata Technologies, and Coca-Cola (Fig. 6.7). Let us summarize the outcomes of Chitkara’s international collaborations:

Fig. 6.6 Student working environment

102

6 Developing and Fostering Smart Ecosystems

Fig. 6.7 Student initiative project

– Faculty and student exchange programs with more than 50 educational organizations, including Purdue University, University of Florida, Sciences Po Lille, and China Medical University, – Joint degree programs and twining arrangements with 15 educational organizations from the USA, France, and Canada, – Curriculum development programs with educational organizations including Anglia Ruskin University and Institute D’Etudes Politiques De Toulouse, – Curriculum development in degree courses such as those offered by the School of Health Sciences in collaboration with Fortis Healthcare, – Industry links with major companies including CISCO, Ericsson, Dassault Systems, National Instruments, and Oracle for training, internships, and placements, – Internationalization by events, such as biannual Global Engineering Week, featuring an annual Global Business Week. These factors made Chitkara one of the leading Indian universities, known worldwide. Its main Indian competitors are Amity University, Sharda University, and LPU. Recently, Chitkara University had revenues of around $1.6 M, and over 160 employees. As of 2017, the university had over 150 K followers on Twitter.

6.2 Case Study: Chitkara University Research and Innovation …

103

Table 6.2 Punjab International Collaborations Country

Collaborations

UK

• Lovely Professional University (LPU) has tie-ups with UK universities such as the University of Sunderland, the University of East London and Thames Valley University • Chitkara University has a tie-up with Glasgow Caledonian University • Panjab University has a tie-up with CERN as part of the ALICE collaboration

US

• Punjab Technical University (PTU) has signed an MoU with the University of California, Santa Cruz (UCSC) to set up an Institute of Excellence (IOE) at Chandigarh • LPU has tie-up with Troy University, Washburn and Iowa State University • Punjab University (PU), Chandigarh has been selected by the Government of India as the agency for Indian Institutional collaboration with US institutions in research on neutrino physics

Canada

• The Punjab Government has invited Canadian institutes to establish education and healthcare institutions in the upcoming Educity and Medicity in Chandigarh • The Government of British Columbia has opened an office in Chandigarh. The aim of the office is to promote joint research and development

Australia

• The Australian Centre for International Agricultural Research has funded research programs in Punjab on improving crops, cropping systems and economics • Australian and Indian scientists from CSIRO and the Institute of Microbial Technology, Chandigarh have collaborated on developing a tool to diagnose tuberculosis

According to the strategy of the Punjab Government, this state is an important market of student recruitment. The four major destinations (Table 6.2)—the USA, the UK, Australia, and Canada—have their education promotion offices in the state. The leading four education consultants have ten offices in the state, which is 12% of their Indian offices [6, 10]. • Hydroponics Greenhouse Farming: Chitkara University’s Environmental Startup “Go Green” is the motto of ventures globally. Chitkara University as a brand has always been the front-runner in innovation and entrepreneurship. Hydroponics is a method of growing plants without soil, using mineral nutrient solutions in a water solvent. Terrestrial plants grow with their roots exposed to the mineral solution, or supported by an inert medium, such as perlite or gravel. Chitkara developed this 100% computer controlled greenhouse and currently offers it to customers as a business proposal ready to operate (Figs. 6.8 and 6.9) [11].

104

6 Developing and Fostering Smart Ecosystems

Fig. 6.8 Chitkara greenhouse interior (detailed view)

Fig. 6.9 Chitkara greenhouse interior (general view)

6.3 Case Study: Innopolis University and Ecosystem • Background The University of Innopolis is a part of the plan to build a smart city with the same name. The city comprises a set of institutions and infrastructure objects. Among

6.3 Case Study: Innopolis University and Ecosystem

105

Fig. 6.10 City design plan

them are ultra-modern facilities for education, business, healthcare, conferences, and sports. The University of Innopolis forms the hub for IT training, job creation, and recruitment. Figure 6.10 presents the design plan for the city of Innopolis with these innovative and hi-tech structures that ensure intelligent use and recycling of the smart city resources [12, 13].

6.3.1 Timeline The Innopolis city was launched in 2012. Subsequently, training of the students at the University of Innopolis started in 2013. In 2015, the smart city was officially founded, and in 2016 the Lyceum high school was launched. The following sections provide more details on the project milestones. • Launch of site In June 2012, Medvedev, the Russian Prime Minister, with other prominent officials, laid a capsule with a message to the future residents at the launch site of the city (Fig. 6.11). Later in 2012, Liu Tai Ker, the Head of the Singapore Planning Department, produced the Innopolis design plan; this is a model for many modern cities in the world. Innopolis is located in the Republic of Tatarstan, at the confluence of two rivers, the Volga and Sviyaga. This is the first Russian city for IT professionals. The concept of smart city helps Innopolis to organize the infrastructure, business, education, city services, and make life of residents comfortable. Three years later, in 2015, the official start of the new city was given [12]. The city of Innopolis, as captured on Yandex map, shows how its design was implemented (Fig. 6.12).

106

6 Developing and Fostering Smart Ecosystems

Fig. 6.11 Innopolis opening ceremony

Fig. 6.12 City of Innopolis on Yandex map

• University-as-a-hub strategy In 2013, the University of Innopolis began its program of study. This was the commencement of a smart city. The goal was to produce graduates with advanced knowledge of IT to attract leading world experts and multinational companies to this smart city [13] (Figs. 6.13 and 6.14). In the Lyceum, teenagers of grades 7–11 study. The Lyceum program is designed for in-depth study of physical and mathematical disciplines.

6.3 Case Study: Innopolis University and Ecosystem

107

Fig. 6.13 University of Innopolis: lecture hall and the campus

Fig. 6.14 Opening of Innopolis lyceum

• Contemporary Innopolis As of 2018, Innopolis reported over than 3000 inhabitants; 150 companies were registered, of which 76 were the city residents. Innopolis leased over 12,000 m2 of real estate. The ecosystem infrastructure comprised 16 residential houses, a kindergarten, a school, an IT Lyceum, medical and sports centers, a post office, banks, supermarkets, a beauty salon, a car wash, a cafe, a bar, and other services. In 2018, the next stage of rental housing for 730 apartments was delivered [14].

6.3.2 The University of Innopolis The University of Innopolis provides education and research in the fields of IT and robotics. At the University of Innopolis, there are professors and researchers from the best world universities, such as the Carnegie Mellon University (USA), the Swiss Higher Technical School in Zurich, the National University of Singapore, the University of Amsterdam (Netherlands), the Korean Institute of Advanced Technology, and Institute EURECOM (France). The university applies the best educational practices and creates its own methodology.

108

6 Developing and Fostering Smart Ecosystems

The specificity of the University of Innopolis attracts industry experts, thereby ensuring continuous update of courseware. The university has 13 research laboratories and 4 research centers. Students and graduates of the University of Innopolis are engaged in advanced research and new developments under the guidance of eminent professors and experienced research associates, in close connection with the industrial partners. The programs of the University of Innopolis imply an intensive combination of fundamental and practical courses, and project practice with the leading IT companies from the early stages of training. University of Innopolis is created exclusively in the interests of business. Industrial partners participate in the forming and adjustment of the educational programs, selection of research directions, admittance, internship, and further employment of students. Innovative lectures and group work help focusing on deep, hands-on learning approaches. In the sports facility, there is a swimming pool, gyms, and playgrounds for the instructor-guided group and individual training. In spacious rooms of the four residential buildings, there is everything required for comfortable living. Key facts and figures about the Innopolis University (as of 2017): – – – – – –

Over 600 students, 13 research laboratories and 4 centers, Over 20 academic partners around the world, 45 grants (of approx. USD 10 M), Over 1 billion Russian rubles (or approx. USD 150 M) in sponsorship funds, Over 80 professors and researchers from the world top universities and leading IT companies.

• Innopolis approach The university runs bachelor, master, and post-graduate programs. It hosts international conferences and trains professionals in specific areas to acquire the extra skill and capacity to improve their prospects and career. The university also carries out research in collaboration with the industry partners. Innopolis ecosystem facilitates and encourages commercialization of its R&D projects.

6.3.3 Programs The university runs a Bachelor and Master programs in the fields of software engineering, computer science, and robotics. It also has shadow programs and research training opportunities for information technology-oriented students. Students who intend to undertake their post-graduate programs can easily find support and supervision in their research field given the close association of the university and industry as far as cutting-edge technology is concerned.

6.3 Case Study: Innopolis University and Ecosystem

109

• Bachelor program This program is designed by world-class experts in computer science, robotics, and software engineering working in conjunction with representatives from the research community and IT companies. The program duration is four years (i.e. eight semesters). In the first two years of studies, the students take core courses in software engineering and computer science. In the final two years, the students can select electives considering their specific degree plan, such as artificial intelligence, software engineering, robotics, game development and applications, or data science. Most courses feature team-based software development. Some courses contain research under supervision of laboratory team members of the Innopolis University. The curriculum includes 32 weeks of internships in leading IT companies, innovative startups, and research laboratories. • Master program This master degree program was designed by top curriculum developers in collaboration with renowned researchers and best IT professionals. The program duration is one academic year, and another year of internship. The program is designed for those who have at least one and half year of experience in the computer science and the related fields, and desire to master state-of-the-art techniques in big data and data science areas. During the program, students are offered six core courses and various electives, which broaden their knowledge and application areas. Most of these courses are project-based, enabling students to apply the theory and methods studied to real-world problems. Upon completion of the program, successful students become data scientists, who process datasets, apply algorithms, and analyze, visualize, and report results. • Post-graduate This program is designed for young scholars having R&D experience in IT, whose scope of research interests is computer science. The program consists of four units: General and Special Subjects, Scientific Research, Teaching Internship, and Research Internship. The Scientific Research Unit helps post-graduate students to develop their skills in activities that require in-depth fundamental and professional training related to research tasks offered by the university. Teaching Internship is focused on building of professional competencies in planning, preparation, and organization of university-level classes. Research Internship is based on unique programs designed by research supervisors according to individual post-graduate plans, and results in thesis graduation.

110

6 Developing and Fostering Smart Ecosystems

• Faculty The faculty consists of tenure and visiting professors, distinguished in their respective fields and enthusiastic about the innovative synergy in education, research, and industry. The Dean for the Faculty of Computer Science and Software Engineering is Professor Succi, who obtained his Ph.D. from the University of Genoa in Italy. The faculty unites selected professors from well known universities of France, Canada, Russia, Italy, South Korea, USA, Denmark, Portugal, and Greece. • International cooperation Innopolis University actively cooperates with high-tech IT companies and plans further collaboration with them. Industry collaborations include agreements for the young specialist training and research with leading IT companies and Russian governmental organizations. Figure 6.15a, b display the logos of the key Innopolis industrial partners. The university builds bridges and extends the partnership to vibrant and interested parties with the focus on technology and research. • Student life Students are housed on-campus in cozy apartments at affordable rates, or they can rent an apartment in the vicinity. The students have all the facilities required for recreation, training, and sports. Additionally, they have state-of-the-art laboratories

Fig. 6.15 Industrial partner logos

6.3 Case Study: Innopolis University and Ecosystem

111

to do research and professional software development. The students are encouraged to form tech clubs and participate in contests and competitions (internally, nationally, or globally). This environment is very transformative for the lives of students as it prepares them for the future, particularly their industrial internship programs. The platform for 5G network was officially presented by the President of the Republic of Tatarstan, the CEO of Rostelecom Company, and the CEO of Huawei Russia. These 5G networks support video streaming in 4 K format, live 360° camera broadcasting, and virtual reality headsets. Recently, Innopolis University also admitted designers of machine learning and image recognition systems. A National Centre of Competence in Robotics and Mechatronics is being located at Innopolis University. The focus of this new Centre is R&D in medicine, industry, and unmanned vehicles. Figures 6.16, 6.17, 6.18, 6.19, 6.20, and 6.21 present the key Innopolis ecosystem facilities and student engagements (on-campus and outside), as they battle in IT competitions. The students receive training and coaching, not to mention their personal effort and dedication to academic excellence. Innopolis University and ENIKS Company completed field testing of package delivery drones under limited visibility and sub-zero temperature. In one hour, the drone delivered the order to a destination located 38 km away and came back. The CTF Inno 2018 is an annual tournament on cybersecurity for schoolchildren. The students compete in cryptography and steganography, they analyze web vulnerabilities and other information security issues (see Fig. 6.26). The student teams typically include 2–4 people.

Fig. 6.16 Testing 5G network at Innopolis University

112

6 Developing and Fostering Smart Ecosystems

Fig. 6.17 Geo-information systems hackathon

Fig. 6.18 Innopolis: the new hub of Russian robotics

6.3 Case Study: Innopolis University and Ecosystem

113

Fig. 6.19 Innopolis: the main university building

Fig. 6.20 Drone testing at Innopolis

Figures 6.22 and 6.23 present the living environment of the students. These are spacious and stimulating facilities designed for happy and creative lifestyle. The University services created a conducive environment for training and studies (Figs. 6.24, and 6.25).

114

6 Developing and Fostering Smart Ecosystems

Fig. 6.21 Registration for the CTF Inno 2018 competition

Fig. 6.22 Bedroom

6.3 Case Study: Innopolis University and Ecosystem

Fig. 6.23 Kitchen

Fig. 6.24 Swimming pool

115

116

6 Developing and Fostering Smart Ecosystems

Fig. 6.25 Gym

Fig. 6.26 Winners of the CTF Inno student competition

6.3 Case Study: Innopolis University and Ecosystem

117

Fig. 6.27 The book on cybersecurity authored by an Innopolis professor

In 2018, Innopolis Professor Petrenko wrote a monograph on the applications of big data for cybersecurity. This book was published by Springer, a major world publisher in the fields of science, technology, and medicine (see Fig. 6.27). • Projects and publications Innopolis University actively engages the students in the projects in big data, software engineering, and robotics; these combine research and practice. • Application process The application process to the university programs is convenient and straightforward. The process starts with an online registration and uploading of the documents required. A series of interviews and tests follows. Upon a decision, successful candidates receive an email confirming their admission. All students admitted are offered full scholarships and monthly stipends to cover their accommodation, food, transport, and some other needs (Fig. 6.28).

6.3.4 Deliverables Success story of the University of Innopolis is the bedrock for the expansion, attraction of the best professors, top-notch companies, and leading industry experts to lecture and deliver keynote addresses at various conferences and seminars.

118

6 Developing and Fostering Smart Ecosystems

World-class faculty members Foreign and Russian experts from top 100 universities worldwide

Study grants

Monthly scholarship Up to 36,000 Russian rubles for Bachelor students and up to RUR 42,000 Russian rubles for Master students

Internship and career start in top IT companies

Covering up to 100% of the tuition fee

Residents of Innopolis City

Instruction in English

International exchange programs

Fig. 6.28 Innopolis University: reasons to apply

The educational process of the University of Innopolis is aimed at combining the best international programs and teaching methods. The university attracts best industry experts, thereby ensuring continuous courseware updates. One of the main goals of the University of Innopolis is to provide students with grants as a source of funding. The applicants undergo online testing in IT and English, and technical interviews with the faculty and industry representatives. The university portal tracks the application process. Under the guidance of eminent professors and experienced research associates, students and graduates of the University of Innopolis are trained in advanced R&D, in collaboration with the industry partners. The university programs imply an intensive combination of fundamental and practical courses, and internships with the leading IT companies from the early stage of training. The University of Innopolis combines science, education, and business. The industry partners actively participate in curriculum design, research projects, internships, and student employment. The University of Innopolis hosts such events as festivals, conferences, and open lectures by high-tech industry experts, on an ongoing basis. The university provides training for high school students in the STEM program, which includes courses in robotics, mathematics and physics, teamwork, and case studies. The university team regularly conducts international competitions in mathematics, computer science, programming, and robotics.

6.3 Case Study: Innopolis University and Ecosystem

119

6.3.5 Innopolis Ecosystem: Conclusion The success story of Innopolis as an ecosystem, smart city, university, and an advanced R&D center, suggests that this strategy can serve as a blueprint for the other cities. The university formed the pivot for the ecosystem, offering advanced training in software engineering, robotics, artificial intelligence (as well as the Lyceum did for mathematics and physics to kids) to produce the human resources for the IT industry. From the systemic approach, the university is the fundamental structure that provides the patterns of sponsorship and research grants to students and migrants of this smart city. The neighboring city objects include the Lyceum, sports and recreational centers, and versatile accommodation assets. The question remains: what are the strengths and weaknesses of the Innopolis ecosystem. To answer this question, a SWOT analysis is required [15]. Although the list of faculty contains a number of advanced experts, it misses superstar professors and topmost IT practitioners from the USA, the global tech innovation leader [16]. Innopolis University continues to expand and grow. This emerging city draws life from the university and propagates it in other spheres including R&D in IT and other hi-tech industries, sports, entertainment, work and research opportunities, and cozy environment and accommodation for the residents.

6.4 Case Study: Comparing CURIN and Innopolis 6.4.1 Project Timelines In 2012, Medvedev, the Chairman of the Russian Government, Minnikhanov, the President of the Tatarstan Republic, and Nikiforov, the Russian Minister of Communications and Mass Media, started the Innopolis construction project by laying a capsule with a message to the future residents. The Russian Government promotes the Innopolis as the project of the Russian IT capital that should unite the high-tech industries around it. Innopolis is a highly urbanized city, which is going to incorporate a nature-friendly environment, modern infrastructure, and support cooperation between IT education and professional development. The University of Innopolis is the hub central to the elements of the Innopolis city. The year 2013 became the starting point for the first student cohort arrival, and the actual birth of this modern city. The university aims to attract intelligent and highly qualified people to teach and study from the world over. The professors from high-ranking universities are invited to do research and train students. The unique atmosphere of the university allows blending practical courses with innovative techniques and methods to offer high quality, applicable knowledge, and essential

120

6 Developing and Fostering Smart Ecosystems 2790

3000

Number of students

2500 1720

2000 1500 1000 500 240

1210

Number of students

Number of faculty

Number of faculty

2002

240

20

2007

1210

190

2010

1720

360

2014

2790

540

0

Fig. 6.29 Chitkara growth story

skills. Many IT companies pay attention to the collaboration with this university; therefore, they open laboratories, become city residents, and adjust the educational process to meet the business requirements. Special economic zone benefits, innovative business priorities, and close cooperation with the government lead to creating massive startups and testing new technologies such as self-driving cars, AI-based systems, and advanced robots. Moreover, expert knowledge of the undergraduates allows IT companies to invite them for internships and research. A large number of such high-tech companies located next to the campus, together with the entrepreneurial spirit of the city, assists in many successful innovative startups. The following key facts, and Fig. 6.29, illustrate the Innopolis University project progress as of 2015 (the current data is even more impressive): • • • • • • •

over 600 university students, 13 research laboratories, 4 research centers, over 20 academic partners around the world, 45 grants for a total of 600 M Russian rubles (approx. USD 10 M), over 1 billion Russian rubles (or approx. USD 150 M) of sponsorship funds, over 80 professors and researchers from the world top 100 universities and leading IT companies.

Chitkara In the year 1998, the Chitkara family established the Chitkara Educational Trust with the mission of providing quality education. They started with an Engineering College in the year 2002. Currently, the same Trust incorporates two universities, and a K-12 international school. Over the past 17 years, student enrollment increased manifold, which demonstrates development success and student satisfaction. Since 2002, when Chitkara started with 240 students, their number exceeded 11,000 in 2018. The university focuses on market-oriented learning and practices. Strong industry collaboration results in regular and intensive on-campus recruitments by the leading companies.

6.4 Case Study: Comparing CURIN and Innopolis

121

Since 2002, the student enrollment has increased over 12 times, and the faculty number has increased over 27 times. Since its inception, the university struggled to become a world-famous brand through excellent interdisciplinary education focusing on innovation-oriented disciplines, and practically focused courses. These goals became achievable due to active and intensive teacher–student–industry cooperation in entrepreneurship and research activities. Chitkara University Research and Innovation Network (CURIN) was a pilot research program of the ecosystem in 2014. The aim was integrating a number of research areas to build a friendly and ethical, product-oriented R&D environment. The key reasons of CURIN competitive advantages: • • • •

Striving for leadership in research, Multi-disciplinary collaboration, Building a friendly, attractive infrastructure, and safe environment, Blending new technologies and methods for innovative solutions.

6.4.2 Similarities Strategy and Focus Area Innopolis and Chitkara universities were both established to facilitate IT training and to commercialize their research-intensive, innovative startups. Innopolis focused on attracting skilled employees and leading world experts from the large-scale multinational companies, universities, and R&D centers, due to their innovative research background and advanced knowledge of IT. Chitkara was established by a family of school teachers, who gave their name to this new ecosystem. Their unique holistic educational approach known as the “Chitkara Way,” suggested starting the venture from an IT-focused engineering college. Designed with an intensive practical focus, Chitkara shortly became one of the best universities in Northern India. Chitkara students are valuable assets to potential employers and society, considering their innovative training, and practically oriented education. Students typically choose their own track of study that helps them to overcome obstacles, achieve their goals, and train essential skills, such as analytical thinking, problem solving, leadership, and team building as well as ethical and social responsibilities. Industry Collaborations Collaboration with companies and organizations is one of the main principles for both Innopolis and Chitkara ecosystems. Their market-oriented learning and practice are aimed at the partnership with multiple organizations participating in campus research and recruitment. Chitkara is building partnership through internationalization, introducing the best talents to the market and building a knowledge-based society, and

122

6 Developing and Fostering Smart Ecosystems

they suggest that extensive and progressive research collaborations with a strong focus on student–faculty exchange programs. The University of Innopolis, as a part of Russian federal project, offers cooperation with many innovative companies. Innopolis programs focus on intensive practical courses in combination with internships. Students are involved in advanced research and development, under the guidance of experienced and highly qualified professors and researchers, which can be connected to industry partner projects. The Innopolis management considers partnership and collaborations with industry are very important, and should help each side to achieve their goals and develop innovative products. They plan to hold this strategic approach with all their partners. Employment Opportunities Most of the students are concerned about job opportunities after graduation. Therefore, both ecosystems provide market and industry-oriented learning that is essential for the future employees in the market. They provide internship programs, strong industry collaborations, and help to secure jobs after graduation. Chitkara’s unique program produces qualified graduates for challenging tasks and real-world problems in their particular environment. Chitkara students apply knowledge and experience to improve their skills, which are highly appreciated in companies and useful in a future career. Chitkara University supervisors ensure that students are connected to the professional environment, and ready to work. The Innopolis syllabus offers more than six months of industrial practice, development and internships in innovative IT companies, and guarantees employment for the graduates. Innopolis students are supplied with advanced skills in software development; they are capable of complex problem solving, and monitoring through metrics and assessments. University provides the platform to suggest their ideas to the stakeholders within the city of Innopolis. Programs Both universities specialize in IT and software engineering. Since Chitkara was founded earlier and follows the step-by-step strategy, they cover more programs and faculties than Innopolis University. Chitkara offers world-class graduate, undergraduate, post-graduate, and doctoral programs. Their key schools and doctoral programs include Chitkara Business School, Chitkara College of Applied Engineering, Chitkara Polytechnic, Electronics & Communication Engineering, Computer Science & Engineering, and Pharmaceutical Sciences. Innopolis University started later, in the 2010s. They offer bachelor and master programs in software engineering, computer science, and robotics. Bachelor program duration is four years. During the first two years, the university provides essential courses in software engineering and computer science. In the last two years, students choose subjects related to their specific degree plan: robotics, artificial intelligence, software engineering, game development and applications, or data science.

6.4 Case Study: Comparing CURIN and Innopolis

123

Innopolis master’s degree program consists of two years. The first one is mostly academic, followed by a one-year internship. The curriculum meets the latest standards in robotics, software engineering, and computer science; it was designed in close partnership with the leading research communities and IT companies, including Carnegie Mellon University and Software Engineering Institute [17].

6.4.3 Research Centers Research initiatives and collaborations are an integral part of the Chitkara University educational programs. Tutors, doctors, and students work together in interdisciplinary projects, and they improve their experience in different spheres. CURIN was established in 2014, with a clear objective to bring all research related activities under one umbrella, provide a conductive environment for best research practices, and promote product-oriented development (Fig. 6.30). Innopolis offers a number of competitions and grant programs to their students, to get paid for development projects and fundamental research. These grants are industry-focused. Moreover, Innopolis University has the Institute of Robotics, a leader in robotics and artificial intelligence. This became possible due to attracting competitive professors and teachers, who focus on innovative research. Innopolis has a goal to attract students to become IT experts. Their programs apply to the global economy and improve existing approaches to reach a new level of social, ethical, and practical value. To achieve this goal, they opened the IT Institute with the following methods and domains: Domains

Office of Patent Facilitation Licensing and Consultancy

Centres for Advanced Research

Masters of Engineering Programs Doctoral Research Centre

CURIN

Fig. 6.30 CURIN ecosystem: motivation and drivers

Centre of Excellence for Entrepeneurship Education

124

• • • • • • •

6 Developing and Fostering Smart Ecosystems

Understanding human behavior, Computational creativity, Social network analysis, Computer vision, Biomedical/Bioinformatics, Transportation and smart city, Automation/Process development.

Research/Training methods • • • • •

Soft computing/Computational intelligence/Machine learning, Image/Video processing, Databases, Pervasive computing, Procedural content generation.

The Software Engineering Laboratory of Innopolis University is devoted to development of software methods and tools. The key competence areas are: • • • • • • • • • • •

Software verification (by constructing proofs and testing), Concurrency, Persistence and evolution, Object-oriented reengineering, Language design and evolution (with particular focus on Eiffel language), Software architectures, Model checking and temporal logic, Process calculi, Service-oriented programming, Microservices (with particular focus on Jolie language), Social networks and trustworthy computing algorithms.

6.4.4 Differences Organization type Innopolis University is a government project under Russian Federation control. Also, there is a Board of Trustees, which includes the Minister of Communications, Mass Media of Russia members, and a few other government officials. The Board of Trustees is responsible for: • • • •

University strategy, Budget, Key performance indicators, Director appointment.

6.4 Case Study: Comparing CURIN and Innopolis

125

Fig. 6.31 Innopolis University: management structure

Sponsor investments are received timely and acknowledged by the management. Obviously, the Rector and the Director are not the Innopolis owners (Fig. 6.31). Conversely, Chitkara ecosystem is initially private, which means they receive little or no governmental support. The university has no Trustee committee, and government officials do not affect their strategies and decision making.

6.4.5 Budget Chitkara and Innopolis ecosystems had very different financial prerequisites. Being a private startup, Chitkara initially had a low budget; therefore, the founders applied a step-by-step strategy to commit the development stages one by one. Conversely, the Russian Government allocated a substantial budget to launch the Innopolis project. Therefore, this ecosystem was fully equipped with modern and new technologies; all buildings were constructed from the ground up. Moreover, Innopolis provided high standards and excellent living conditions for students. The founders of Innopolis continue expanding the infrastructure to host the increasing number of students and IT professionals.

6.4.6 Salaries Innopolis University provides a decent benefit package, which includes paid vacation, housing and relocation allowances (depending on family size and employee rank),

126

6 Developing and Fostering Smart Ecosystems

Fig. 6.32 Chitkara: assistant professor salaries

home leave travel (twice in a year), and medical insurance. Besides, they offer a salary level competitive to Europe and North America (USD 42,000–210,000). The University also offers a special package for each distinguished faculty member; this supports laboratory establishment, two Ph.D. students, and extra research opportunities. They also help to search and recruit Ph.D. students from the world over, and support national and international research grant applications. In contrast to Innopolis, Chitkara does not offer a salary level competitive to the EU or the USA. Assistant professor’s average salary is approximately |25,090 (Indian rupees), which varies between |22,982 and |36,579, according to salary reports. Considering bonus and compensation policy, an Assistant Professor at Chitkara University may expect an average income of around |30,108 per month [6] (Fig. 6.32). The exchange rate of US d· 1/70. This means that $100 is equal to |7076 according to average exchange rates of 2018. Fees and Scholarship Opportunities Innopolis University can offer a choice of tuition scholarships, up to 36,000 (Russian rubles) for bachelor, and up to 42,000 for master degree in case of perfect academic performance. For the same period of 2018, an average exchange rate of US dollars to Russian rubles is around 1/60. This means that $100 is equal to nearly 6100. Chitkara also can offer a few scholarships under the Punjab Government program that cover their full tuition fees. However, most of the students have to pay for their education (Table 6.3).

6.4.7 Student Life Students of the Innopolis University enjoy comfortable accommodation at reasonable prices. They can also rent an apartment on their own. The infrastructure provides dedicated facilities for sports and training, and places to take a rest. For their R&D projects, the students have a wide choice of laboratories, where they can carry out research and develop applications, following the recent trends in project management,

6.4 Case Study: Comparing CURIN and Innopolis

127

Table 6.3 Fee structure and education cost at the Chitkara University Course

Semester I

ERP feeb

Semester II

Semester III

Semester IV

MBAa

Rs. 125,000/-

Rs. 7500/-

Rs. 125,000/-

Rs. 125,000/-

Rs. 125,000/-

M.Sc. Actuarial Science

Rs. 125,000/-

Rs. 7500/-

Rs. 125,000/-

Rs. 125,000/-

Rs. 125,000/-

Course

Year I

ERP feec

Year II

MBA in Sales and Retail

Rs. 125,000/-

Rs. 7500/-

Rs. 125,000/-

MBA in Pharma Mgmt

Rs. 125,000/-

Rs. 7500/-

Rs. 125,000/-

MBA in BFSI

Rs. 125,000/-

Rs. 7500/-

Rs. 125,000/-

a Marketing/Banking

& Finance/Business Resource/Financial Markets Practice b ERP fee only at the time of admission c ERP fee only at the time of admission

Analytics/Healthcare

Management/Human

web, mobile, and AI areas. To improve the “soft” skills, they can practice sports (such as football and swimming), improve communication at the foreign language clubs, compete in hackathons, software development championships, and visit conferences and lectures with world-class experts, top-level speakers etc. These favorable conditions prepare students for the individual and team activities in their future internship programs, and further professional careers. Every year, before the studies, Innopolis has a “boot camp” for the new university entrants. The freshmen have meetups, join different groups according to their interests, and visit the ethno-village, where they study the diversity of the neighboring cultures and traditions. These activities assist in establishing strong ‘multinational ties’ from the first days of studying together; they improve agility in terms of cultural varieties. Similarly to the Innopolis aims, the Chitkara ecosystem sets the goals of improving communication between the students and actively engaging the freshmen into their diverse environment [18]. An efficient way to achieve these goals is promoting picturesque and colorful campus life for the students, faculty, and staff. Therefore, the campus life at Chitkara includes a rich set of athletic, cultural, social, and educational activities.

6.4.8 Arts and Culture The Chitkara student community informally controls most on-campus organizations and events. Fostering and stimulating creativity is one of the key traditions of the university. Chitkara has a large number of student clubs (such as EBUZZ, MATRIX, SEAGULLS, BIT & BYTES, MECHSTEIN, ELECRAMA, C2S2, to name a few).

128

6 Developing and Fostering Smart Ecosystems

Favorable

Internal

Strength •New and modern Infrastructure •Outstanding professors

Unfavorable

Weakness •May have flexible recruitment process

•Modern state of the art laboratories

External

•Diversified culture

OpportuniƟes

Threats

•Federal Support •Industrial Support

•Other universiƟes rank beƩer

•InternaƟonal publicity from the diversity of students

•More established universiƟes in of their programs

Fig. 6.33 SWOT analysis of the Innopolis

The major on-campus events include Annual Convocation, Algorithms, University Sports Meet, Gameeks, C-Champ, T-20 Cup, Questions, Chitkara Mandi, and Techelone.

6.4.9 SWOT Analysis of the Innopolis University See Fig. 6.33.

6.4.10 Questions for Discussion To outline a plan for similar projects, as Gill recommends [2], we would suggest the following set of questions: • • • •

What is the motivation (i.e., driving force) for the two projects? Which features of the project plans would you recommend for similar smart cities? What are the prospects for these two projects? What are the lessons learnt in these two projects, and what is their cost?

6.4 Case Study: Comparing CURIN and Innopolis

129

In essence, the initial purpose of the Innopolis ecosystem was to build a smart city, and an IT hub full of technology startups, to drive innovation and implement intelligent technologies. Chitkara’s main aim was more pragmatic, as they planned to provide the latest market-oriented educational programs and train qualified specialists for the innovative IT engineering industries. Both ecosystems were established to give cutting-edge knowledge and experience to the high-tech young professionals, who strive to build an innovative future and open new horizons.

6.5 Conclusion This chapter discussed the strategies for research, international collaboration, and advanced training implemented at the Chitkara and Innopolis ecosystems. Their strong research and study programs attract distinguished faculty and gifted students from the world over. Studying at these universities develops both professional and life skills, such as critical thinking. These perspectives, together with open communication and the innovative nature of the ecosystems concerned, assist in building an agile and crisis-responsive framework [19, 20], and therefore, contribute to a better and more prosperous future.

References 1. Chitkara International School and Kindergarten. http://www.chitkaraschool.in/kindergartenprogram/. 2. Gill, G. T. (2011). Case method informing with the case method: A guide to case method research, writing, & facilitation (562 pp.). Informing Science Press. Chitkara University, Punjab. https://www.chitkara.edu.in/. 3. Trimester-Based Academic System information. Available at: https://www.researchgate. net/publication/304579637_Trimester-Based_Academic_System_in_Engineering_Institutes_ Chitkara_University_-_A_Case_Study. 4. Information on Punjab and Punjab universities. Available at: https://www.britishcouncil.org/ sites/default/files/the_indian_states_-_oppurtunities_for_international_higher_education_ col_.pdf. 5. DEXPERIENCE System, case study in Chitkara University. https://www.3ds.com/fileadmin/ customer-stories/Chitkara_University_-_3DS_-_Tata_Technologies_case_study.pdf. 6. Chitkara University in Himachal Pradesh. https://www.chitkarauniversity.edu.in/. 7. Chitkara university national excellence award information. https://businesswireindia.com/ news/fulldetails/mr-manish-sharma-president-ceo-panasonic-india-south-asia-conferredwith-chitkara-university-national-excellence-award-2018/58051. 8. HackerEarth Recruit System information. Available at: https://www.hackerearth.com/ recruiters/customers/chitkara-university/. 9. Information on Chitkara competitors, employees and revenue. https://www.owler.com/ company/chitkara#history. 10. Chitkara University ranking and Review. https://www.4icu.org/reviews/14345.htm. 11. Hydroponics Greenhouse Farming information. Available at: https://www.shoutlo.com/ articles/chitkara-univeristy-initiates-hydroponic-farming-startup.

130

6 Developing and Fostering Smart Ecosystems

12. Innopolis, Ecosystem website (in Russian). https://innopolis.ru/. 13. Innopolis, University. https://university.innopolis.ru/en/. 14. Innopolis, Annual report, https://university.innopolis.ru/upload/iblock/026/IU_AR2018_eng. pdf. 15. Turban, E., & Aronson, J. E. (2001). Decision support systems and intelligent systems (6th ed.). Upper Saddle River, NJ: Prentice Hall. (Copy-right 2001). 16. The Changing Landscape of Disruptive Technologies: Tech hubs forging new paths to outpace the competition, KPMG Report, March 2018, https://info.kpmg.us/content/dam/info/techinnovation/pdfs/2018/tech-hubs-forging-new-paths.pdf. 17. Software Engineering Institute. www.sei.cmu.edu/. 18. Gromoff, A. (2010). A study of the subject-oriented approach for automation and process modeling of a service company. S-BPM ONE, 2010, 192–206. 19. Zykov, S. (2016). Crisis management for software development and knowledge transfer. Issue 61: Springer series in smart innovation, systems and technologies (133 p.). Cham: Springer International Publishing. 20. Zykov, S. V. (2018). Managing software crisis: A smart way to enterprise agility (p. 153). Cham: Springer International Publishing.

Conclusion. Reaching Agility in Diverse Environments

In this book, we have discussed large-scale software systems development. Developing such kind of systems, especially under critical conditions, requires agility. The intuitive, naive understanding of this agile approach is flexibility. However, in reality, an agile approach is often much more complex. The introduction to this book suggests that for large-scale systems (possibly with software and hardware components), at least two dimensions of factors matter. These are human and technological. Surprisingly, for such kind of systems the human factors are often influential and sometimes mission-critical. Two recent Russian catastrophic examples, Chernobyl (1986), and the Kursk submarine disaster (2000), suggest that these were human factors, which triggered the technological malfunctions and which were the root causes of the tragedies. In Chernobyl, people violated operating instructions; they turned off the automatic control systems, and manually set certain operating parameters to dangerous levels. With Kursk, the operating environment was also changed to a critical one (a shallow depth of 108 m for a 144 m long submarine), and then the launch of a damaged missile, triggered the explosion. We present a model of these mission-critical environmental changes in the conclusion of our previous book [1]. This model is referred to as crisis management triangle, which includes three zones: two nested triangles (the inner green and the outer yellow), and the outermost red zone embracing these. Each zone refers to a set of combinations for the essential project delimiters, such as labor, time and budget. The idea is that the inner green triangle refers to the comfort zone, where no managerial action is required to adjust the delimiters, whereas the other two zones require attention. The next yellow zone refers to manageable projects; therefore, timely managerial action is required to adjust the delimiters so that the new project parameters move the development into the green zone, or at least keep it out of the critical red one. The outer red zone refers to the critical area, where it is impossible to complete the project safely and deliver a quality product. The project should be either terminated as soon as possible, or seriously readjusted. In the latter case, the project

© Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0

131

132

Conclusion. Reaching Agility in Diverse Environments

either yields to a downsized version of the initially approved product, or requires a critically different timeframe or labor cost. Therefore, to produce a quality product with the timeframe specified and the human resources available, the project should be continuously monitored in order to avoid critical parameter combinations that may result in a low quality, extra time or labor expenses or even an undelivered product and/or tragic consequences. To make this software production more efficient, we suggested a systemic approach to improve agility, which included a few dimensions of models, methods, tools, patterns, and practices. These dimensions should be applied at the three levels: individual, team and organizational. As each software development project is unique, no “silver bullet” is available; instead, the project should be tailored to provide acceptable quality in a timely manner and without extra labor expenses. Our focus was complex and large-scale systems. We demonstrated by the case studies, that successful projects are possible even under regional and cultural diversity, when the developers boost human factors (including communication, negotiation, and teamwork) by carefully selected and adjusted agile methods, techniques and practices. Harnessing these human factors assists in a successful knowledge transfer between the client and the developer, which clearly becomes the key to project success, and product operational quality and utility. A couple of failure stories below, illustrates what could have happened in case of insufficient agility and ignoring/neglecting these human factors. In 1986, there was an accident at the Chernobyl nuclear power station (Ukraine, former USSR, Fig. 1) [2]. This accident is believed to be the largest nuclear energy related disaster that has ever happened. The official reason was a sudden surge of power, which destroyed the reactor and produced massive radioactive emissions. The accident caused severe radiation effects, among nearly 600 workers, of which over 130 died (28 died in 4 months) and many more suffered from radiation sickness. In 1986–87, around 600,000 workers were involved in the recovery and cleanup at Chernobyl; as they may become ill, their health is being monitored [3]. In 2000, there was a disaster on the Kursk nuclear powered submarine (Barents Sea, Russia). This accident is believed to be the largest naval tragedy that ever happened in Russia during peacetime. The reason was a torpedo fuel leakage due to its damage in transportation. Inspectors noticed the malfunction; however, the officers neglected it, as the scheduled exercise was their priority, and the torpedo was loaded. The fuel leakage led to the initial explosion in the torpedo compartment; in about two minutes, this triggered a second explosion of 5–7 combat-ready torpedo warheads. This destroyed nearly 80% of the compartments and severely damaged the submarine, which “descended to the ocean floor”, as the Navy reported (Fig. 2). The rescue attempts failed due to bad weather and inappropriate/malfunctioning equipment. Although experienced international divers participated in the rescue mission, this was very restricted as the Russians were extremely cautious concerning the Kursk, the pinnacle of Soviet engineering. Due to the authorities slow reaction and oxygen reserves depletion, the remaining 23 survivors of the 118 men crew, died

Conclusion. Reaching Agility in Diverse Environments

133

Fig. 1 Chernobyl: severely damaged energy unit of the nuclear power plant

from suffocation. Finally, the Chief of the Russian Northern Fleet announced that the Kursk flooded, and the crew was dead. What do these accidents have in common? As it seems at first sight, they happened in very different environments (Southern and Northern locations, land and sea, USSR and Russian Federation, civil organization and Army). One evident similarity is the scale of these tragic events; perhaps this was the reason for revisiting them in

134

Conclusion. Reaching Agility in Diverse Environments

Fig. 2 Kursk Memorial, Murmansk City

the recent movies shot in 2019: the “Kursk” drama film, and the “Chernobyl” TV Mini-Series [4, 5]. The other common part is a nuclear reactor, which is a typical example of a complex system. Yet another similar point is that several teams designed, constructed and tested these complex objects, and then another team operated them. Since such large-scale systems are typically more complex managerially than technologically [6], the accidents happened due to human error (or even a series of errors, which might seem negligible at first sight). In the case of the Kursk submarine, this is evident if we turn to the discussion on the catastrophe [7]. The Summary Reports on the Post-Accident Review Meeting on the Chernobyl Accident by the International Atomic Energy Agency, specify that in spite of the reactor design flaws and system malfunctioning as a result of an uncommon operating mode, "the human factor has still to be considered as a major element in causing the accident". By removing too many control rods and thus dangerously lowering the operating reactivity margin, the operators placed the reactor in a condition that triggered the accident [8]. Now we can see the striking similarity of these two tragedies that happened, again, under very different circumstances. Careless application of safety instructions, severely neglecting job responsibilities, and weak management and process control, resulted in these major accidents, unprecedented in history. Afterwards, these tragedies required tremendous investments in rescue and recovery missions (in terms of labor and budget), which was an attempt of stabilizing the after-crisis environments, instead of improving the human resource-based safety management and raising the chance of saving the lives in future. Let us revisit the book narrative and the approach suggested by the authors to make the agility shift, which allows prediction, prevention and/or responsive management of accidents and critical situations, in software product development.

Conclusion. Reaching Agility in Diverse Environments

135

To establish a firm basis for future discussion and findings in large-scale software development, we summarized the key concepts of agility, crisis and the human factors in Chap. 1. This conceptual framework included an overview of the strategies for agile software development and smart process improvement. Further, in Chap. 2 we provided a deeper dive into diversity, concerning its cultural, mental, organizational, process, and maturity aspects, within the same context of system agility. Specifically, we addressed the problems of large-scale software development in certain domains and environments, focusing on social and cultural aspects. In the next Chaps. 3 and 4, we took a closer look at knowledge management in an agile manner, including a set of multi-faceted, human factor-dependent examples that reinforced the foundation for future case studies. To provide a deeper insight, in Chap. 5 we investigated the agile development patterns and practices at individual and team levels. Afterwards, we provided a walkthrough of large-scale innovative ecosystems in Chap. 6, based on a comparative case study. Therewith, our standpoint was multi-contextual agility analysis, which, again focused on the human factors. Finally, we summarized our key findings in the conclusion, and suggested agile practices to improve large-scale software development in terms of smartness and flexibility. Our narrative was based on systematic analysis of the local and cultural diversities. This was supported by the case studies of the innovative ecosystems of the CURIN/Chitkara (Punjab State, India) and Innopolis (Tatarstan Republic, Russia). The above-mentioned case studies suggested a few agility improvements, which are applicable even in inflexible and crisis-provoking environments. These suggestions included open communication, positive climate, disciplined development, strict adhering to standards, commitments and deadlines, timely and goal-directed feedback, and continuous process and quality improvement. We sincerely hope that our set of models, methods, tools, patterns, practices and case studies will be a handy toolkit for both software developers and their managers. We wish you extreme agility and every success in your current and forthcoming software development endeavors!

References

1. Zykov, S. V. (2018). Managing software crisis: A smart way to enterprise agility (153 p.). Cham: Springer International Publishing. 2. http://www.atomicarchive.com/History/coldwar/p21_image.shtml. 3. U.S. Nuclear Regulatory Commission: Fact Sheet: https://www.world-nuclear.org/informationlibrary/safety-and-security/safety-of-plants/chernobyl-accident.aspx. 4. Chernobyl movie. (2019). https://www.hbo.com/chernobyl. 5. Kursk movie. (2019). https://www.imdb.com/title/tt4951982/. 6. Booch, G. (2006). Software architecture and the UML. 7. War history online: https://www.warhistoryonline.com/military-vehicle-news/tragedy-russiansubmarine-kursk.html.

136

Conclusion. Reaching Agility in Diverse Environments

8. Summary Reports on the Post-Accident Review Meeting on the Chernobyl Accident (INSAG) by the International Atomic Energy Agency (IAEA): https://www-pub.iaea.org/MTCD/ publications/PDF/Pub913e_web.pdf.

Glossary

Agile methodology Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer/end user. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change. Backlog A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome. Burn down chart A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. Business Intelligence (BI) BI act as a set of all technologies used to collect and investigate data so that it helps the organization in the decision-making process. Collective code ownership Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. Communities of Practice (CoPs) Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain. Collaborative wall (information radiator) "Information radiator" is the generic term for any of a number of handwritten, drawn, printed or electronic displays, which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information at a glance. Culture All definitions in general relate to identifying with the shared mindsets, feeling, shared meaning and characteristics, shared socially developed environments, common ways in which innovations are utilized, and commonly experienced events. Cross-cultural Cross culture in the business world refers to a company’s efforts to interact effectively with professionals from different backgrounds. © Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0

137

138

Glossary

Cross-functional teams A cross-functional team is a group of people with different functional expertise working toward a common goal. Daily build A daily build or nightly build is the practice of completing a software build of the latest version of a program, daily. Domain knowledge In software engineering domain knowledge is knowledge about the environment in which the target system operates, for example, software agents. Explicit knowledge Explicit knowledge (also expressive knowledge) is knowledge that can be readily articulated, codified, stored and accessed. Framework A framework, or software framework, is a platform for developing software applications. It provides a foundation on which software developers can build programs for a specific platform. Globalization The process by which businesses or other organizations develop international influence or start operating on an international scale. Global Software Development Global Software Development (GSD) is "software work undertaken at geographically separated locations across national boundaries in a coordinated fashion involving real time (synchronous) and asynchronous interaction". Individualism Individualism is a feel that a person gets re-electing to a personal sense of accomplishment from work, having a work that spares adequate time for individual or for the family members, flexibility to use their own method for work. Intellectual property Intellectual property (IP) refers to creations of the mind, such as inventions; literary and artistic works; designs; and symbols, names and images used in commerce Big-data and artificial intelligence. Knowledge management Knowledge management (KM) is the process of creating, sharing, using and managing the knowledge and information of an organization. Lightweight methodology A lightweight methodology is a software development method that has only a few rules and practices, or only ones that are easy to follow. Masculine Masculine characterizes gender roles for example in some societies, men are to exhibit masculine characteristics and behaviors as self-confident, tough, intense, and concentrated on objective achievement, while women being more humble, delicate, and concerned with the quality of life. Modularization The design or production of something in separate sections. Pair programming Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. Planning game A planning game is a meeting attended by both IT and business teams that is focused on choosing stories for a release or iteration. Process A series of actions or steps taken in order to achieve a particular end. Refactoring Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve non-functional attributes of the software.

Glossary

139

Retrospective meeting Retrospective, a meeting that is held at the end of an iteration in agile development. Self-organizing team A self-organizing team is one that does not depend on or wait for a manager to assign work. Instead, these teams find their own work and manage the associated responsibilities and timelines. Shotgun debugging A process of making relatively undirected changes to software in the hope that a bug will be perturbed out of existence. Socio-cultural variable Sociocultural factors are customs, lifestyles and values that characterize a society or group. Software development lifecycle The systems development lifecycle (SDLC), also referred to as the application development lifecycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system. Sprint A sprint is a set period during which specific work has to be completed and made ready for review. Tacit knowledge Tacit knowledge resides in the human mind, being a personal asset and is difficult to put it in a formal way, classifies as well as communicate. Throughput Throughput is the rate of production or the rate at which something is processed. User Story A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

Index

A Activity, 20 Agile, xiii Agility, 20

B Backlog, 47 Best practice, 65 Bloom’s taxonomy, xiv Business requirements, xiii

C Carnegie Mellon University (CMU), 123 Chitkara, 91 Comfort zone, 131 Common vision, 14 Communication, 30 Continuous Delivery (CD), 30 Continuous Integration (CI), 76 Crisis management, 1 Crisis zone, 2

D Dijkstra, E., 8

I Innopolis, 111

K Key performance indicator, xv Knowledge management, 37 Knowledge transfer, vii

L Language, 5

M Metaphor, 24 Microservice, 124

O Optimization, xiv Oracle, 6

F Feedback, xiii Formal methodology, 2

P Product vision, xiii

H Human-related factor, vii

S SAP, 60

© Springer Nature Switzerland AG 2020 S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Smart Innovation, Systems and Technologies 175, https://doi.org/10.1007/978-3-030-40989-0

141

142

Index

Soft skills, 3 Software architecture, xiv

Teamwork, 3

T Teaching, xvi

V Visual Studio (VS) .Net, CASE tool, 5