Why Agile Project Management?
by Jim Highsmith, Director, Agile Product and Project Management Practice
I was recently rereading one of my earliest e-mail Advisors from this Agile Project Management Practice (it was actually e-Project management then). The Advisor was about why this different way of managing projects was so important. After reading it, I decided it was time to revisit and update that issue.
One company struggles with a large project with critical time constrains and ever-shifting requirements. One and one-half million lines of code -- in a cell phone, and that's just the beginning. "My project has critical time constraints and the requirements are evolving constantly (brought about by changing industry standards) during the project, because of turbulence in the wireless telecommunications market, so that generating and maintaining the range of documentation required for a typical corporate project would doom this one."
A company with an extensive human resource product line struggles with growth (over 500 engineers), rising complexity, and demanding customers. A functionally oriented organizational structure (product management, development, QA) and expanding feature requirements limit necessary collaboration and lead to slipping schedules and quality issues.
A worldwide, multibillion-dollar media company struggles with new product introduction as Web-based delivery platforms evolve and competition requires innovative and easy-to-use new products.
Innovation, complexity, change, size, uncertainty, growth, globalization, and more are factors that software development organizations must deal with today. Historically, development methodologies dealt well with one or two of these dimensions but not with all. Traditional methodologies dealt well (sometimes, at least) with large size and complexity, but not well with innovation and change. Rapid development methodologies of the early to mid-1990s dealt well with innovation and change but not well with size and complexity.
A software development methodology is actually a strategy for success, and as such must prioritize objectives. An agile approach builds on a common framework of principles and practices, but even more important, one of those principles encourages us to adapt to change; to adapt to different objectives and constraints on a project. However, given the business environment today, there are certain challenges for which agile development excels.
The number-one challenge of agile project management is creating a culture of innovation -- everything else pales in comparison. Agile projects often attempt to implement the new, the untried, and the nearly impossible -- this is not the problem domain in which controlling tasks to achieve a fixed plan will succeed. This is a problem domain that demands the innovative exploration of possibilities.
The underlying assumptions of traditional project management are predictability and control: project managers expect progress to mirror the plan, and they expect to exert firm control over that progress. Whereas traditional practices focused on the mechanics of scheduling, task planning, and monitoring, agile project management focuses on innovation, collaboration, decision making, knowledge management, fuzzy planning, and exploratory development.
In that earlier Advisor, I defined agile projects in the following way:
Agile projects are large projects that must be delivered rapidly, that are both research-like and mission-critical, and that have to be managed in a turbulent business and technology environment.
The statement is as valid today as it was five years ago. There are quite a few significant words in the statement: rapidly, large, research-like, mission-critical, and turbulent. Each requires some elaboration. First: rapidly. There is no question that the pace of business has accelerated. While many bricks-and-mortar companies don't necessarily have to be first, they can't lag too far behind. There are still great demands on schedule. But, we are learning that if we focus exclusively on schedule, bad things tend to happen as quality is sacrificed. Agile projects are teaching us that the right focus points are customer value and quality -- within predefined timeboxes. Meeting a schedule with poor quality and unwanted features is hardly a success. Agile projects have changed our views about what is an objective (value, quality) and what is a constraint (time).
The second issue raised by the above definition is size. In the earlier days of agile development, smaller projects were the norm. Today, companies are tackling all sizes of projects -- even the very large with hundreds of people -- with agile concepts and practices.
The third issue is research-like. Research projects are characterized by risk and uncertainty -- risk relating to things that you anticipate might go wrong and uncertainty relating to things that might go wrong that you don't even know about. Research requires exploration rather than a fixed plan. Research is synonymous, at least for our purposes, with innovation, and innovation today is focused on the top line of business: the revenue line. Innovation has become the hot topic in business in 2006 and this focus should continue. Agility is one key to achieving high levels of innovation.
The final issue in the above definition is turbulence, which causes projects to acquire research-like characteristics. For example, SOA concepts and technology are emerging, there are many competing vendors, and experience in doing SOA projects is limited. SOA may change business models -- or maybe new business models will change SOA. Web 2.0 may be the next wave of Internet-based business models or it may just be a technology that suffers for lack of a problem to solve. There is one TV commercial in which a store morphs from one business to another in moments as one business model succeeds another in real time. Turbulence, and change caused by that turbulence, continues to be a major factor in business in this decade.
High speed, high quality, and high change -- with a dollop of uncertainty thrown in -- define a type of project that agile project management addresses well. These projects may be similar in some ways to traditional projects, but they require more innovation than optimization, more discipline than formality, and more adaptability than control. The fundamental business environment that produced the need for agile project management five years ago is as valid today as it was then.
-- Jim Highsmith, Director, Agile Product and Project Management Practice
Did you enjoy this article?
Talk to Cutter today about membership, including one-on-one guidance from and interaction with Cutter's experts and with their peers, access to research, webinars, podcasts, white papers and more.Request trial membership