By Gary Chin
I've reviewed several project management books lately, and so far this is the best-of-breed in terms of defining agile project management, describing its need, and setting out a list of concepts for understanding it. The book isn't a set of heuristics and principles, nor is it a methodology, but it provides a solid basis for those other sorts of books.
Starting in the Preface, Chin argues that highly innovative businesses, especially those that push the limits of current technology, face challenges in discovery and planning that have not been encountered before. Such projects have inherent uncertainty, and face multiple paths, decision points, and iterations. Classic project management, he argues, is simply not set up for that sort of problem (p.vii). He ties this issue to the advent of the knowledge-based economy and acknowledges that although project management could be a key advantage for smaller businesses in this economy, classic PM is not well suited for helping them (p.ix).
It's not that classic PM is broken, he argues in Chapter 1, but it's been overextended. Agile project management is seen not as yet another extension, but a new foundational element (pp.2-3). The focus of agile PM moves from planning to execution -- a necessary move because
Agile PM Environment = [Uncertainty + Unique Expertise] + Speed (p.3)or, in other words, the agile PM environment involves specialized problem solving that has not been done before, at the edge of experience, with rapid development. It's for startups in particular. Think in terms of software development, but also other lightweight tech-heavy development such as search engine optimization, social networking, and social media marketing. Organizations functioning in this space have "gurus" rather than interchangeable resources, working on problems that change from day to day, opportunistically incorporating new technologies to accommodate a rapidly shifting environment with both internal and external uncertainties. In contrast, classic project management assumes familiar problems, interchangeable expertise, unchanging objectives, and minimized internal and external uncertainty -- all signs of more mature industries such as construction.
I've discussed emergent organizational structures such as networks, federations and coworking on this blog. Chin doesn't quite get there -- he is still envisioning single organizations, multiple organizations, and single companies within multiple organizations (pp.17-20). Yet he edges closer to a federation understanding in Chapter 3, when he argues that in smaller companies, projects are the business (p.22) -- that is, a single project might be the central activity of the startup. In such an environment, classic PM, with its emphasis on project boxes that cut across silos, is not wholly applicable (p.25). Naturally, a project-driven organization is better suited to agile project environments (p.33).
In agile spaces, Chin argues, teams need to be boundary-crossers in order to solve new, multidimensional problems (p.43). Agile decision-making must be decentralized as well, pushed down to the level of the local team when possible (p.46); it is rarely handled through formal authority, most frequently through personal credibility established during the project (p.69). "The agile project operates in an atmosphere of high interactivity, boundary crossing, and multiple simultaneous pathways," he adds (p.79), which is to say (in my terms) that agile PM is a result of splicing dissimilar activities. It's not surprising (to me) that he points to telecommuters as good candidates for agile projects (p.94).
Chin goes on to offer some heuristics and practical approaches to implementing agile PM. But the real value in this book is Chin's sharp eye for the connections between classic and agile PM, grounded in the differences among organizations, industries, uncertainty, speed, and expertise. It's a great book for getting an overview of agile PM rationale.
1 comment:
Some person still want to use waterfall Model. I think following link will help them to move out from Waterfall model
Moving Waterfall model to Agile Software Development
Post a Comment