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:

  1. Agile Development requires little to no planning
  2. 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.

Stephen Smith                 05e65fd

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:

image

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 ERP implementations. While I certainly see Agile working in many other places (some noted below) the actual implementation is not one of them. The reason is that ERP projects tend to be more holistic in nature. For example, you cannot get the full value from an inventory tracking process without having first set up a properly structured general ledger. Agile call for prioritizations that make no sense in the context of ERP.
  • Agile makes a ton of sense for CRM projects which a normally more development related than ERP. With ERP, ultimately debits must equal credits (i.e., conform to GAAP), with CRM there are no rules.
  • One area where Agile could make sense for ERP 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.

7 thoughts on “On Agile Project Management

  1. I suggest you look at the following article by Alan Shalloway:
    http://www.netobjectives.com/blogs/difference-between-inspect-and-adapt-and-plan-do-check-act-pdca
    I think you will find the plan-do-check-act process compatible with your fixed price contract.
    Also, the concepts of work-in-process, WIP, and time boxing will work in ERP implementation. Rather than starting implementation of everything, some AR, some AP, some IM, focus on one module and setup everything prior to moving to the next module. Use time boxing to set the intervals at which you check in on your progress and communicate/check in with the customer.
    You tagged Scrum in your post and this may be why you have had trouble reconciling Agile with fixed price work. Scrum is just one Agile methodology designed with particular constraints and isn’t suitable for all situations. If you stop and check your progress at regular intervals and adapt your process for the next iteration then you are being Agile.

  2. Thanks for you comment Robert. I will do some more investigation. As I hope was clear, I am not an expert on Agile in any way. Any thoughts on key concepts are certainly appreciated!

  3. Ed,

    First, let me give a shout-out to my Agile/Scrum instructor Erin Beierwaltes at Skipstone Consulting (erin@skipstoneconsulting.com, http://www.skipstoneconsulting.com). She was excellent, and has the holder of multiple certifications (including PMP and CSM) which enables her to bridge the gap between the waterfall and agle methodologies.

    While I agree that an ERP implementation is holistic in the sense that it is not an option to only complete a subset of defined tasks, and to do them in a potentially constantly changing order, there are several Agile principles that are useful. As Robert suggested above, timely, regular communication (which is built into the Scrum methodology) is important in any project. More frequent opportunities to regularly check in with the client and solicit feedback can only improve the results over a project where we hand over the results to the client only at the very end.

    Rick

  4. Ed,
    Unfortunately, over the years, specific processes have been established with “agile” in their name, or “agile” as a reference. Then two groups form (have formed), the ones that are all for it and the ones that are against it. Both start to convince the other of what is better. I believe this happens in any case where a methodology, framework or “standard” is established.

    This, of course, causes confusion. Walk into a room and say “Agile” – people think of the noun – people don’t think about the Agile Manifesto, they think of all the processes that have “sort of” been derived from the Agile Manifesto. I believe that is inherently wrong.

    I could write a book about this – maybe I will – but the point is, we have to focus on adjectives (agile, lean, etc), not the nouns. Being agile can help any project, at any level. Applying the Agile Manifesto can do the same. Maybe applying scrum directly won’t work – but again – scrum is not the definition of agility. It is merely *one* way of being agile, for a particular set of situations.

    We spend more time talking about specific situations, and specific processes, than we do about our method of thinking, and our willingness to think differently. This I feel is the core of the Agile Manifesto – it’s not that there is one process – rather, to be agile, we must define what our end goals are, exit the jail of tradition, buzzwords and marketing, and use our own thoughts and experiences to define a flexible process/model that fits that situation. Next time, our process/model may work, but it might not, and we should be prepared to change it, or think up a new one.
    They might all apply: Scrum, TOC, TQM, JIT, WIP, etc, etc, etc…

    Maybe thats too philosophical?

    -Ralph

  5. Ralph, thanks so much for your comment.

    Too philosophical for this site… no way!

    I am a huge adherent of Peter Block’s belief that ALL change is linguistic. Words mean things and very important. Thanks for adding to the dialogue!

  6. Thank you for this very long challenge on presuppositions. I have a few more. I am searching for answers although my questions often sound like gainsaying. This is not my intent.

    I do not think product development (and in my case, software development) is a team sport. I think it is more closely related to fighting a war. Developers are the expendable, filthy, unwashed occupants of the foxholes on the battlefield of the development hill. At least that’s how I’ve always felt.

    Every level up, all the way to the client sitting back there at home in complete comfort without any concept of the fight, loses touch with the developer. Nothing — not agile, not waterfall, not mystics with Magic-8-Balls, not tools, and certainly not meetings — has broken through that social and cultural barrier that exists between the people who know the technology and the people who buy the technology.

    While I must learn to trust, implicitly, the talents and skills of my fellow developers (and those in the foxholes with me), I rapidly lose trust of the managers and further up and up and up until I fully distrust the project managers and the client.

    Agile has never helped this feeling of isolation. It has only left the managers and up and up and up and all the way to the client with a false feeling of visibility and control.

    I believe this is because “process” always overtakes interaction and negotiation is the very soul of management. Therefore, “agile” breaks what I perceive as a fundamental human instinct that middle management always leverages to its advantage — distrust.

    Further, I perceive that “agile” is so very popular because it either pushes down or pushes up, leaving the manager and the client perceptibly free of responsibility. It pushes estimates, timetables, product, testing methodologies and results, and the coding of a software product down to the foxhole. It pushes clear instructions, communication of expectations, budgets, calendars, and priorities up to the stakeholders and clients (while calling all of that communication).

    Unfortunately, it fails at providing these newly-burdened players with the real understanding for their new duties, and certainly never provides rewards for these extra obligations. Just getting the joy of being “agile” is supposed to be the reward unto itself.

    I have asked many questions in this screed.

    Can Agile and Human Nature be reconciled?

    Is there anything, short of chasing all management into the sea that will get those in the foxhole and those in the leather chairs talking?

    Is there any approach that effectively deals with the innate isolation of product development?

    Are there any happy developers in agile? (I ask this because I’ve never heard of any. I hear of happy clients and happy managers, but I think that’s always at the expense of the guy in the foxhole.)

    I look forward to a public dialog.

  7. You are raising some excellent points. However, I am not sure if the distrust to which you refer is limited to Agile or any other project management methodology.

    Gary Hamel in has last two books, The Future of Management and What Matters Now, goes into great depths as to why distrust is pervasive throughout business. “We need to make organizations more human,” he says.

    I believe you and he are onto something. Thanks for your comments.

Leave a Reply