The desire to be agile has long impacted human behavior. Consider the elite athlete, the army general, the opera singer, the belly dancer, the professional golfer, the heavyweight boxer, the high seas sailor, the commercial pilot, the top-end banker, and even the federal politician — they all love agility, and so do we. Why? Put simply, agility provides the basis for adaptability and change which, in turn, are integral to our survival and growth. The same agility that enables a springbok to outrun a lion or an ant to carry a load more than 20 times its size allows a small start-up in Southern California to prevail against the might of a large, well-established brick-and-mortar organization (based on my arguments in the preface to my book, The Art of Agile Practice: A Composite Approach for Projects and Organizations). No wonder mainstream business is increasingly fascinated by “Agile.”
In a special issue of Communications of the ACM commemorating the first 50 years of computing, virtual reality pioneer Jaron Lanier wrote: “The biggest surprise from the first 50 years of computers is that computation turns out to be a cultural object in its own right, with all its warts and semicolons.” This phenomenal importance of “human issues” in IT project management has also found its way in discussions by Cutter Fellows Tom DeMarco and Timothy Lister in their book Peopleware: Productive Projects and Teams; Gerald M. Weinberg’s The Psychology of Computer Programming, and Larry Constantine’s Constantine on Peopleware and Soft Issues and Other Hard Problems in Software Development. Indeed, Constantine claimed: “Good software does not come from CASE tools, visual programming, rapid prototyping, or object technology. Good software comes from people. So does bad software.” I have also discussed the importance of people in software projects and the destructive nature of “game playing” — together with suggested antidotes. These discussions led to an inescapable conclusion: the dire need to address the social and cultural factors in project management. Contemporary Agile emerged out of the exploration of such issues in software development projects. Agile helped the software development community climb out of its cellars of up-front planning, analysis paralysis, and siloed (primarily driven by the waterfall lifecycle) approaches to the users and business.
Unlike construction and manufacturing, which are “linear” in nature, software projects tend to be “fuzzy” and continuously “changing.” I consider their nature as “amorphous,” with the output not as clearly visible and measurable as that of building a house or manufacturing a car. Yet, the project management frameworks (e.g., PMBOK and Prince2 ), techniques (e.g., WBS, Pert/CPM), and corresponding tools (e.g., MS Project) are all based on a “linear” engineering paradigm. Applying engineering principles to software projects helped in early information systems days but, with growing size and complexity, the same principles led to many challenges (such as those very well documented by Robert Glass in Software Runaways: Monumental Software Disasters). Experience suggests that the nature of software projects is far less organized than construction and manufacturing. This could be one of the main reasons why the field of software development picked up on Agile — because the many subdisciplines of software are closer to art than engineering (see The Art of Agile Practice), and Agile is much better suited to this type of work. While we do have many right-brained subdisciplines of computer science and wireless networking, when it comes to developing software there is very little engineering in it. Besides, the “success” criteria of the software output is heavily dependent on the subjective viewpoints of the user. Furthermore, the needs and the wants of the users of software systems are continuously changing and demand continuous attention.
Figure 1 depicts a simple mindmap of Agile, which is based around the Agile Manifesto. The Agile Manifesto encompasses key values of Agile: trust, simplicity, honesty, and courage, amongst others. A cursory glance at these values tells us that these are universal human values, and that they do not pertain to anything specific to software. In fact, it will be hard to find a plan-driven hierarchical project manager who would not want these values in his or her project. The Agile movement deserves our gratitude for extracting these human values and applying them nicely to the field of software development. We can credit the successes of Agile-based projects to these characteristics of individuals, their ability to collaborate, and their capacity to take on and absorb change. However, the Agile practices and methods (mindmapped in Figure 1) are not entirely right-brained; they do need certain planning and discipline (left-brained activities) for Agile to succeed in practice. The need to understand and apply Agile as a balanced psychosociological paradigm could not be greater.
While the roots of Agile lie unequivocally in the IT domain, the popularity of Agile transcends the software development space. This places responsibility on us, the IT community, to understand the psychosociological basis of Agile. In what ways do you think Agile would be well served by exploring the connections between knowledge, culture, psychology, and technology?