Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Is change inevitable? – A Scrum Master’s dilemma

Posted on: 03 October '12

Product Engineering

What do you think Kiran should do?

Is Change Inevitable?

What about the impact of change on efforts, cost and quality?

How do you deal with such situations?

Do you have any suggestions to Kiran, Andy or Anita?

Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.

  • Scott

    Swarm and ask the team weigh and give an honest appraisal of risk/reward.

    • Scott,
      Excellent suggestion! Collaborative spirit and collective decision making are critical!

  • Mahwish Zaheer Khan

    As conveyed by Andy, this requirement is inevitable. The team cannot go ahead without accommodating this need. If managed effectively the team can deliver on time provided the team members can put some extra efforts. This may require some work reshuffle and shifting of responsibilities within the group. Kiran, Anita and Mohan should take up the changes while keeping Andy informed on the overall impact.

    • Mahwish,
      Accomodating as many features as possible will impact product quality. This situation will result in accumulation of ‘Technical Debt’. I wrote a blog post on ‘Technical Debt’last year. It is at http://www.blogs.mindtree.com/teams-technical-debt
      I agree with the second part of your last sentence that the team should let Andy know the overall impact.

      • Mahwish Zaheer Khan

        Agree that there will considerable technical debt. Also accommodating as many features possible will be difficult in such a short duration.
        The idea is to consider those features which are absolutely essential in the current Sprint. This could be identified with the help of someone from the Client side having better understanding of Client’s immediate needs. But these need to be on ‘Top of the Priority’ list. Rest can be delivered in the next cycle.

        • Mahwish, Absolutely! Having a prioritized list of things or backlog is a viable approach. Also, prioritation has to happen at regular intervals. Thanks!

  • Pooja Wandile

    As per theory, Kiran should say No and ask the business user if this new requirement can wait until next sprint. (obviously the answer will be a big No from the BA) But in practical situations this does not happen. In real life, any feature, if found to be important,even if it comes late in the sprint, the team is forced to work on it,if you have agreesive customers. The team will burnout itself in order to make the business users happy. But, if the feature does not work as desired then who takes the responsibility? The team has already informed Andy about the impact of change on the quality.

    • Pooja,
      Valid point. Let me add more. The ‘Definition of Done’ (DoD) plays an important role here. With DoD the team can differentiate requirement refinement from change. That will help them negotiate. As you said, pushing the team to deliver extra features will result in burnout as well as porr quality. So, what is your answer to the key question – ‘Is Change Inevitable?’ ?

      • Pooja Wandile

        Yes, It is inevitable. How much does it impact the team and deliverables will depend on the SM’s negotiation skills.

        • Pooja, Yes. On the outset it depends on Scrum Master’s negotiation skills. When there is constructive collaboration, negotiation is efficient and such issues can be resolved smoothly.

  • Upendra Bhadauria

    The biggest problem here is that Andy and the Business users do not understand the SCRUM process and feel that in an agile methodology change can be done anytime. It is not the Scrum Master but the Product Owner from client side who should be the gate keeper and shield the team from such requests during the middle of a sprint. The Product Owner should be able to either hold off the change till next release or reduce scope by pushing out some lower priority user stories to the next sprint.

    If there is no Product Owner, then someone needs to help Kiran by talking to Andy on the correct process and the risks of going with Andy’s approach. Given that there seems to be a critical business need, the team should make the change but definitely should adjust the scope by re-prioritizing the remaining user stories – since only half of the sprint is completed that should be possible.

    • Raja Bavani

      Upendra, You have shared an excellent point on the role of ‘Product Owner’. With effective product owners, Scrum teams can avoid such sticky situations. Thanks for sharing your comments!

  • jayram joshi

    I will say there appears to be something fundamentally broken here.

    0. Yes change is inevitable and should be welcomed. If team is not able to handle a change then it’s doing nothing but mini waterfalls.
    1. How come the details came from business users for this story when the story is being played? Didn’t they review the stories with business users before start of the iteration/sprint during kickoff meeting?
    2. Who reviewed the acceptance criteria of the story?
    3. Why is the team so rigid? If the new requirement can be played as a story in current iteration..assuming it can be ready to be played and executed, why not ask the PO to deprioritize some story not played yet from the current iteration?
    4. Why did Kiran accommodate 3 changes earlier? If you have already set expectations with client/PO that things can be changed randomly then ofcourse they are going to push you hard.
    5. From the nature of conversation Scrum or any fixed time box based solution doesn’t appear to the right solution for this client. Why don’t they adopt Kanban?

    • Jayram, You have raised very good questions. Acceptance criteria is very important and so is expectation management. This cartlog implies the fact that the team is responsible for such a sticky situation. I like your last question th emost. Kanban helps in such cases! Collaborative spirit adds value and ridigity does not! Collaborating without showing any signs of rigidity is key to success! Thanks again!

  • Anannya Deb

    From the story, it looks like the two groups are at cross purposes – Andy is worried about business users while Kiran is worried about how much work he (and his team) has to do. Is there a common ground? Is there a shared goal that both Andy & Kiran want to make happen?

    There seems to be errors on both sides – the larger concerns of the customers are not detailed out (rather in pieces) at the front end. From a domain point of view, volume discounts and seasonal discounts are regular concepts in sales (I am assuming from the conversation that the proposed client is a consumer products co). So they should have been considered together.

    • Raja Bavani

      Anannya, Well said! There has to be a shared vision or goal. Also from domain perspetive, grooming of user story could have been done better in order to explore different forms of discounts. Thanks for commenting!

  • Nirmaljeet Malhotra

    I am not sure if Andy is client or a Product Owner or both. Yes, change is inevitable indeed. However, this exactly where training plays an important role.

    Clients tend to focus on the aspects of Agile which they think can work in their favor. In this case, adapting to change. But they have to be told that change in the middle of an iteration is not the best choice.

    Additionally, Product Owners need to understand the options that they can possibly exercise in the middle of a sprint. In this case, trade off for other low priority user stories.

    Whatever said and done, one can only experience the advantages of going the Agile way by exploring the flexibility of Agile keeping in mind the limits. Remember, it is about following the rules before you decide to be the rule.

    • Nirmaljeet, Andy is the PO and customer. I agree with your point of view. Training plays an important role in building project teams. Training helps them establish common policies or rules through collaboration and collective decision making.
      I like the second para in your comment. Change in the middle of an iteration is not the best choice. Change impacts both schedule and quality. Sometimes, change becomes very costly!

  • Satya Narayan Dash

    Is change inevitable?

    Short Answer – Yes, of course! In this case, the change can NOT be included actually. This is a rule and people violate many times and let the team burn out. However,please also note that Agile is about sustainable pace along with changes. Not overtime and burn out!!

    Long Answer – 1) Shorten the iteration duration. In place of 2 weeks (as per the conversation of Kiran), make it to 1 week. 2) Now 1 week might be too aggressive for Scrum projects. Go for XP from the next iteration onward. 3) If still the story in question is to be put in, then one lower priority story has to go out. 4) However, IMO, as I see the kind of work and conversation between the team, SM and Andy, Scrum is not the right fit here in this organization. I believe Kanban will the right fit here. (but will have a tough time from Management to get a buy in, considering Andy’s approach!)

    Actually, I have had 1st hand experience on a situation like this. I was into a NPI in a Fortune 50 company and the CEO was very interested in the product coming up ….along with price…he asks for new changed every 3/4 days ;-). So what did we do? It is always a good practice to have some nice to have features along with some Must have features. Nice to have features can be dropped in favor of Must to have feature. And the CEO was okay with it! (PS: Still I say that it is not Scrum per se, as during iteration, changes should not be allowed, but we have to change it as needed!!)

    • Raja Bavani

      Dear Satya Narayan, Thanks for providing the short as well as long answer. I like your long answer better because it talks about short iterations or adopting Kanban in such situations. Good points! Alsok thanks for sharine your experience with all of us!

  • Kumar

    I find this post and discussion interesting (though I am not from IT industry). This is because it conveys a simple point. I think, Kiran’s role is to help the team. He should get some outside expert or coach to help the team and involve himself in convincing the client.

    Change is evitable depending on
    1) its own weightage or priority
    2) the ability of product manager to convince client,
    3) the cost factor or business value
    4) the time available, and
    5) its impact on product quality.

    • Raja Bavani

      Dear Kumar,
      Your views on why change is evitable are very interesting.

      I agree that change is inevitable – but not always. This is because change can have a negative impact on project cost, quality and schedule.

      When the impact of change is not feasible or sustainable, is the change inevitable? Obviously the answer is ‘No’. Thanks for commenting!