Alec the Geek

or “My big fat geek’s blogging”

Agile projects vs. Change process

Regular readers will remember that a while back I wrote a few posts talking about the job of a ticket process to manage changes and issues; and more recently I have banging the drum about the wonders of Agile development. How can I reconcile what appear to be two conflicting approaches?

Well the answer is of course that they are talking about two different things; and at two different levels even. What follows it a little simplistic, but I hope will illustrate the point:

Agile Projects:

  1. Are delivered by a team over a period of months.
  2. They are projects — i.e. the contain novel activity which can be difficult to plan at the start of the projects
  3. They may well be a capital expenditure item
  4. They address multiple requirements (more than one story)
  5. They (hopefully) have fully engaged customers as part of the team
  6. They are are focused on delivering new business value

Change Process

  1. An ongoing process to apply fixes and minor improvements to a production environment
  2. Each piece of work or change may be very small
  3. The issues are often well understood and it is ‘easy’ to estimate costs, impacts etc.
  4. The budget process is different (e.g. operational)
  5. Has a smaller team with limited customer involvement
  6. Often start and stop work because of external and operational constraints

So the management of Change Process is, in many ways, a completely different issue. We need to:

  1. Plan many smaller pieces of work and roll them up into releases for production.This is slightly different to planning stories for iterations because there are issues beyond creating new business value for customers.
  2. Track the smaller conversations we have with our customers so we still understand their needs and time constraints
  3. Be able to adequately document changes so that we can pick them up and put them down as our operational needs change
  4. Keep track of costs for budget purposes
  5. Make sure that operational, organisational and statuary requirements are satisfied for each work piece
  6. Reduce costs (maintenance is a far higher proportion of software costs than development) with better process and more automation

So choose the Agile and Process based work practices that appropriate to the current phase of your Application Lifecycle, and make sure you evolve it as your needs change. There is NO one size fits all. (seem to have heard that one before!)

5 March 2007 - Posted by Alec | Application Lifecycle Management, Software Development, Work Practices | | 2 Comments

2 Comments »

  1. Change Management is a core Project Management function, and it is critical to achieving success. This is because change usually affects your ability to deliver your project within scope, therefore increasing your costs and delivery timeframes. Give your team a clear set of guildlines by using a formal Change Management Process such as Method123 http://www.method123.com/change-management.php. It will give you a clearly defined tool for managing change effortlessly within projects.

    Comment by Eve Sheridan | 9 March 2007

  2. I thought I would allow the above spam comment into my blog so that I can state that THIS IS NOT WHAT I AM MEAN when I talk about appropriate process.

    Persuading yourself that you are managing a project through the repeated completion of someone else’s check lists is self delusion best and insures that you’rr driving with your eyes shut towards a nasty crash. Actively review and develop your own process and tracking mechanisms as required — and keep reviewing throughout the project!

    (of course initially basing your process on existing best practice is a good start, but don’t use it as a cop out)

    Comment by Alec | 10 March 2007

Leave a comment