On Agile Project Management
Over the past few years, I have been hearing more and more about Agile development project management. For the most part the conversations have not been very positive.
This is not because I think there is something inherently wrong with Agile, but because those that espouse it have always tried to convince me of two things:
- Agile Development requires little to no planning
- There is no way to do agile development in a fixed price environment
You can imagine that I begin to shake violently at either of those ideas.
In the past month I have had two conversations that have corrected some of these misgivings. Mostly because I have come to the conclusion (confirmed by my conversations) that the folks with which I have had these previous conversations about Agile were full of shit.
The two conversations - one with Stephen Smith, Chief Architect at Sage, the second with Rick Cobb, senior ERP consultant at Blytheco - have enlightened my thinking when it comes to Agile.
Rick had just taken a class and was kind enough to take me through the materials. I found that in many ways I am in alignment with many of the principles of Agile. For example, I really like the idea behind this:
Now, I would enhance the idea of customer collaboration to a more broad idea of comprehending customer value. Indeed, one weakness of all of the project management methodologies I have seen is the assumption of customer value. In all fairness, it is difficult to integrate value into any methodology because of it subjectivity, but that is for another post.
My conversations have led me to a few conclusions, all of which I am open to change based on more learning.
- Agile is probably not for most knowledge worker projects. While I certainly see Agile working in many other places (some noted below) one-time knowledge projects (such as an implementation) is not one of them. The reason is that implementation projects tend to be more holistic in nature. For example, you cannot get the full value from one aspect of the engagement without having first set up another element of the project. Agile calls for prioritizations that make no sense in the context of these types of engagements.
- Agile makes a ton of sense for any iterative type projects which are normally more creative in nature than say ERP implementation. For example, with ERP, ultimately debits must equal credits (i.e., conform to GAAP), whereas with CRM or web-site development there are no rules.
- One area where Agile could make sense for implementation type projects would be in dealing with change requests and change orders. Often, these are mini-development projects and therefore Agile might be quite effective. I say might because on small engagements, some of the change requests might be so small as to only need an adjustment to the statement of work.
- Another area where Agile excels is in communication. The daily standup meetings and one to two week scrums have some excellent communication touch points built in. I hope that when Agile is implemented that these processes are truly adhered to. There are definitely some things that Agile can teach us about better communications.
Ultimately, I think Agile is very much in line with the concept of results oriented project management that I presented in this space a few weeks back. This gives me some hope for being able to integrate some of the best idea from both methodologies into one more coherent approach.
My thanks again to Stephen and Rick who contributed to my thinking about this post.
