Modern productivity teams demand modern leadership, one that understands modern development needs, stresses, teams, and other aspects of agile development team dynamics []. The purpose of the book is to introduce managers to the new productivity environments, including geographically, culturally, and generationally diverse teams. The Agile development paradigm embodies a set of principles which at first may seem contrary to classical business practices:
Satisfy the customer through early and continuous delivery of software capabilities and services through short software sprints, lasting from 2 weeks to 2 months, with a preference toward shorter sprints.
Embracing the environment of change. The Agile development process harnesses change to gain a competitive advantage in the software development marketplace [].
Business development, management, and developers must cooperate and collaborate throughout the development project.
Communication needs to be face-to-face, even if that means teleconferencing over diverse geographical locations. Face-to-face communication is essential for efficiently and effectively conveying necessary information across an agile development team.
The Agile development process is designed to allow a sustainable, constant pace development throughout the entire development project.
The primary measure of success (Earned Value) is working software and capabilities, NOT Equivalent Software Lines of Code (ESLOC).
Agile development does NOT mean a lack of design. A good design (architecture) enhances agility and allows continuous attention to technical excellence.
Simplicity is essential in agile development. The importance of agile software development demands the art of maximizing the work NOT done.
The best architectures, requirements, and software designs emerge from self-organizing teams, NOT from management mandated team structures.
1.1 Agile Development Demands Agile Management
Agile software design methods are now commonplace; however, management skills, in general, have not kept pace with the advances in software development practices. There is a major push among companies, both government and commercial, to embrace the concepts of diversity and inclusiveness. Managers need to be trained in how to manage teams of diverse personnel. Much has been made of managing different personalities, but managers need to be aware of soft people skills, how to manage them, use them effectively, and how they affect people of different backgrounds [].
It is commonplace to have to work with teams across geographically, ethnically, generationally, and culturally diverse backgrounds within the same team, not to mention a range of skill levels. This book will be helpful in understanding how to manage an agile development team that includes such dynamics []. This book will take the project/program manager beyond the concepts of transformational leadership, which provides methodologies to connect to employees sense of identity, to include human psychological concepts such as Locus of Control, which will help the manager understand team members view of how to manage their world contributes (enhances or detracts) from their ability to work within team dynamics.
Agile design methods have been utilized since the mid-1990s, and yet program/project managers have been slow to adapt to the changes required for effective agile development []. And while there are basic management techniques like Scrum available for the mechanics of managing agile teams, none of these address the dynamics agile development, which include:
How to choose the right agile development team
How to facilitate, not control, an agile team
How to trust your team: trust is an important factor in change []
The agile development process demands trust, transparency, accountability, communication, and knowledge sharing [].
The purpose of the book is not to emphasize any particular Agile Development Management style (e.g., Scrum), but instead to investigate and present methods for effective Agile team development and management philosophies. Just because you use Scrum does not mean you are Agile. Scrum is a one of many methods for managing Agile Software Development teams, assuming you have an agile development team. Many management organizations confuse this, with disastrous results. To overcome this and to provide the Agile Manager with the skills required to efficiently manage agile development teams, the book includes discussion agile management techniques []), as well as new metrics and methodologies for measuring the efficacies of Agile Development teams (agile EVMS).
1.2 Software and Systems Engineering: Where Did They Come From?
Many think the discipline of Software Engineering is relatively new, and that before the invention of modern software techniques, the discipline was nothing more than structured coding. But actually, the first two conferences on Software Engineering were sponsored by the NATO Science Committee in 1968 and 1969 in Garmisch, Germany [].
1.2.1 Software Engineering History
In 1968 and 1969, the NATO Science Committee sponsored two conferences on software engineering, seen by many as the official start of formal discipline of Software Engineering. The discipline grew, based on what has been deemed the Software Crisis of the late 1960s, 1970s, and 1980s, in which very many major software projects ran over budget and over schedule; many even caused loss of life and property. Part of the issues involved in software engineering efforts throughout the 1970s and 1980s is that they emphasized productivity, often at the cost of quality []. We will discuss this at length in subsequent chapters, as the intent here is just to provide a brief history.
1.2.2 System Engineering History
Systems engineering began its development as a formal discipline much earlier than software engineering, during the 1940s and 1950s at Bell Laboratories. It was further refined and formalized during the 1960s during the NASA Apollo program. Given the aggressive schedule of the Apollo program, NASA recognized that a formal methodology of systems engineering was needed, allowing each subsystem across the Apollo project to be integrated into a whole system, even though it was composed of hundreds of diverse, specialized structures, sub-functions, and components. The discipline of system engineering allows designers to deal with a system that has multiple objectives, and that a balance must be struck between objectives that differ wildly from system to system. System engineering seeks to optimize the overall system functionality, utilizing weighted objectives and trade-offs in order to achieve overall system compatibility and functionality [], coupled with elements of other methods. Here the Rational Software Company simplified current methods from several authors into a set of OOAD methods that included Class Diagrams, Use Case Diagrams, State Diagrams, Activity Diagrams, Data Flow Diagrams, and many others.