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. 

I am sorry to inform you but Project Management as we know it is dead. Plan-driven approaches are dead. Agile will be dead before it hits the masses. You have no idea how I hate this fact. It makes me sad. Heck, it makes me mad!

Come to think of it, I wonder if it ever was alive. The fact that it seemed to work in the past is no guarantee that it ever was the proper way to do projects. It was not if we had evolution in the field. We didn't start out with a gazillion ways to do things and in the end only a few survived because they were the best. There is no comparison, so who knows.

Why the fuzz now all of a sudden?

As a Project Manager I am now more than ever faced with the fact that part of my teams are at the other end of the world. Different cultures, different time zones, different languages, different customs. Different. Worse? Nope. They are very good, very skilled. I would even say excellent. But I hardly see them, let alone know them.
Read more

If you are considering a career in Project Management, I welcome you and congratulate you on a perfect choice. The future is ours. Managing projects is a skill that will be requested more and more in the near future. There will be more projects in the future. And the amount will only increase.

For software projects we will see an enormous amount of projects with small complexity. Just complex enough to justify calling it a project. Small and medium sized companies are stepping up the pace to further automate their processes. But they will use out-of-the-box applications that don't need much customization to do this. This to avoid huge bills on IT. These applications don't even run on the companies servers; the software is offered to them as services they rent. This type of project will become the majority of projects to be done. This can be called the long tail of software projects.

The fat head will be made up of a far smaller number of projects with enormous complexity. For example the projects that create the software that will be rented out to these small companies.

If you are considering training in Project Management you can opt for PMBoK or Prince 2, the fat plan-driven methods that are controlling many projects today. But they will only serve you if you are aiming for the fat head (and even than we are still not sure). If you are finding yourself in the Long Tail of Software Projects, you will need something lighter, something that complements the applications for the mid- and small sized companies: project management out-of-the-box, not too much need for customization. Oh yeah, and cheap.

Should we talking about "agile" for the long tail? For a part agile methods can assist here. But if we consider the properties of the tsunami of projects that await us:

• Rigid software solutions (not much software customization)
• Relatively inexperienced customers concerning IT implementations (small companies)
• Very tight budget
• Lot of virtual working because of small budgets and multiple projects for teams
• Lot of outsourcing to different countries and cultures

And this is exactly a profile not suited for agile methods.

Stay tuned to this blog as we will try to find out how we can serve the long tail in software projects.

I am currently preparing an introduction for IT people in PM methods. While struggling to come up with a way to provide a fast overview of a method, I came up with the following: the four mechanisms of PM methods. A short description of how these mechanisms function within a certain method, works quite well as a fast introduction.

Decisions: A project is a game of trade offs. There is always a need to balance resources, money and time towards certain goals. Because nothing is unlimited, because you are dealing with scarce resources decisions have to be made for which purpose resources are allocated. A method provides a mechanism to make those decisions.

End Result: The goal of a project is to solve a problem or to take an opportunity. There is a reason why a project is performed in the first place. With all decisions that have to be made, with all the changes in the environment that take place a method provides a mechanism to keep the eye on the price, to keep a project pointing to a certain direction.

Resilience: "Change" is a projects middle name. Uncertainties and changing certainties are the environment in which project have to operate. That is just inherent to the nature of projects. How a project deals with changes, how it absorbs or adapts to uncertainties and shifting targets is a major component of the method.

Tailoring: Not all situations are created equal. Different circumstances make different projects. What is effective and desired in one situation may be complete irrelevant and harmful in other situations. A method will provide a mechanism to tailor the method itself to the circumstances.

There are not many books available that cover the topic of when to apply an agile or plan driven method. In my opinion the selection of when to apply a certain technique or process component remains the most difficult area of Project Management. I only know of two books that cover this in detail, my own and "Balancing Agility And Discipline" by Barry Boehm and Richard Turner.

First of all, the fact that the book is written by Boehm and Turner is remarkable. Boehm wrote the classic "Software Engineering Economics", formulated Theory-W, invented the spiral model, a true influential pioneer. Turner helped shape the CMMI model. So, both respected "old school" software engineering professionals. The fact that they try to have an impartial look at agile is an accomplishment on its own.

The book provides insights in when to apply agile methods and when to apply plan-driven methods. The authors argue that for every type there is a kind of project that is suited for one of the approaches. Or a kind of combination.

Five factors are considered influential when considering an approach:

• Critically: if the end result doesn't work, are people going to die or is it a minor inconvenience?
• Personnel: how good are your people?
• Dynamism: are requirements changing all over the place?
• Culture: do people like change or do they need order?
• Size: how many people are involved in the project?

Presented is a risk-driven approach to select the proper method. Some general project environment risks (E) are considered, risks associated with the use of agile methods (A) and risks that occur when plan-driven methods (P) are used. An assessment of these risks should help you to make a proper choice of method.

The risks are:

• E-Tech: Technology uncertainties.
• E-Coord: A lot of stakeholders to coordinate.
• E-Complex: The complexity of the system.
• A-Scale: Scalability and critically.
• A-YAGNI: Use of simple design or YAGNI (You Aint Gonna Need It).
• A-Churn: Personnel turn-over and churn.
• A-Skill: Not enough people skilled in agile methods.
• P-Change: Rapid change.
• P-Speed: Need for rapid results.
• P-Emerge: Emergent requirements.
• P-Skill: Not enough people skilled in plan-driven methods.

What I find very useful is the appendix with a comparison of a lot of methods like Scrum, RUP, Crystal, CMMI etc.

Although the book is very dry, although you don't get a ready recipe for success (duh!), this book will make your mind better suited for balancing different methods.

Project Managers with experience know that the traditional ways of doing PM are not sufficient any more for all our project situations. You need more tricks up your sleeve to pull it all off. That's why I follow eagerly the techniques that are coming from the agile PM camp. But I have a hard time integrating them with my own views, at least in the ways they are expressed by practitioners. Glenn Alleman provided me with the final "aha" I needed in this direction in his posting : Agile PM is not discussing project management as such, but more the management of software development using agile processes (where the agile-part is in software development).

He raises some very interesting issues I agree with. Software development can be a part of a project, but a project always has a broader scope of activities, so limiting yourself to only development leaves out some aspects. And before we go this way, let me just start now : yes, it is important for a PM to know software development practices. Not to perform them personally, but to be able to communicate intelligent about the subject: "where are the risks, is he or she bullshitting me… ?"
Read more