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</ul> 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</ul> 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?