Comments on: Managing changes in scope and direction in an agile projects http://lostechies.com/joeocampo/2008/10/12/managing-changes-in-scope-and-direction-in-an-agile-projects/ Tales from the field... Sat, 11 Feb 2012 08:43:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Joe Ocampo http://lostechies.com/joeocampo/2008/10/12/managing-changes-in-scope-and-direction-in-an-agile-projects/#comment-489 Joe Ocampo Mon, 13 Oct 2008 15:43:11 +0000 /blogs/joe_ocampo/archive/2008/10/12/managing-changes-in-scope-and-direction-in-an-agile-projects.aspx#comment-489 @Steve >How do you see this playing out in a context where the delivery of the 'christmas plankton' isn't what the client thought they were buying when they signed the contract? If you are a Agile consulting company then transparency of every facet of your process is paramount. More importantly you have to gain the trust and understanding of the customer on how you will be conducting business. I usually encourage the consulting company to setup a one to two day workshop for the client to set expectations on the customers role in the process. If your customer does not want to take part in the workshop then this negates the Agile offering and you move towards more of a traditional cost and materials scenario. The workshop will not prevent the misunderstand or lack of clarity of the problem context above. But what it does outline is how you are going to go about solving it. Agile consulting from a contractual basis places emphasis on the planning game and the retrospective. During the planning game I place a lot of value on low fi modeling and screen wire frames. These design artifacts serve as communication conduits more then requirements. Taking the snowman paradox into account, early on I would have identified a RASCI model that outlined stakeholders involved in the process. If the end used were the "field reps", then I would ask that they sign-off on high level concepts that determine scope. I would also encourage them to be present during the demo session at the end of every sprint. In the end of you do everything I have said and the scope still changes then yes, execute your change in scope procedure but try not to be so bureaucratic about it. In other words make it an engaging experience that combines aspects of the planning game and a retrospective. Be Agile the noun not Agile the verb. @Steve

>How do you see this playing out in a context where the delivery of the ‘christmas plankton’ isn’t what the client thought they were buying when they signed the contract?

If you are a Agile consulting company then transparency of every facet of your process is paramount. More importantly you have to gain the trust and understanding of the customer on how you will be conducting business. I usually encourage the consulting company to setup a one to two day workshop for the client to set expectations on the customers role in the process. If your customer does not want to take part in the workshop then this negates the Agile offering and you move towards more of a traditional cost and materials scenario.

The workshop will not prevent the misunderstand or lack of clarity of the problem context above. But what it does outline is how you are going to go about solving it.

Agile consulting from a contractual basis places emphasis on the planning game and the retrospective. During the planning game I place a lot of value on low fi modeling and screen wire frames. These design artifacts serve as communication conduits more then requirements. Taking the snowman paradox into account, early on I would have identified a RASCI model that outlined stakeholders involved in the process. If the end used were the “field reps”, then I would ask that they sign-off on high level concepts that determine scope. I would also encourage them to be present during the demo session at the end of every sprint.

In the end of you do everything I have said and the scope still changes then yes, execute your change in scope procedure but try not to be so bureaucratic about it. In other words make it an engaging experience that combines aspects of the planning game and a retrospective. Be Agile the noun not Agile the verb.

]]> By: Steve Bohlenq http://lostechies.com/joeocampo/2008/10/12/managing-changes-in-scope-and-direction-in-an-agile-projects/#comment-488 Steve Bohlenq Mon, 13 Oct 2008 13:09:27 +0000 /blogs/joe_ocampo/archive/2008/10/12/managing-changes-in-scope-and-direction-in-an-agile-projects.aspx#comment-488 I would be interested to know from your perspective how you would approach managing this change from the perspective of an outside consulting engagement instead of an internal development team. Most of the typical 'embrace change' mantra of the Agile approaches always seem much more applicable to the internal dev staff v. internal product owner scenarios as you have used for your example above instead of from the perspective of an outside consulting firm servicing a client. How do you see this playing out in a context where the delivery of the 'christmas plankton' isn't what the client thought they were buying when they signed the contract? Change order time? I would be interested to know from your perspective how you would approach managing this change from the perspective of an outside consulting engagement instead of an internal development team.

Most of the typical ‘embrace change’ mantra of the Agile approaches always seem much more applicable to the internal dev staff v. internal product owner scenarios as you have used for your example above instead of from the perspective of an outside consulting firm servicing a client.

How do you see this playing out in a context where the delivery of the ‘christmas plankton’ isn’t what the client thought they were buying when they signed the contract?

Change order time?

]]>