So one of the requirements in our Fortune 500 proposal, is a detailed plan for change management. I'm guessing that the client will be wanting to sign off each and every modification or update.
Working with Agile and Rails, change management isn't something we normally consider too carefully during initial development - features are scheduled into iterations and the client is always aware of what is in which iteration. And if they want to change their mind, that's just fine - we shuffle things around. So would I simply have a form that signed off for any changes to the content of an iteration? Does anyone have an example of such a form?
On 6/14/07, Nick Coyne <nic.co...@gmail.com> wrote:
> So one of the requirements in our Fortune 500 proposal, is a detailed > plan for change management. I'm guessing that the client will be > wanting to sign off each and every modification or update.
If you are wanting to follow an Agile/Iterative approach then one thing I've found to work well is having the client sign off on the stories going into each iteration during the weekly iteration planning.
> So one of the requirements in our Fortune 500 proposal, is a detailed > plan for change management. I'm guessing that the client will be > wanting to sign off each and every modification or update.
> Working with Agile and Rails, change management isn't something we > normally consider too carefully during initial development - features > are scheduled into iterations and the client is always aware of what > is in which iteration. And if they want to change their mind, that's > just fine - we shuffle things around. So would I simply have a form > that signed off for any changes to the content of an iteration? Does > anyone have an example of such a form?
Currently, when a client has a change request, it goes through a series of discussions about why something needs to be changed. How does it affect the rest of the existing application and where does it fit into the road map. We often say no to some change requests because they aren't supported with rationale for them, which our process requires for any features to exist. This is our way of working with our client to avoid the, "wouldn't it be cool if...?" requests and keep the system focused on it's primary objectives. When changes are necessary, they become new deliverables in an upcoming iteration.
If the change impacts other areas of the application, there should be some discussion/tracking of the dependencies it may affect. Not sure that a form that a client would fill out... would work with our process, aside from it being where a conversation begins. (example: client posts an idea in a basecamp message)
Anyhow, that's how we currently handle it at PA.
Cheers,
Robby
-- Robby Russell Founder and Executive Director
PLANET ARGON, LLC Ruby on Rails Development, Consulting & Hosting
Moving slightly away from my original question... how does everyone handle bugs after application launch compared with during app development. Is their always a bug/issue tracking system that you use for these things? How does one integrate this with agile processes?
Nick
On Jun 18, 8:26 am, Robby Russell <r...@planetargon.com> wrote:
> > So one of the requirements in our Fortune 500 proposal, is a detailed > > plan for change management. I'm guessing that the client will be > > wanting to sign off each and every modification or update.
> > Working with Agile and Rails, change management isn't something we > > normally consider too carefully during initial development - features > > are scheduled into iterations and the client is always aware of what > > is in which iteration. And if they want to change their mind, that's > > just fine - we shuffle things around. So would I simply have a form > > that signed off for any changes to the content of an iteration? Does > > anyone have an example of such a form?
> Currently, when a client has a change request, it goes through a > series of discussions about why something needs to be changed. How > does it affect the rest of the existing application and where does it > fit into the road map. We often say no to some change requests > because they aren't supported with rationale for them, which our > process requires for any features to exist. This is our way of > working with our client to avoid the, "wouldn't it be cool if...?" > requests and keep the system focused on it's primary objectives. When > changes are necessary, they become new deliverables in an upcoming > iteration.
> If the change impacts other areas of the application, there should be > some discussion/tracking of the dependencies it may affect. Not sure > that a form that a client would fill out... would work with our > process, aside from it being where a conversation begins. (example: > client posts an idea in a basecamp message)
> Anyhow, that's how we currently handle it at PA.
> Cheers,
> Robby
> -- > Robby Russell > Founder and Executive Director
> Moving slightly away from my original question... how does everyone > handle bugs after application launch compared with during app > development. Is their always a bug/issue tracking system that you use > for these things? How does one integrate this with agile processes?
> Nick
> On Jun 18, 8:26 am, Robby Russell <r...@planetargon.com> wrote: > > On Jun 14, 2007, at 10:12 PM, Nick Coyne wrote:
> > > So one of the requirements in our Fortune 500 proposal, is a detailed > > > plan for change management. I'm guessing that the client will be > > > wanting to sign off each and every modification or update.
> > > Working with Agile and Rails, change management isn't something we > > > normally consider too carefully during initial development - features > > > are scheduled into iterations and the client is always aware of what > > > is in which iteration. And if they want to change their mind, that's > > > just fine - we shuffle things around. So would I simply have a form > > > that signed off for any changes to the content of an iteration? Does > > > anyone have an example of such a form?
> > Currently, when a client has a change request, it goes through a > > series of discussions about why something needs to be changed. How > > does it affect the rest of the existing application and where does it > > fit into the road map. We often say no to some change requests > > because they aren't supported with rationale for them, which our > > process requires for any features to exist. This is our way of > > working with our client to avoid the, "wouldn't it be cool if...?" > > requests and keep the system focused on it's primary objectives. When > > changes are necessary, they become new deliverables in an upcoming > > iteration.
> > If the change impacts other areas of the application, there should be > > some discussion/tracking of the dependencies it may affect. Not sure > > that a form that a client would fill out... would work with our > > process, aside from it being where a conversation begins. (example: > > client posts an idea in a basecamp message)
> > Anyhow, that's how we currently handle it at PA.
> > Cheers,
> > Robby
> > -- > > Robby Russell > > Founder and Executive Director
