Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.
PROJECTS change. This simple fact is not fundamentally due to a lack of planning or incompetence on the part
Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.
PROJECTS change. This simple fact is not fundamentally due to a lack of planning or incompetence on the part of project managers and project developers. Rather, change is an inherent characteristic of any growing entity. Embedded projects grow as much as they are built. Living things adapt to their environment. The environment surrounding any embedded project is ever in flux. Budgets change. Resources change. Schedules change. Competition changes. Customer needs change. Even if this changing environment could be eliminated, another form of change would continue to affect embedded projects. A project learns as it grows and must change in response to this learning. That is, as features come to fruition, the developers, users, customers, and managers become more fully aware of the project’s reality. First, by “traditional project management” we refer mainly to any methodology where project development is viewed as a specialized version of manufacturing or as a construction project. This type of project management is identified by its sequential phases of design, implementation, and testing (the “waterfall” approach) planned out through critical path analysis (usually represented via Gantt charts). Second, we address here only those projects that include any sort of variability or unknowns in their requirements
Agile methodologies such as eXtreme Programming (XP), SCRUM and Feature-Driven Development strive to reduce the cost of change throughout the project development process. For example, XP uses rapid iterative planning and development cycles in order to force trade-offs and deliver the highest value features as early as possible. In addition, the constant, systemic testing that is part of XP ensures high quality via early defect detection and resolution. In spite of some early success with agile methodologies, a number of factors are preventing their widespread adoption. Agile methodology advocates often find it difficult to obtain management support for implementing what seem like dramatic changes in application development. These methodologies require developers, managers and users alike to change the way they work and think. For example, the XP practices of pair programming, test-first design, continuous integration, and an on-site customer can seem like daunting changes to implement. Furthermore, these methodologies tend to be developer-centric and seem to dismiss the role of management in ensuring success. Traditional management theory assumes that:
Rigid procedures are needed to regulate change
Hierarchical organizational structures are means of establishing order
Increased control results in increased order Organizations must be rigid, static hierarchies
Employees are interchangeable “parts” in the organizational “machine”
Problems are solved primarily through reductionist task breakdown and allocation
Projects and risks are adequately predictable to be managed through complex up-front planning
Within this context, it is small wonder that the new methodologies appear informal to the point of being chaotic, egalitarian to the point of actively fostering insubordination, and directionless in their approach to problem solving. We believe that the slow adoption of agile methodologies stems mainly from this misalignment between the fundamental assumptions of traditional management and those of the new agile development methodologies. As such, there is a significant need for a change in assumptions and a new management framework when working with agile methodologies.
Specifically, we have begun to build the notion of complex adaptive systems (CAS) into our management assumptions and practices. Complexity scientists have studied the collective behaviour of living systems in nature such as the flocking of birds, schooling of fish, marching of ants and the swarming of bees. They have discovered that, while the individual “agents” in these complex adaptive systems possess only local strategic rules and capacity, their collective behaviour is characterized by an overlaying order, self-organization, and a collective intelligence that is greater than the sum of the parts. The theory of CAS has been applied successfully in several areas – economics, life sciences and more recently, to management. These concepts of CAS led to the inspiration that like the XP team, project managers also need a set of simple guiding practices that provide a framework within which to manage, rather than a set of rigid instructions. Following these practices, the manager becomes an adaptive leader – setting the direction, establishing the simple, generative rules of the system, and encouraging constant feedback, adaptation, and collaboration. This management framework, covered in detail in Section 4, provides teams implementing agile methodologies with:
An intrinsic ability to deal with change
A view of organizations as fluid, adaptive systems composed of intelligent living beings
A recognition of the limits of external control in establishing order, and of the role of intelligent control that employs self-organization as a means of establishing order
An overall problem solving approach that is humanistic in that:
It regards employees as skilled and valuable stakeholders in the management of a team.
It relies on the collective ability of autonomous teams as the basic problem solving mechanism.
It limits up-front planning to a minimum based on an assumption of unpredictability, and instead, lays stress on adaptability to changing 