Managing Agile Projects is a book edited by Kevin Aguanno, a noted speaker and educator on agile project management. It describes techniques for managing projects in environments where the scope is constantly changing. This book is about techniques common to nearly all of the agile development methods (Extreme Programming, Scrum, Feature Driven Development, DSDM, Lean Development, Crystal Methods, Agile Software Development, Agile Project Management, etc.) that you can use to reduce risk, improve quality, and dramatically increase customer satisfaction in high-change projects. Chapters were written by the gurus of the agile movement: Scott Ambler, Alistair Cockburn, Ron Jeffries, and many others.

All author royalties from this book will be going to the International Red Cross for disaster relief.

A good time for me to have an interview with the editor. 

One could think “Another book on agile?” What makes this book different from the rest?

[KA] Almost all the other books on agile are focused on explaining agile methods to technical teams (programmers, architects, tech. team leads, etc.) This book focuses more on explaining the business benefits from employing agile methods and some techniques for controlling these projects. The BIG differentiator is that this book is targeted at project sponsors, project managers, and development managers. These more business-focused managers may have heard their teams are considering agile methods, and want to know more about the methods and also how to manage/control them. The book is about dispelling fears and explaining how agile can find a place in their existing management structures.

Why did you decide to create the book?

[KA] I am a senior project manager who primarily works on custom software development and systems integration projects. In these types of projects, changing requirements and technical uncertainty are a daily reality, unlike more production-driven projects that can be better controlled with more predictive processes. I am regularly faced with the challenge of trying to structure and control these custom development projects to meet aggressive timelines while still following “best practices.” Naturally, I began using techniques such as XP, Scrum, and FDD; however, I found my biggest challenge was not getting the buy-in of the technical teams — they already read about these techniques in their magazines — but rather the business executives who fear terms like “extreme” and see these methods as introducing unacceptable levels of risk. I saw that some education for executives and senior managers was required that explained how these methods actually are used to REDUCE risk. They needed to hear how these projects are structured, controlled, and managed. Finally, it is an uphill battle to introduce agile techniques into any organization, so I thought it was important to devote a chapter to explaining the topic of Stealth Methodology Adoption — a technique for packaging and introducing agile techniques to make them more palatable to the organization. With such a strong belief in the need for this book, I felt compelled to put it together.

Such a respectable team of contributors? How did you get them together?

[KA] Getting the buy-in of the other contributors was rather easy. I had first planned out what topics I thought the book needed to cover and then vetted that content with a few target readers. Given their feedback, I was able to prepare a chapter plan that divided the required content into chapters. Once I knew what I needed, I went out and did my homework, looking for top-rated articles (where I could find them) that fit one of the required chapters. When I could not find existing content that filled one of the slots, I asked authors who were known in the industry for their expertise in the specific area to write one for me. With only one exception (due to copyright restrictions) every contributor immediately came on board with the plan. I was surprised at how easy it was to get everyone’s agreement.

Do you remember your first transition from traditional PM to agile PM?

[KA] I think it was back in the mid 1990s when I finally realized that the way I was doing things didn’t seem to work well for the eCommerce and other Web projects to which I was being assigned. I realized that I didn’t have the right tools in my toolkit for managing these projects and began to look for better (more appropriate) tools. I first came to RAD and used that for a while, realizing the benefits from iterative and incremental development approaches. But more structure was needed, and I continued to search, eventually finding Extreme Programming, Scrum, and FDD. I have used these now for several years and have enjoyed great successes in doing so. While I don’t believe that Agile methods are ideal for every project, I do find that they are the tools in my toolkit that I grab most often, given the kinds of projects I manage.

What did you find the most interesting “new” fact or insight when compiling the book?

[KA] For me, I think it was the tight link with traditional methods. Agile methods are not all that radical — these techniques have existed for many years, and indeed are just evolutions of what previously existed. When you look at “the history of agile,” you will see that the techniques we have packaged into our named methods (XP, Scrum, etc.) were used long ago, we have just grouped them together and formalized their interactions. We have cobbled together methods from existing techniques — there is little revolutionary in the techniques, but much in the thinking behind the methods. Agile methods are a mental revolution, but a technical evolution.

In your introduction you write “While agile methods may not fit every project..” What makes a project suitable for agile methods? Is there still a role for “traditional” methods?

[KA] Definitely. Agile methods work best on projects where high levels of change are expected. Changing requirements, technological uncertainty, the need to experiment and evaluate different approaches to see which one works: these are the factors which indicate agile methods might be a good choice. However, some projects are fairly stable. Change is not going to be a big factor on these projects. Also, since all agile methods use iterative structures, and some projects cannot effectively use iterative development for their main deliverables, traditional sequential techniques still have a role to play. I tend to think of these non-agile projects as “deployment” projects — where the design and development are already done, we are just looking at installing and testing the products. I was once involved in rolling out a chip upgrade to thousands of cash registers across the country — on a project such as this, agile methods did not provide much value — though I did use a few techniques stolen from those methods.

An important factor within agile is colocation, as I understand it. How do you see this in respect to offshore outsourcing of development?

[KA] Colocation is definitely the ideal. Wherever possible, I have my development teams working together. The reality is, however, that most of my projects are rather large, and that the development teams can be scattered. On one project, I had almost 200 developers in 17 cities across North America and India. General colocation was not possible, but I WAS able to assign individual components to colocated teams where possible. I centralized the cross-component interfaces so that one colocated team (composed of members from each distributed component team) could work out all of the issues in one room. Finally, we can use technology to lessen the impact that distance introduces. Cockburn has a wonderful diagram that shows how different tools (such as teleconferences, instant messaging, screen sharing, etc.) are placed along the continuum between face-to-face interaction and communicating via documentation. When scattered teams are a reality, we can use daily teleconferences, instant messaging, web-based document repositories, etc. to increase the communication bandwidth and reduce communication delays.

If someone applies for an IT Project Management job a PMI certification will help him more then e.g. being a SCRUM master. Why is this in your opinion? Will this change?

[KA] Both of these are primarily a knowledge-based certification. Neither proves that the recipient is actually competent at what they do. So, removing competence from the equation, all we have left is ascertaining which knowledge certification is more valuable. I think that learning all of the project management techniques and best practices takes a lot longer than learning the techniques such as Scrum. If I needed someone with both, it would make sense to me to hire the one with the PM knowledge certification and teach them the Scrum practices on top of that, rather than the other way around. I also feel that PM knowledge must be complemented by IT knowledge for a PM to excel in managing IT projects. But underlying this discussion is still the need to choose candidates that can demonstrate the personal characteristics that one cannot learn from a book — honesty, open communications, self-confidence, ethical behavior, leadership, etc. — I look for these items first, as the rest can all be taught in a classroom.

If someone is working in a large corporation that uses “heavy methods”, how can he convince senior sponsors to let him go the “agile way”? How does your new book help in this respect?

[KA] I have a chapter in the book on this called “Stealth Methodology Adoption.” The chapter is quite involved, and I could not reproduce all of its main points here, but one of the key techniques is to avoid the concept of “selling Agile” at all. Instead, propose adptations of the existing methods that incorporate some agile techniques, one by one, and explain how they are being done to reduce risk, improve quality, etc. Don’t brand the changes as “Extreme Programming” or any other methods, but rather just call them tweaks to the existing method. That way, you can slowly adopt more and more of a method without earning the ire of the “process police.” See the “Managing Agile Projects” (www.agilesecrets.com) book for more details, or you can buy just that portion of the book as a Palm Reader (PDB) eBook at www.mmpubs.com/publications.html.

Do you have plans for another book?

[KA] Yes, I have one in the works on career development for project managers that helps them plan out what they can do next after they have attained their PMI certification (PMP). It is called “Beyond the PMP: Advanced Project Management Certification Options.” I also have a half-completed manuscript called “Project Closeout Best Practices.” I have plans on writing a book at some point on Scrum for non-IT projects as well.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Managing Agile Projects is a post from: Project Shrink.