Dev work not upto mark

Hi All,

We work on a 2-week sprint model wherein we get a total of 10 working days. To give a live example, we are currently on with our Sprint5, it started on 28th March and will end on 10th April (since 30th March was a company holiday, we took this as a 9-day sprint).

We took all the capacity and velocity into consideration and decided to take up a total of 32 pointer stories. 21 pointers from this total were assigned to one developer and rest to another. The division could not have happened any other way since the former was a new hire, hired for a specific integration role. On the 6th day of the sprint, in the daily standup, it was all good and the dev team ensured to deliver all the stories to QA by end of the 7th day. However, in today's daily standup meeting (today is the 7th day), the dev lead mentioned that they might see some delays in the 21 pointer stories since the resource was new and she underperformed which was not taken into consideration. 

The impact I see is that I have to communicate the business on the delay in the production deployment of these stories which will not give a good impression. How can I put this up in retrospective? Is it something I can skip for a while since its the first time and I do believe to give some space to the team to improve their mistakes. How can we as a team avoid it? Please suggest.

Thanks

Hi Rhea - May I clarify?  From what I understand, your Sprint is not over yet and you are projecting that the Development Team will be unable to deliver a 'Done' Increment by the end of the Sprint?  And you are asking whether or not to discuss this in the Sprint Retrospective?

First, you didn't mention a Sprint Goal.  Do you have one?  If so shouldn't the next best action to take would be to have the Development Team alert the Product Owner, and adapt the Sprint Backlog to see how they can still meet the Sprint Goal?

Why do you feel it is your job to communicate to the business the delay?  Are you the Product Owner?  What is your role in the Scrum Team?  How might the Scrum Team speak to this in the Sprint Review?

If at the end of the Sprint the Development Team does not meet the Sprint Goal, wouldn't it be timely for the Development Team to inspect why and adapt and improve next Sprint?  If they didn't talk about it, how would they be able to avoid the same challenges in future Sprints?

All the best,

+1 to Chris' observations.

It may seem trivial, but there seems to be much in your post Rhea that doesn't represent Scrum, and perhaps should be discussed/revised going forward so that the team can improve their practice of Scrum.

A few examples:

21 pointers from this total were assigned to one developer and rest to another.

• Should we conclude then that your Scrum Team is composed of only two Development Team Members?   
• There is no assigning of work in Scrum.   The team accepts work offered based on their assessment (capacity, ability), and then the team decides as a whole how to complete the work
• Did the Scrum Team create a Sprint Goal that identifies the business value that they are intending to deliver at the end of the sprint?

dev team ensured to deliver all the stories to QA by end of the 7th day

• Why does QA need to wait so long before being able to test and verify anything?   How can the stories be changed so that QA can be engaged much earlier in the sprint?   Scrum is about Empiricism, and the ability to inspect and adapt.   Delaying testing until the 7th day does not support a quick feedback loop

On the 6th day of the sprint, in the daily standup, it was all good... (on) the 7th day, the dev lead mentioned that they might see some delays

• There is no role in Scrum other than Product Owner, Scrum Master, and Development Team Member.   Why is there a role identified as Dev Lead, and why are they speaking for the team?
• Seeing this statement reminded me of traditional project management, where everything is reported as "green" until the target date approaches, and then it becomes "red", all hell breaks loose, and everyone starts scrambling.   This should not be your typical Scrum experience
• What can the "team" do to help complete the items that have fallen behind schedule?   The Daily Scrum should serve as a point each day for the Scrum Team to assess the health of the sprint (inspect/adapt).   If this was not happening, then that is another topic to be discussed in the retro

she underperformed which was not taken into consideration. 

• That sounds like something for the team to discuss during their retrospective.   What were some alternatives to delegating so much of the sprint work to a new Development Team member, and why did they overestimate the new person's capability?   A review of Tuckman's Guide to Team Maturity may give the Scrum Team some insight on this
• The very real issue I see is around individual ownership of work, that seems to be supported by the business, which is a very bad smell in Scrum
• The team owns the work, and if the team over-estimated their ability to complete their forecast, it falls on the team to assess and work on how to improve both their ability to forecast and deliver

Keep in mind, failure is not a bad thing, because it provides the right environment for true change to occur.   There is a familiar saying in Scrum: "Failure is not an option in Scrum.   It is mandatory".

Good luck.

+1 to both Chris and Timothy's comments.

Would definitely be good to coach the team on this concern but not just at the retrospective, but also during daily scrum. Begs the question of what the team can collectively do in order to deliver their increment.

If the team sees that one person is lagging, I don't think it's right to set the person up for failure - like in the responses here, there is nothing that should be stopping the entire team from working on the integration pieces - it's not one person's responsibility to deliver 21 story points, it's the whole team.

It's not that it won't look good on one person for underperforming, but the entire team for just throwing her unto the deep end and not doing anything about it. A helpful resource for correcting this kind of thinking would be "The Five Dysfcuntions of a Team" by Patrick Lencioni.

I'm fairly curious though about why QA only comes in at the latter half of the sprint - Shouldn't they be involved early on to work with the developer and have some cases that supplement the integration pieces?

Thanks, Chirs and Timothy for such elaborate answers.

21 pointers from this total were assigned to one developer and rest to another.

• Should we conclude then that your Scrum Team is composed of only two Development Team Members?   Yes, our scrum team has only 2 developers only.
• There is no assigning of work in Scrum.   The team accepts work offered based on their assessment (capacity, ability), and then the team decides as a whole how to complete the work. The team was involved from the beginning in the capacity planning. They did accept work taking into consideration everything. However, the one thing, I believe we overestimated was the capability of the new hire. We thought she can pull off 21 pointers easily, however, when she got to work, there were challenges. The one thing I am going to pick in retro that the scene should have made clear to us in the beginning and not on the last day.
• Did the Scrum Team create a Sprint Goal that identifies the business value that they are intending to deliver at the end of the sprint? We did have a goal, however, as I said above, the new hire was not up to the mark and her capabilities were over-estimated.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

dev team ensured to deliver all the stories to QA by end of the 7th day

• Why does QA need to wait so long before being able to test and verify anything?   How can the stories be changed so that QA can be engaged much earlier in the sprint?   Scrum is about Empiricism, and the ability to inspect and adapt.   Delaying testing until the 7th day does not support a quick feedback loop. These 21 pointers were divided into 2 stories only. These were some integration tasks. This is a common problem with our scrum team. They do deliver few stories after 3rd or 4th day but the majority goes till the 7th day only. I am unable to figure out a way yet how to change the stories to make them more independent. The tester does get few stories before the 7th day as well.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

On the 6th day of the sprint, in the daily standup, it was all good... (on) the 7th day, the dev lead mentioned that they might see some delays

• There is no role in Scrum other than Product Owner, Scrum Master, and Development Team Member.   Why is there a role identified as Dev Lead, and why are they speaking for the team? I apologize to use this term. I mean the developer only.
• Seeing this statement reminded me of traditional project management, where everything is reported as "green" until the target date approaches, and then it becomes "red", all hell breaks loose, and everyone starts scrambling.   This should not be your typical Scrum experience. I have noted this for retro already. When I spoke with the devs this afternoon, they still give a security that 90% they are sure that the work can be delivered, however, they wanted to raise the challenge just in case if the work is not finished.
• What can the "team" do to help complete the items that have fallen behind schedule?   The Daily Scrum should serve as a point each day for the Scrum Team to assess the health of the sprint (inspect/adapt).   If this was not happening, then that is another topic to be discussed in the retro. The daily standup was happening every day. On very few days, we didn't meet up physically, however, I made sure to ask them personally whether all is on track and if there are any impediments

The developers could not have forecasted how the new hire would perform. She was new, we gave work making sure that she is not burdened yet a challenge was raised saying that she is slow and new to system and taking time to code. The only thing I am worried that why this was not raised initially.

Thanks

These 21 pointers were divided into 2 stories only. These were some integration tasks. This is a common problem with our scrum team. They do deliver few stories after 3rd or 4th day but the majority goes till the 7th day only. I am unable to figure out a way yet how to change the stories to make them more independent. The tester does get few stories before the 7th day as well.

21 story points divided into 2 stories seems like quite an undertaking for one person for sure - that's like an 8 and 13. That's a bit telling about how QA verification, by majority, happens near the end of the sprint. That's a bit of a concern, and if, historically-speaking, this happens all the time, looks like it's another thing to address at retrospective (unless of course they historically get to Done-Done with these large stories)

In terms of changing the stories to be more independent, that maybe goes back to the Sprint Planning - was there something that could have been done/discussed with the Product Owner to negotiate how these stories could be more independent so that this could be addressed moving forward?

Perhaps it would be wise to anticipate a temporary reduction in Development Team productivity should a new member be taken on.

Did the team expect their productivity to be negatively impacted while they made an investment in their new hire? If not, why not?

From my personal point of view, as a Scrum master, I find the situation explained here as a very good opportunity to Inspect and Adapt and learn from a past experience. 

I do not know the level of comprehension of the Scrum Values the team has right now but I would reinforce the values and maybe refer to situations lived during the sprint (I like the article from Stephanie Ockerman). For example, What would "respect/courage/commitment/openness" tell us about "she is slow and new to system and taking time to code"? As a team, do we collaborate (paring for instance) to make a comfortable and secure place to work since day 1? What have we learned from the last sprint? How could we be more successfull in the future with a new member (and her in the next sprint)?

From what I understood of the situation, I would focus my energy on how to improve the process of integrating a new resource as a team than trying to figure out "(...) why this was not raised initially." 

As mentionned, I would come back to the basis of empirism and the three fundamental pillars (Transparency, Inspectation and Adaptation).

Finally, I am not 100% sure I understood well these sentences. Are saying that she did not take part of the sprint planning and work have been pushed to her?

The developers could not have forecasted how the new hire would perform. She was new, we gave work making sure that she is not burdened yet a challenge was raised saying that she is slow and new to system and taking time to code.

I wish you the best in order to meet the sprint goal for the last couple of hours in the sprint.