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:
- Are delivered by a team over a period of months.
- They are projects — i.e. the contain novel activity which can be difficult to plan at the start of the projects
- They may well be a capital expenditure item
- They address multiple requirements (more than one story)
- They (hopefully) have fully engaged customers as part of the team
- They are are focused on delivering new business value
Change Process
- An ongoing process to apply fixes and minor improvements to a production environment
- Each piece of work or change may be very small
- The issues are often well understood and it is ‘easy’ to estimate costs, impacts etc.
- The budget process is different (e.g. operational)
- Has a smaller team with limited customer involvement
- 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:
- 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.
- Track the smaller conversations we have with our customers so we still understand their needs and time constraints
- Be able to adequately document changes so that we can pick them up and put them down as our operational needs change
- Keep track of costs for budget purposes
- Make sure that operational, organisational and statuary requirements are satisfied for each work piece
- 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!)
2 Comments »
Leave a comment
What’s it all about
Alec’s warped view on the world of software and sometimes life in general.
Pithy, germane, comments are always welcome.

This content on this site is copyright Alec Clews and licensed under a Creative Commons Attribution-ShareAlike 3.0 License unless otherwise stated.
N.B. Postings on this site represent my personal opinion only and many factors specific to your environment may invalidate this information. You should check before relying on anything I say or quote here.
-
Archives
- October 2008 (2)
- September 2008 (1)
- August 2008 (12)
- July 2008 (11)
- June 2008 (11)
- May 2008 (15)
- April 2008 (11)
- March 2008 (4)
- February 2008 (12)
- January 2008 (13)
- December 2007 (10)
- November 2007 (7)
-
Categories
-
RSS
Entries RSS
Comments RSS
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.
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)