Although Remote work (or) Telecommuting (as coined by Jack Nilles, the Father of Remote work) has been in existence as early as 1970s, the emergence of revolutionary changes ranging from wi-fi in early 90s to the proliferation of state-of-the-art mobile devices and ultra-fast internet connections (Remember Moore’s Law?), ubiquity of cloud-based storage, SaaS solutions and drastically optimized costs in the last decade have expanded the landscape of work much beyond the confines of office spaces, creeping into our drawing rooms. Of course, Covid pandemic has certainly created an unprecedented surge in the long-term remote work with millions of people experiencing the flavors of it. 

Numerous Research studies across the globe carried out by McKinsey, Gartner, Buffer etc., in the last few years throw some interesting insights on the increasing footprint of remote working, the challenges that it triggers, and the implications thereof, especially in the wake of the current pandemic. These studies reveal some of the emerging trends in organizations across the globe, such as reduction in stigma towards remote working, inclination towards 100% remote working, setting up remote-friendly policies, stepping up remote security, altering work cultures and practices, promoting coworking spaces, synchronizing communication and collaboration, and finding new ways to boost productivity by adopting digitization and automation technologies, AI etc., to name a few. 

In this session, , let’s explore a few thoughts on how our remote working environments can be swiftly transformed into a more collaborative and productive workspaces, especially in these pandemic times by striving towards optimizing and streamlining the collaboration and communication channels, synergizing best practices, coaching and empowering the teams to solve the problems on their own, and make them self-organized, which is critical in maximizing the productivity of the teams.

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.

As defined in the Scrum Guide, the role of a Scrum Master is responsible for promoting and supporting Scrum, by helping everyone understand Scrum theory, practices, rules, and values.

But in practice, we often see this important role as an "extended" role, an "additional" responsibility, usually played by project managers or any of the senior member of the team who is expected to "make things work". This role is often pushed into a dilemma between the "expectations" (to solve every other problem that the team faces) and "reality" (to take a step back and let the team get empowered to solve their own problems).

While the role includes facilitating a conducive work environment for the Scrum Team, guiding and teaching Scrum practices to everyone involved in the project and clearing impediments for the team, it also includes facing resistence from the teams, management, stakeholders and sometimes, probably of all them put together. The challenges could vary from "Time-boxing the Daily Scrum Meeting to 15 minutes" to "the extent of owing the team's deliverables on a whole".

This session aims to take a realistic look at the usual challenges (and probably any unusual ones too) that the Scrum Masters face and try to understand some best practices centered around this role as an outcome of the discussion.

First things first, why "Velocity" alone, when there are many other factors (requirements, estimations, defects, automation etc) which would help arrive at a Team's maturity? So, with so many other factors in the ambit, why does this session emphasizes on "Velocity" alone, while I could have just easily entitled this session as "Various factors influencing a Team's Maturity"?

Let me start with the statement that "The more the velocity, the more the more productive the team is and hence more matured". It sounds fairly correct right? A team with more velocity is more likely capable and productive and hence more matured. Isn't it?
But wait, consider this!
> What if the team has shown significant "progress" in increasing their velocity but at the cost of team's burnout?
> What if the team has increased their average velocity by X percent but has compromised their quality?
> What if the team has padded their product backlog with the list of stories which are more of "non-functional" in nature which don't necessarily add any business value?
> What if the team has "bloated" their velocity unusually by sometimes(or many-a-time probably) by projecting simple tasks as stories-with-a-business-value?

Can the team be branded a matured?

And the reason as to why the team resort to such anti-patters to "save their velocity" is because "Velocity" which is ought to be the primary measure of a Team's progress, has metamorphosed into a "performance metric" leading to the teams (their leadership hierarchy too) becoming conscious or (rather "obsessed" in many cases) with Velocity so much so, that in order to "preserve" or "increase" their velocity, teams can resort to anti-practices such as extending the sprints, bloating the story points, add stories that don't add value only to "maintain" velocity.

Having said that, while its true that Velocity is certainly a critical indicator to measure of the amount of work a Team can accomplish in a sprint, it should also be seen in the context of the team's ability to maintain a consistency in achieving the velocity and at the same time, take a closer look at the team's definition of velocity itself.

Notwithstanding the above points and considering that a team gets them all right, can we then say that Velocity drives a team's maturity? To an extent, Yes. Velocity can be an indicator of a Team's Maturity but it cannot be the ONLY factor determining it. Among other factors, Maturity can also encompass how effectively the team tackles the dimensions such as "planning", "quality", "practices", "communication and collaboration" etc. (the list is exhaustive).

It is in this context that this session aims to throw some light on what "Maturity" and how "True Velocity" can contribute to a Team's maturity and discuss about numerous other factors that contribute to a team's maturity, such as a team's ability to break the silos and "self-organize" themselves, adhere to "practices", learn to cultivate "mutual Trust", "team commitment","collective ownership" and many more.