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

A Dip in the Chart – An Agile Story

Posted on: 22 May '12

This is about a project that started a couple of months ago with a team of eight in India and a team of five in the U.S. Andy is the onsite manager. Kiran went onsite for a month long knowledge transfer and worked with Andy and his team.

At offshore, Kiran has started playing the role of a Scrum Master. After Sprint-0 and Sprint-1, one fine morning, Kiran receives an email from Andy and reads it.

What do you think Kiran should do? How can we avoid such incidents in projects?  Let us discuss.

  • Priyadarshini

    Firstly not necessarily agile teams lag on reliability scale in the beginning of a project, but if the team is new to agile, it is possible. I think Kiran should bring forth the business value that is added against all the odds. Completing 12 user stories out of 16 is not bad as long as what is delivered is of highest priority and is absolutely shippable. The quality of deliverables, adherence to “definition of Done” and the business value added should be emphasized on , with an assurance of being reliable in the coming sprints and an intelligent estimate of increase in velocity of the team.

    Also if some team members have a slower velocity, techniques like pair programming can be used which will make sure, technical inefficiency doesn’t hinder the progress and will also remove dependency on team members. Also making the team cross functional is very important as it is a crucial aspect of scrum.

    Regards,
    Priyadarshini

    • Raja Bavani

      Priyadarshini, Good points! Agle teams start performing in ‘rhythm’ after the first three or four iterations. This is because, in software industry, every project is unique and different from the rest.
      You have mentioned that making the team cross functional is important. Could you please elaborate?

      • Priyadarshini

        Basically

        Development Teams are cross-functional, with all of the skills as a team necessary to create
        a product Increment;
        -Scrum recognizes no titles for Development Team members other than Developer,
        regardless of the work being performed by the person; there are no exceptions to this rule;
        -Individual Development Team members may have specialized skills and areas of focus, but
        accountability belongs to the Development Team as a whole; and,
        -Development Teams do not contain sub-teams dedicated to particular domains like testing
        or business analysis.

  • AD

    The dip in chart can be due to one of the following 2 reasons:
    1) Those 2 team members being the star performers might have been engaged in solving issues which were not planned in the sprint but very critical
    2) The task handled by these resources might have encountered some ambiguity hence the initial estimate for the tasks worked by those resources might have been incorrect.

    If the the reason is first one than it is self explained. If its the second reason, than this will get corrected over the following sprint as the team develops understanding of the product/business knowledge.

    -Ajay

    • Raja Bavani

      Ajay,

      Very practical reasons! Timely communication unplanned critical tasks and efforts is critical.

      I agree. When a project involves knowledge acquisition on a product or business, even if the team members are experienced in agile, a ‘Dip in the Chart’ can happen and the situation can be improved over the next 1 or 2 iterations.

  • Kiran Dasari

    For me in this case bigger problem to worry is why customer realized this after the sprint is over especially and got escalated when he is receiving the status on regular basis. If Andy has been completely aware he would have raised the alarm bells in advance not after his VP has raised concern. By principle agile project will have changes come in anytime and there is always a chance that original sprint plan might not be achieved and in that case all stakeholders should be aligned to revised status. Generally when the team is new to the project we can load 75% of their time in sprint plan and rest in the project ramp-up so that they achieve what is expected at the same time increase delivery speed as project progresses and many customers agrees with this of course it is up to the project manager to convince customer.

  • Dhanasekar

    As per this case, the same should have been discussed in the sprint retrospective meeting. Sprint backlogs with valid reasons is accepted, which would have been an answer to Jim. Moreover I don’t think because of backlogs the team members need to be replaced. What if the same scenario happens in spite of replacing the team members? Ideally these things should be taken in the retrospective meeting which would lead to the better solution in the forthcoming sprints.

  • Raja Bavani

    Thanks Kiran, Dhanasekar,
    Good points. It occurs to me that Andy did not provide regular updates to his senior management or Andy’s goal is to satisfy his senior management. In addition to the points you mentioned, the absense of collaborative governance is visible in this story.

  • David

    Nice presentation in storyboard format! Like Kiran alludes to, I think the team overcommitted and underdelivered. During task planning, I always recommend planning on completing only 2/3 of capacity. What this means is that if I have a team capacity of 10 people over two weeks, then capacity = 10 * 6.5 * 10 = 650 hours. But I only let the team commit to 2/3 or 433 hours of work. This leaves a buffer of 50% for overruns and unexpected difficulties. Once you have 4-5 sprints/timeboxes of history, you can use your historical average to guide what you can realistically get done.

    Remember, despite your big ambitions and best intentions, reality will always win. Look to real numbers to guide your future performance. And as Dhanasekar points out, investigate why the team fell short of its goal — there should be lessons in there somewhere.

    Lastly, the VP needs to stop micromanaging and start delegating & trusting the team to manage and improve itself. Likewise, the team needs to demonstrate it is managing and improving itself to the VP.

  • Thanks David for sharing your insights!
    I agree that the ‘trusting the team to manage and improve itself’ is critical. Also, the team needs to show improvement.

  • Nirmaljeet Malhotra

    A little late to comment on this post. I concur with David. In addition to estimating for 75 to 80% of the capacity, I advice my teams to always have a couple of uncommitted stories. These stories are typically of lowest priority for the sprint. The team picks these up if they complete the committed user stories. All going well, teams utilize the buffer time to deliver the uncommitted stories as well.

    Not to mention, Product Owners need to agree on the concept of uncommitted stories. My Product Owners don’t mind.

  • Nirmal, Thanks for sharing your practice here! It is going to help our readers. POs agreeing on the concept of uncommitted stories are the enablers here!

  • Balan

    Thanks Raja for the real-life-scenarios in Blog-posts. The reader comments are equally great.
    Its obvious that think its dangerous to “change horses in midstream”. Let the team complete the sprint, then retrospect and improve (if required) in next/later sprints.

    • Balan, I agree and appreciate all readers for their participation in sharing their views here. Midstream change can be dangerous when team is busy executing a Sprint. Good point!

  • Karen Favazza Spencer

    Kiran is letting the bosses frame the conversation in the hierarchal paradigm that creates Death Marches. Since the bosses are so data point driven, they need to understand about the learning curve, aka the J Curve. And they need to understand that if you don’t have dips and plateaus, you won’t ever be highly productive, either. Think of it like this: If the team only commits to work they know they are going to complete, they are never going to stretch and increase their output. On the other hand, if they know they have to complete it at all costs, the cost might be the quality or a hit on their health. None of which is good for the company.

    Explain that Agile expects that some Sprints will “fail.” It is about learning. When the fear of failing is entrenched on the team, velocity becomes worthless. Stop with the daily updates. Have end of Sprint Reviews, only. Put the pressure on Product Management to be really specific and limited in identifying the top items in the backlog. Use the reviews to explain not only the successes, but the challenges – such as no automated tests, or a dirty database, or a time consuming work around due to not having the right tools.