Scrum master requested for helping with technical work

Is the Sprint Goal clear? Are the Development Team actually able to accomplish the Sprint Goal without technical assistance from the Scrum Master?

It is clear. These SBI's need to be finished in order to achieve the sprint goal.

The team detects not only that they do not have time left for finishing them without some aid but also provides a well-supported reason as a team to state that if the scrum master's technical help is employed then they'll be able to finish all the work and meet the sprint goal on time. Why the scrum master? They believe that adding someone else like a new team member at this point will make things worse and decline it as an option. Reasons provided are that he is the closest person to te current state of the increment with technical skills able to help (And they are right, the sm could help here, but the thing is what the sm would say about it)

Aside, let me clarify that this is an hypothetical situation, though I don't see it too bizarre to happen in real scenarios where the team is struggling to finish work at the end of a sprint and look for the sm's technical abilities to help them out. Am I being too imaginative here?

So basically, the team ran out of time. They have the technical knowledge to do this but for various reasons, they just ran out of time. 

I'm not a developer, but if I were and my SM had the knowledge and ability to help us when we needed help but just said "sorry, not going to do it, I don't do that anymore"; I would be livid. My trust and support in my SM would be shot because they clearly showed that they have no desire to be part of our team. As a SM I would expect my team's trust and openness with me to be completely destroyed were I to do something like that. How a SM could do something like that and expect the team not be affected is far beyond what I could fathom. I get it if it was just not possible for the SM to help due to lack of knowledge, resources, and time; but if it's possible the SM should do everything in their power to help the team succeed and remove any and all impediments. 

The basic premise of your proposed scenario can apply to many different instances. Say something blew up and caused the team to scramble on the last day so they couldn't take a break for lunch. It takes no technical skills to go pick up lunch or even call in to order pizza to be delivered. What would happen if the team asked the SM to help them out by getting lunch brought in because otherwise they would not be able to eat until supper. Think about what would happen if the SM just said "It's not my fault you didn't prepare by bringing your lunch." Different details but in my opinion it is on the same petty level. 

While I agree that the SM should make efforts to help the Development Team meet their forecast/Sprint Goal (like buying lunch, securing SME help, etc.), there shouldn't be an expectation that the SM will jump in to bail the Dev Team out.

I guess it would be at the option of the Scrum Master, if asked, whether they wanted to help that way.   Certainly a Scrum Master is busy working as a Scrum Master, and availability would be a huge factor (even if the Dev Team thinks the SM isn't really that busy).   However, in my opinion, it is setting quite a poor precedent to look to the Scrum Master to rescue a sprint that the Development Team forecast so badly.

Having the SM come to save the Dev Team simply glosses over several issues that the Dev Team needs to address if they hope to improve going forward (under/over estimation, transparency into item progress, team skill set, cross-functionality of members).

To Curtis, I can certainly envision a scenario where the SM would decline the Dev Team request.   Failure, and the pain associated with it, are great catalysts for change and improvement.   Stepping in to be a hero to the team is similar to kicking the can down the road, delaying the changes needed for team improvement.

Tim, good call outs man. I always enjoy what you have to share. I should have clarified a bit more but I meant if it was something that was beyond the team's control and not a regular occurrence and the SM had the time and knowledge to actually help. I certainly don't think the SM should save the team in this capacity frequently, that would be detrimental to the team overall. But if I have the means and ability to help my team in a situation that is far from the norm from them; I would do what I could to help. And I fully agree there are many scenarios where it is absolutely valid for the SM to decline the team's request for help. As with most things in our world, it's dependent upon the team and the situation and as always "what is best for the team". 

As with most things in our world, it's dependent upon the team and the situation and as always "what is best for the team". 

Correct. Bailing the team out could rob the team of an opportunity to learn from failure. On the other hand, not bailing them out could mean that the initiative is canned and the team disbanded. The best course of action therefore depends upon context.

Generally speaking, if a team demonstrates a willingness to learn from a situation, and to inspect-and-adapt their process accordingly, then lending extraordinary assistance can be worthwhile. The investment may be justified. Otherwise failure might be the best teacher.

So basically

• if the scrum master says "no" based on several reasons, like "This was your forecast. This is your commitment, your responsability as the develoment team so you must find solutions", "You know you must be self-organizing as a team, and I am not really part of the team" or even "Sorry, I could help but it is not my bussiness" (quite aloof)... all of them would be valid reasons but... after the sprint probably fails then the team may feel abandoned and the relationship with the scrum master somehow eroded. 
• If the scrum master says "yes", then the sprint probably succeeds, the scrum master is surely viewed as the new hero or the guy who is always there for the team no matter what and the relationship between both enhanced.

Both have consequences however.

If I was to say no, I'd do it with an extra dose of tactfulness and making sure the team understands the reasons behind it. Depending on the team and the context they could accept it without thinking "Our scrum master could have helped us finishing the work on time but he decided not to just to give us a lesson". That is definitely something a scrum master wouldn't want to drag along in future sprints.

If I was to say yes, I will probably rise a discussion at the retrospective to make sure the team understands that my role as scrum master is not to rescue the team everytime they need an extra hand on tech work to finish the sprint on time. Otherwise that would set a very ugly precedent for the self-development of the team. I'd make sure they understand this and make clear it won't happen again.

Now honestly... I feel a bit like Curtis said. I'd probably say "yes" and help the team out to the best of my skills but make them understand afterwards why it cannot happen again. If I see the team is willing to learn, as Ian said, I see more benefits on helping than not. Being totally optimistic I also see this as an opportunity to the scrum master to teach by example some good serving values for the team than if not given the situation might be less easy to transfer.

Not an easy call for the sm though, not at the least based on a fictional scenario lacking more context.

Thanks for your comments guys!

Nice discussion.

Shall we think about other options than "Yes" or "No" ?

Shall we think about other options than "Yes" or "No" ?

Do you have something in mind?

Shall we think about other options than "Yes" or "No" ?

Given the scenario posed, I don't know what other answer a SM can provide other than Yes or No. 

Always many options.

For instance one option, already proposed in Juan's question, is to answer back to the team with a question like :

What should be the best scrum master action(s) to this (hypothetical) situation? What would be the consequences of helping/rejecting it?

Sending the question back to them would bring the conversation upfront, wouldn't it? However, as the scrum master, would you base your final response upon their answers only or would you add something of your own to it?

Always many options.

For instance one option, already proposed in Juan's question, is to answer back to the team with a question like :

What should be the best scrum master action(s) to this (hypothetical) situation? What would be the consequences of helping/rejecting it?

I got you Olivier, I read that question as Juan asking what the SM should do; help or not help. The problem is there are so many unknown variables that there is no 1 right answer. Therefore, we should revert back to what is best for the team. Most times that means posing different questions to the team and all but listing out those questions would be tough without knowing the team and the details surrounding this sort of situation.

I had a real-life situation recently that reminded me of the questions posed in this thread.

I have a son - a young adult.   He received a driving violation, but has continually delayed paying his fine or requesting a court date.   

The "due" date is rapidly approaching, and even though he admits to the infraction (doesn't want to go to court), he complains frequently about the unfairness of it all, and claims that he doesn't have the funds to pay the fine.   Keep in mind, he's known about this ticket for 2 months now.

So, as a parent (i.e. - Scrum Master), what are my options?   I could step in and pay his fine because I have the means to do so (i.e. - bail out the team), but I know that any potential opportunity to teach would be lost once I've freed him of his obligation to pay (i.e. - would a team be receptive to teaching if they were similarly bailed out?).

I could also work with him and help him as much as possible, so long as it didn't require me to fix his situation for him.

I just wanted to present this, as I quickly identified the parallels to bailing out a team.   Sometimes, teams come out better having gone through pain (i.e. - failure).   As Scrum Masters, we should be very careful about stepping in to save the team from potentially painful consequences.   Sometimes, tough love is the best approach.

Very good example Tim. I would completely agree that pain is often the best teacher. Otherwise, people view the help given as a crutch and safety net to the point that they have little thought to the future infractions. On the flip side, say he was saving the money to pay for the ticket and then (God forbid) he got injured or was laid off and he just couldn't pay for it; that is when I think it would be beneficial to help by paying the ticket. It would prove that he could trust you and count on you when things out of his control happen; especially when he was working to right the wrong. It's definitely a delicate balance. I deal with this with several family members and it's always a case by case basis for me. Great analogy though, it's something that many of us can relate to; thanks for sharing.

Indeed.

Nice analogy Tim. So scrum masters resemble the father figure after all...  :D

As Scrum Masters, we should be very careful about stepping in to save the team from potentially painful consequences.

I totally agree. However, as Curtis mentioned, on the flip side of your story let's say your son did not deliberately delay the payment. He did not complain about it for two months but instead he started to find solutions to the problem keeping in his mind that his goal (sprint goal?) is to achieve the ticket's ammount of money. He destined some money from his savings, he helped at home, do some chores, earn some extra cash mowing the neighbour's lawn ... He even got a job as a deliveryman on weekends... But the time to pay runs thin now. He comes to you somehow dissapointed and says "Dad, I fear that despite my efforts I still need a 20% of money to the total payment of the ticket and I can't get more time for it..."

What would you do then?

Juan,

I'm trying to draw the analogy to the scenario you presented, and it isn't easy.   Best I can come up with is a "push" scenario, where work was pushed to the Development Team (by the business, or by the PO), and despite the Dev Team's best efforts, they were unable to meet the imposed deadline.

Should the Scrum Master step in to save a sprint that the Development Team did not truly forecast?

Like I said, I identified parallels between my real life scenario and the subject discussed here, but it is far from a perfect example.   In a true Scrum example, the son would not have had a deadline imposed on him, and a daily inspect and adapt ceremony (Daily Scrum?) should have revealed areas of concern (falling short of funds) long before the end of the time box.

I have been following this discussion with interest. As a Scrum Master / Developer, who is very soon to become a full-time Scrum Master, this seems very relevant to me.

I wonder whether people would have the same views if the Product Owner is able to do development work. I suspect in at least some organizations, it would be unthinkable that the PO would be asked/expected to step in.

So then I wonder, how well is the Scrum Master role respected? Are the Scrum Master's feelings respected? Does the Scrum Master see any dangers in stepping in to help as a Developer?

I feel that a Scrum Master who develops is compromised somewhat, because they are perhaps then seen by the other Scrum Team members as closer to the Development Team. This could affect the self-organizing behaviour of the whole Scrum Team, and the drive of other team members to push for continuous improvement.

If I were to step in, then I expect I would want to agree with the team on a suitable way to make the underlying problem transparent, so that the extraordinary nature of this scenario is widely understood, and that helping out in such a way does not become normalized.

I don't know much about Scrum, but I would see it like this:

One of the goals of Scrum seems to be to release the development team's Free Child (so that since people do things better when they are challenged and enjoying themselves, than when they are told what to do, then if you create an environment in which "what the team wants to do" and "what the company would find it useful for the team to do" align, you will get a better outcome).

From a Child perspective, the team would be perfectly correct in asking the SM for help (and, as per a comment above, would be entitled to be livid if that help was not forthcoming). This is equivalent to asking a friend for help when there is no expectation of remuneration, on the basis that they are your friend. I.e. since the team's operating environment is informal, then the request for assistance is also informal, and cannot be declined due to formality.

However, since the agreement to complete the sprint backlog comprises a trust-based contract, it may be incorrect to help the team, as this would compromise the trust relationship that exists between the company (which provides resources to the team, leaves the team alone, and expects the team to come up with the goods) and the team. In this respect, the SM not helping out, is like not paying your son's driving fine, on the basis that this would not help your son face reality.

I would posit that the SM present their quandry to the dev team what to do, and then follow the dev team's decision, which would progress the "personal growth" of the Scrum team at any rate. 

Definitely not an easy issue with a Yes/No answer !

The Dev Team is self-organized but before that, the Scrum Team itself is also self-organized.

To use Simon's example with the PO, I often see PO taking part in functional testing, wich mean for me that the PO has enough band-width to act as a Dev Team member with QA skills.

Beeing Scrum Master, we should not forget that we are also peer member of the Scrum Team.

The question that comes to my mind with this discussion is: When you're a fulltime Scrum Master, how can it be that you have the time to follow the development work of your team on such a deep technical level that you are able to just jump in at the end of the sprint and bail them out? If I had relevant technical knowledge for that situation I would be fine with sharing that with the team. In a sense of asking "have you tried this or that?". This still qualifies as helping the team to help themselves. If I had to join in a programming pair and look at the code and write code myself and if I as a Scrum Master am able to just do that without getting myself an up to date overview of the code base (which costs time the team does not have in that situation) I probably have never left the role of a developer.  

Timothy,

I see what you mean (thanks for sharing by the way), and I sense this as an education matter of the son/team too. You made me think further so my intention was to complement your analogy with the ‘other’ side of the story and show the two different behaviors that could (maybe) lead a scrum master to decide whether to step in or not when requested and under which terms. Both teams forecast inaccurately and both asked for help at the ending of a sprint. Considering both cases together, which team would a scrum master/father prefer to help?  Which one would benefit most if so? I see that ‘rewarding’ the effort of the team could be a reason fot the scrum master to step in and help, even though the outcome is not a total success. Of course the scrum master could say no to both and let the pain do the teaching, but… don’t you think that one team would suffer more than the other?

Simon,

Congrats on your full-time sm job :)

I feel that a Scrum Master who develops is compromised somewhat, because they are perhaps then seen by the other Scrum Team members as closer to the Development Team.

Well. I'd see that happening if the sm do development work multiple times when he is not supposed to. However some technical teams may feel rewarded if their scrum master is also skillful in the technical work they are performing, and probably more respected.

Christian

When you're a fulltime Scrum Master, how can it be that you have the time to follow the development work of your team on such a deep technical level that you are able to just jump in at the end of the sprint and bail them out? 

Aside from technical advising, more than that the solution to the problem resides in the scrum master's hands it is more like the extra pair of hands of the scrum master can help to do part of the work leading to finish the whole thing on time. Another new developer would do more harm than good at this point, and the SM is a) close in understanding to the increment being developed and b) able to help due to his technical skills.

I guess I benefit somewhat working as a Scrum Master from not having a technical background (I was a mainframe hack in the day, but I only have a passing knowledge of languages, concepts, and tools now).   It forces me to explore other ways to help the team besides stepping in.