Sprint Standup is Not Rollcall — A recipe to modernize your sprint calendar

This is an opinionated blog on Creative and Empathic Leadership. It is intended to spark the reader’s imagination on simple, yet creative patterns that leverage existing tools in their toolbox to keep staff engaged and motivated. In today’s employment landscape, famously dubbed as the Great Resignation mostly enabled by remote work, individuals have a broad range of employment opportunities, which is a good thing. Such environments should challenge engineering leaders to be innovative in establishing an engaging and ownership mindset from their staff while enabling a healthy, fun and caring, yet sustainable work-life environment in order to ensure employee retention. Mark McClain, SailPoint’s CEO and Co-Founder has posted several articles recently on culture and employee morale, bringing great awareness to this critical aspect of today’s working culture.

This article starts a series of creative methods a leader could employ to keep employees motivated, without necessarily dipping into the bank, assuming of course your employees are compensated fairly. We leverage tools in our toolbox to remodel existing processes that are showing of age or are not quite fitting with the expectations of today’s working culture.

Are you an engineering manager who requires a daily stand-up at 10:00 am? If so, I would pose a second follow-up question:

Given today’s plethora of communication mechanisms, methods and techniques, is there a need for your team to log into a Zoom, Slack or Teams every day at 10:00 am (enter your time zone) to report status?

And a third follow-up question to the above is:

Do you trust your team to deliver and do you give them the space and sense of autonomy to get their work done?

If your answer to the first question is no and your answer to the second question is yes, this article is for you. Any other combination of answers to the above questions may imply the opinions in this article do not quite align with your managerial philosophies but I’ll still recommend you give this article a read.

Having personally participated in many debates on agile/scrum including establishing scrum practices across a few organizations, a common concern expressed by developers is management’s lack of trust — the sentiment being that managers are trying to ensure their staff is working (or clocked-in), and in other cases, managers are using such meetings to educate themselves on system design, information readily (or should be) available in documented artifacts. From my experience, managers who exhibit the above behaviours have not spent sufficient time in the trenches crafting, deploying and operating production-level code, do not enjoy reading design proposals or commit to existing processes to document system design, do not find time to checkout and read code from Github or Bitbucket repositories, nor do they participate in pull requests.

Managers on the other hand may argue that daily scrums are used to identify and remove roadblocks, ensuring we remain committed to delivering on time, although such a point could also be challenged in today’s world of continuous delivery. Since there is merit to both sides of the debate we can, therefore, conclude that all such opinions or concerns should be factored in when evaluating your current processes.

Managers may argue that daily scrums are used to identify and remove roadblocks, ensuring we remain committed to delivering on time. And that point could also be challenged in today’s world of continuous delivery.

When I wrote code on a full-time basis, the thought of stepping out of the thinking zone (think context switch here) to attend daily scrum standup, especially on those days where reportable progress had not been made on a given task felt like rollcall. Merriam-Website online dictionary defines rollcall as “the act or an instance of calling off a list of names (as for checking attendance)”. In other words, rollcall is an activity for authoritarian settings such as boarding school and the military and should not be applied to creative professionals.

Scrum standups feel like rollcall

To maintain a sustainable level of commitment and excitement while maximizing throughput as an individual contributor, I made a conscious decision not to engage in tasks that required deep levels of focus before scrum standup. Instead, I would engage in research-related tasks, side-coding exercises, light reading, or any other activity that can be interrupted at a low cost. But let me digress for a minute….the borrowed image below succinctly captures some reasons why we should minimize interrupting software developers.

What am I saying? There are plentiful scrum meetings these days and developers generally do not care for these. Organizations transitioning from a waterfall to an agile culture do inject many more meetings into a developer’s calendar without considering the impact on overall developer productivity. Developers or Software Engineers enjoy writing code and even though this is just one aspect of their work, as Brian Conn founder of Connsulting LLC succinctly put it, writing code is often the most enjoyable part of a developer’s work. So what should we do as leaders? We need to be creative and practise empathy when introducing processes, questioning the very essence of these processes or modifying them to meet the workplace expectations of today.

In this article, we take the sprint calendar, which includes all the meetings that come with Scrum, on a remodelling exercise. But before doing so, let us review a few facts about Scrum:

• Scrum, as an Agile practice, finds its origins in 1986, according to this Wikipedia article. That was almost 4 decades ago!
• Scrum proposes a lightweight process to guide teams towards collaborative, iterative and incremental delivery but does not mandate how.
• Scrum is today’s most popular method for software delivery.

Scrum proposes methods to foster collaborative, iterative and incremental delivery

There is much more to the Scrum literature so why call out the above characteristics? To emphasize a key point: considering how fast the technology landscape evolves we can conclude that the activities prescribed with Scrum need to be morphed into the workspace expectations of today. For a typical Software Engineer, today’s working culture is characterized by remote work, an unlimited vacation policy, an emphasis on a healthy work-life balance, flexible hours, trust and empathy. Yet most, if not all, of these aspects of corporate culture were not a priority when the methods of scrum were invented.

Let remodel the sprint calendar and as with all software solutions, we first list a few key functional requirements that must be met by the re-designed sprint calendar:

1. As an agile software development process, I should minimize Zoom, Slack, Teams overload or management fatigue. I define managerial fatigue as a state of mind whereby employees are literally tired of seeing their manager, mostly as a result of too many monotonous meetings.
2. As an agile software development process, I should allow for team autonomy, and provide an opportunity for the team to learn, grow and reflect on things that went well or processes they can collectively improve upon.
3. As an agile software development process, I should minimize developer interruptions unless these interruptions are adding value to the developer’s workflow or improving their productivity.
4. As an agile software development process, I should ensure developers are maintaining a healthy work-life balance.
5. As an agile software development process, I should ensure sufficient visibility into sprint progress to ensure we consistently deliver customer value.

Given the above requirements, here is how we have designed our sprint calendar based on a 2-week cadence:

Sprint — Week 1

• Monday — day 1 of sprint. There is no standup given that the team just completed sprint planning.
• Tuesday — day 2 of sprint. 30–45 minute meeting run by a team member. Team members rotate running this meeting every month.
• Wednesday — day 3 of sprint. Slack/Teams progress report.
• Thursday — day 4 of sprint. 30–45 minute meeting run by the team lead. By this time employees are often thrilled to see their manager :).
• Friday — day 5 of sprint. The best day of the week! 30–45 minute meeting run by the team lead.

===== Weekend =====

• Monday — day 6 of sprint. No standup and next sprint grooming. Developers are not required to attend grooming but are kept abreast of upcoming initiatives asynchronously.
• Tuesday —day 7 of sprint. Same as day 2.
• Wednesday —day 8 of sprint. Same as day 3.
• Thursday —day 9 of sprint. 60–90 minutes of sprint planning run by the team lead in collaboration with PM.
• Friday —day 10 of sprint. Best day of the week and last day of sprint. 60 minutes of optional demos (not all work is demo-able) and 60 minutes of sprint retrospectives. We take retrospectives very seriously. After retrospective, the team is free to call it a day or engage in self-learning.

Slack, Teams, Google Meet, or whatever communication platform your organization adopts, is a leader’s greatest tool in such a setup to ensure continuous and asynchronous communication amongst all stakeholders and participants in the development process including PM, UX, developers. Such asynchronous communication patterns ensure your team is making good progress while allowing them the autonomy and flexibility they need to grow.

As you would have noticed, we added a total of 330 minutes or 5.5 hours of meetings time within a developer's bi-weekly calendar. If you compare this to the mandatory 300 minutes of stand-ups, not including planning or retrospective, you start to see the advantages of this modification to the sprint calendar from the developer’s perspective. Also what we have noticed with this modification is that developers look forward to these meetings given they have been carefully designed to be engaging and with a sense of purpose. In subsequent articles, we will cover the purpose of each meeting.

What we have noticed with this modification is that developers look forward to these meetings given they have been carefully designed to be engaging and with a sense of purpose

In summary, there is always going an employer who offers better pay. But when a leader is deliberate in using non-monetary levers to strike a balance between effectiveness, team building, relationships and empathy, they are indirectly communicating trust, humility and genuine care, factors that translate to employee motivation and engagement which boosts staff morale and resilience resulting to consistently high-performant teams.

The proposed schedule does not come without its managerial challenges. As leaders, we still need to ensure our teams are delivering on their promises. However, most of the leader’s role now revolves around readily providing guidance, coaching and mentoring as opposed to checking attendance, tracking metrics and chasing delivery dates. The proposed modification also does not mean employees will not leave for greener pastures. When they do, however, you can be certain they are looking for a growth opportunity which you could not provide and you should encourage them to do so.

Leaders, revisit current processes, be innovative and bold in their redesign, then sit back, trust, let go and marvel at the increase in developer productivity with your consistently engaging teams.