Managing changes in scope and direction in an agile projects

I was recently asked the following question, “How do you best manage changes in scope and direction in an agile project?”

Embracing change is the quintessential backbone of Agile.  How to manage it is a whole other story. ;)

The difficult aspect of this paradox is to understand the context of the change.  When I coach people on change I tend to draw a metaphor to building things with Lego’s. In this particular context the change is centered around misguided direction that results in the production team wasting time building the wrong thing.

In this example the product owner has asked you to make a snow man out of Lego’s. We go through preliminary analysis with the team (Development, BA, QA, Product Owner) and determine these high level features and their corresponding complexity ratings:

  • Head  400
  • Body 200
  • Bottom 300

This will give us a ballpark of the project size and we can infer from prior Sprints that the team is capable of producing 50 points every 3 week Sprint.

So it will take 18 Sprints and a total of 54 weeks for the team to complete this work.  Of course this is a best case scenario. I usually factor in reserve time as well but this is another discussion.

The team starts with the Head because the Product Owner and the team both believe this is the most complex aspect of the project. They break the head feature into several epics (master level) stories. (Remember we are working with Lego’s here).

  • Hat 150
  • Skull 100
  • Eyes 60
  • Nose 60
  • Mouth 60

I can go on and on but the point is that the team ends up building the head of the snowman. Now for some curve balls that I know never happen in real life.

The Product Owner is not really the end customer.  They are acting as a proxy for field reps that are actually capturing the customer demand for the products that IT creates.  When the product owner shows the working head of the snow man to the field reps it goes something like this,

“That is great if we were wanting a traditional snowman but we were thinking of something more like Sponge Bob dressed up as a snowman”

Based on this news, the team just wasted 23 weeks’ worth of development.  But you do have intangible gains:

  • the team has learned how to work together
  • the team members have a much greater knowledge of making eyes, noses and mouths with Lego’s.
  • the team matrix as a whole has a much more holistic foundation for issue and problem solving
  • Agile is no longer a buzz word but an implemented methodology

The challenges now revolve around the Scrum Master or the person in charge of the project to insure that the teams momentum and self image are kept intact. Like I have always said Agile is 70% people and 30% software. The focus has to be on the team dynamics in order to create a cooperative and collaborative atmosphere.

The focus should now be this:

  • We are going to have to refactor the head to look more like Sponge Bob.
  • The team should focus on what components they can reuse when gauging complexity ratings.
  • Don’t panic and just approach this as if it simply a knowledge gain exercise

You hold a new project planning meeting similar to the first one you held and come up with these high level features:

  • Head/Body 800
  • Legs 300
  • Arms 200

You don’t want to dive any deeper at this point.  The purpose is to rebroadcast the scope change from a project time line perspective. Now you have a project that was originally projected at 900 points, explode to a project with 23 weeks down the drain and a new projection of 1300 points (that’s including reuse!)  At this point you have not wasted any time developing anything new, you have simply reanalyzed the scope change.  You take your projection to the Product Owner and have them make the decision.  One of two things usually happens, one they cancel the project or two they embrace the new plan.

In most cases this is what usually happens. The product owner doesn’t like either one of the time lines and is completely frustrated.  They go on and on about that they need it by a certain time frame etc.  Usually I negotiate at this point.

“You know we can’t create the sponge bob but would you be willing to work with my team and their estimates on a similar product offering in that time frame?”

When it is all done you end up negotiating building a Christmas “Plankton” for the end customer.  It doesn’t sell at the volume that the SpongeBob would have but it does bring in revenue.  The happy ending for the story is that “TRUST” was established between the development organization and the product teams. In fact trust is so high that they want to start working on the SpongeBob surfer dude for next summer.

I know this was very long winded but I wanted to give you a context for the thought of scope change. Things happen on projects that cannot be forecasted at times. The important aspect of all this is not to panic. Knee jerk reaction is to go into a blame game state. This creates an unhealthy atmosphere and does not focus on producing a value stream. Instead use Agile to help facilitate a discussion around the scope that will drive towards success.

When I am introducing Agile to a team I spend at least an hour on the concept of “Embracing change”. I ask the following questions:

  • · What does embrace mean to you?
  • · Does embracing change mean all the time or only sometimes?
  • · If you embrace something is there a possibility that you can get hurt or have negative emotions?
  • · If you do experience the “feeling” of hurt, how are you going to deal with it in a way that you do not negatively affect the atmosphere and harmonics of the team?
  • · What is your responsibility as a team member to insure embracement of change is being met?
  • · Do you still want to do this?

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of
This entry was posted in Agile Project Coaching & Management, Agile Teams. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to Managing changes in scope and direction in an agile projects

  1. 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?

  2. Joe Ocampo says:


    >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.