Value-Added Role: Technical ScrumMaster

How a TSM Can Help Elevate the Team's Performance

12 February 2014


The Technical ScrumMaster (TSM), meaning the SM with a technical background, has a role that carries a lot of weight apart from being a negotiator, facilitator, and/or servant-leader. (And all my expectations of the technical TSM also assume that he is proactive.)

Why do I emphasize the TSM? Before I answer this, let us understand the primary suspects that cause the failure of a Scrum project -- apart from standard reasons such as scope creep, PO unavailability, lack of domain knowledge, the Scrum process being undefined or not religiously followed, etc. These are a few reasons, in my experience, that are also sure recipes for failure:
  1. There is no follow-up on the team's understanding of user stories.
  2. User stories mapping to a single feature are overlooked.
  3. Acceptance criteria provided by the PO are accepted without any negotiation.
  4. Unit testing is often neglected.
  5. There is no contingency plan to tackle defects during the Scrum cycle.

Now imagine this situation: We have a TSM with respectable overall experience; coming from a programming background; having worked across various front ends, middleware, database aspects, etc. Does this alert you to anything?

It does for me. What I've learned from my experience is that a technical TSM is the 1 percent that takes your 99 percent effort to Done! Let me map my thoughts to the problem areas I described above.

  1. There is no follow-up on the team's understanding of user stories. An experienced TSM is quick to identify whether we have come to a realistic story (or epic) and whether further drill-down is needed. Once there is clarity from the PO about what the user story requirement is, a TSM can follow up with the team first, understand what they understand, and help them get to the task level. Now, there is a catch here -- if there is difficulty in arriving at a technical tasks breakdown for the stories, this is where your TSM (ideally) gets back to the business, communicating the team's understanding and seeking further clarification. After all, is't it good to invest a little more time in understanding a requirement rather than later injecting a bug, just because we did not clarify?
  2. User stories mapping to a single feature are overlooked. Now here the TSM may not be of immediate help, but let's think a little further. Going ahead with sprints, when the product vision and the product itself start evolving, shouldn't we try to map business-critical needs with the features that can be easily and rapidly implemented, since we have some base architecture that was written for prior requirements? Of course we should try! And we should be telling this to the business side as well. But wait -- who is going to help identify those needs and features? The senior technical folks from the team! We might have an architect on the team, but he might be too tied up with the ongoing technical challenges. That's where we have a value add from a TSM; he can help identify and fill such gaps. After all, it's a delivery thing, and we want to be on time.
  3. Acceptance criteria provided by the PO are accepted without any negotiation. OK, now it gets a bit serious. I have sincerely thanked all my POs who have given me great acceptance criteria and been willing to ask for it when it hasn't been given. But how about the POs who've given acceptance criteria out of limited knowledge? Sometimes we need to consider whether the PO has really taken the holistic view into consideration, with all the challenges that the team might face while implementing the feature, any upstream or downstream applications that get affected, whether we expect data that is a replica of the production environment and what the are constraints in such cases, and so on. This is exactly where the TSM can (and should) be bold enough to stand up to negotiate -- and renegotiate -- on any additional acceptance criteria that need to be considered. In my opinion, that's for the better in terms of trust, credibility, respect, and ownership -- not to mention quality, risk management, scope management, and so on.
  4. Unit testing is often neglected. May I preach and teach to perform unit testing if I haven't done it myself in the past? Maybe I haven't been very consistent with it, but I might be a bit more aware of the unit testing implications, and might be able to talk that language, if I had been a programmer at some point. By no means am I trying to say that non-TSMs do not understand the very essence of unit testing. However, if the TSM can help arrange a session on unit testing, that does contribute that additional 1 percent that helps the team. Acceptance tests that are written from the acceptance criteria can be a base for part of unit testing. (I am doing a bit of combining #3 and #4 here.)
  5. There is no contingency plan to tackle defects during the Scrum cycle. Rather than talking about a particular process, I will share a practical experience. I have worked with distributed Scrum teams as a TSM (note the T) and, at times when the team desperately required a breather from the user stories, I would update the code on my machine, run some unit tests, fix the defects found, and ask the testing team to test them. All because I had been a programmer in my past and never gave that up -- being a SM was a choice.

I once had a very nasty but proactive set of testers. They used to come up with a handful of defects just when we stood up for the upcoming sprint planning session. All right! Now it was game on. I had to communicate to the PO during that planning meeting that we had a handful of defects that we would have to take as P1, since previous stories were incomplete in all practical senses because of these defects. And trust me, the PO did understand this, because it was about quality. But again, I still had the dedicated set of developers of my Scrum team ready take on some upcoming user stories while I got my hands dirty with the defects, ensuring that I got it reviewed from the developer who owned the code. I was relying on a lot of good practices here -- teamwork, green builds, unit testing, trust, no hierarchical foul play, taking the pressure off the team, and overall building a fun environment to work in.

Now a vote: Isn't a Technical ScrumMaster definitely a value-add?


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (2 ratings)

Comments

Ravishankar N, CSM, 2/12/2014 7:55:40 AM
Bhavin, a good article that provides practical examples to show that the 'T' side of the Scrum Master is indeed an added value to the Scrum Team.
Zach Bonaker, CSP,CSM,CSPO, 2/12/2014 10:33:31 AM
Interesting article. After some thought, I'm still on the fence over your statement: "isn't a technical SM DEFINITELY a value-add?"

I get the impression that your emphasis on the "T", suggesting the ability to coach beyond Scrum and into the solution-space of the sprint goal, is a shift from servant-leader to leader-servant.

When I review your list of problem areas, I believe that the first three fit within the realm that any ScrumMaster should be capable of coaching a team on. Given that the Team is responsible to commit to the work, empowering a team to have the conversations that lead to acceptance & commitment shouldn't require the "T".

For problems 4 & 5, certainly technical knowledge will be of help. But if the organization lacks skill and commitment to unit testing, automation, and defect management... in my opinion, the problem is substantial; well beyond that of the Team-SM relationship. As management in such a firm, do I want my ScrumMasters focusing on maximizing the success of the Scrum framework... or performing technical training and knowledge transfer?

The concern I have is that such emphasis on technical ability as a value-add could step into the realm of one person playing two roles - in this case, Team & ScrumMaster. Clearly your article doesn't suggest the SM taking on sprint tasks, but there is some threat of a highly technical SM influencing the team's direction & solution - especially in problem 2.

I think in the end you make a great case that the "T", as applied to a ScrumMaster can be a powerful asset. But it also has the potential to hinder the team from growing, learning, and discovering as I suggested above. Thus my hesitation in agreeing that a "TSM" is "definitely" a value-add.

For me, in the end, because the Team is responsible for the work, I want the "T" to be strong in the Team... not the SM. Above all else, I want my ScrumMasters to be highly capable of conversation, building social capital as change agents, and fostering collaboration. If an organization does not have technical resources to assist teams outside of its ScrumMasters... that's a problem, not a value-add solution. Is my opinion in the minority here?
Ravishankar N, CSM, 2/13/2014 12:44:19 AM
Zach Bonaker, good comments. I agree that the 'T' should strong in the team. And of course you cannot rely only the SM for the technical activities as well.

However, an SM with a T could add value by a better appreciation of the overall solution being proposed to the business rathern than depending on the team to provide that insight. And one of the technical team members playing the SM role is quite common, isn't it?
Ravish Subramanya, CSM, 2/13/2014 5:17:37 AM
Good perspective Bhavin!!!.
Though having a TSM helps to a great extent. In this case,
You are trying to see a Scrum Master to be technical and the points listed are biased on engineering practices.

This may induce a very strong bias which may affect the team to a larger extent. Especially when we have multi-disciplined teams (Dev, QA, UI Designers, Documentation, etc.)

Scrum Master should be focusing more on the softer side of communication, facilitation, interaction with the team rather than being extremely biased on any side.

Inline with @Ravishankar and @Zach, the T should be a inherent quality built within the team and focus should be to foster it over a period of time.
Kamal Hasan Kotapati, CSM, 2/16/2014 1:31:05 AM
Good article. I totally agree with technical knowledge of SM will give value add to the team. As you know, the main purpose of SM is to ensure that the team is focused on the goal without any deviations. If SM from technical background, he/she should be diligent enough not to deep dive into the technical discussions/decisions (human tendency is to involve more on primary skill area). He/She should follow bird’s-eye view concept in such cases otherwise the purpose of SM in team will not be fulfilled/achieved
Neeraj Malkoti, CSM, 2/18/2014 2:44:29 AM
Interesting observations, Bhavin.

However, TSM sounds like a waterfall Tech team lead to me.

Here why's:-
#1. IMO, Story mapping ( as part of backlog creation/refinement) can be facilitated by SM (if team chooses so).
Audience should include PO, SME & Team (ideally colocated/ same room).
SM should coach teams on various splitting techniques.
If there are challenges to split story further, everyone discusses & agrees next steps (being colocated).I don't see a reason for SM to act like a PM "gets back to the business, communicating the team's understanding and seeking further clarification"

#2. SM can provide inputs or suggestions ( technical too) but team decides if they would like to consider.
Being Technical helps but in longer run, team needs to make their own decisions (self managing)

# A goal for SM is to coach & transform organization to become learning centric rather than delivery centric. Hence over longer run, SM would need to detach himself from sprint outcomes & invest more time in fixing organization impedinments.

#3, 4
I would imagine that SM would suggest to teams, discussing importance of unit testing etc (promote agile/lean concepts).
SM should also coach PO on acceptance criteria ( as a way to serve PO organization)

An effective SM would coach teams on effective negotiation skills.
#5. Not sure I understand "team desperately required a breather from the user stories".
Rather than fixing defects, do you think it will be more helpful if team discussed this issue in retrospective ( facilitated by SM)

Multi skilled SM will surely help.
A team so closely guarded by SM will not fail, hence won't experiment & will not innovate.

I'd suggest we let them fail sometimes. It might just help them in longer run.
Poornaselvan Jeevanandam, CSP,CSM, 2/22/2014 8:45:03 AM
All value adds especially the ‘cross-functional’ and ‘going beyond the boundaries’ ones, certainly add to the quality and productivity of a team.
Contributions to the team more than what is primarily required of one should certainly be welcome. It is a sure to make up for that occasional lapse on someone else's primary responsibility
As long as there no dereliction of the primary responsibilities of an architect/tech lead because of a backup is in place in the TSM and/or there is no "stepping on others shoes" kind of a feeling, it should be a good thing happening to the team.
Again, every team and its members are unique,and this has to be considered as the key factor, in evaluating matters like these.
Sweta Paul, CSM, 3/24/2014 6:09:44 AM
I agree that having an SM who has technical knowledge is a value add. Does this mean that the JD would describe a Tech Lead with Scrum knowledge? Isn't this what a TSM boils down to?

I agree with the first 4 points mentioned by Bhavin. But this does not require a SM who is proficient in the technology of the project. If the SM has been a developer ever, he/she should be able to contribute effectively. He/She would only need a logical-problem solving frame of mind.

As for the SM getting his/her hands dirty, in fixing defects, this goes against the main tenets of Scrum - to have a self managing team! This turns the SM into a Tech lead. I respect Bhavin's love for programming! But I do not support the idea of the SM working on the team's tasks. The SM should help resolve the impediments.

If the team needed a breather, couldnt that mean that they had bitten off more than they can chew? May be, they can accept lesser story points the next sprint instead. The SM should work with the PO to help them understand that the team wasnt able to cope with the pressure. The current sprint would have failed - some story points not completed. So what? The retrospective should have pointed out the obvious reason - accepting too may story points, or under estimation, or a team member calling in sick, etc etc.

You must Login or Signup to comment.