Get Rid of Daily Standups and to Get Engineers to Update You Daily

As a project manager, one of the common challenges in your day-to-day work is having to extract timely and insightful status updates from engineers. In my experiences, one-on-one or in daily standups engineers are very capable of explaining their current project trajectory provided you probe and question right, but having them put it on Jira or any other project tracking tool on a daily or even semi-daily cadence, is a different kettle of fish.

Absent of current and relevant information at hand, you won’t be able to navigate any risks to the project, resolve dependencies and communicate accurately to your stakeholders. So what do you do? It is all a matter of cultural engraining, but in my mind, there are two options, but both will entail getting rid of daily standups.

Daily Standups in Jira

Engineers already huddle over to provide answer their daily scrum 3-question ritual of 1) what did I do yesterday, 2) what will I do today, and 3) am I blocked on anything. In order to save time going around the table, an optimal approach would be to set a reminder in lieu of your daily standup, to have them update their tickets answering the three questions. This will alleviate them of the annoyance of having the entire team being blocked for 15 minutes (or even more!) and answering the same questions, and instead have them asynchronously and from the comforts of their chairs (or standing desks) provide the update in writing.

Converting daily standups into daily Jira updates, saves the engineers from being forced to verbally huddle in standups, and ensures project managers get written updates in a predictive and consistent manner.

Commit(ing) to Updates

Another idea may be to have the engineers engage in providing more meaningful updates earlier on, and this requires a bit of a re-working of how they code. By having a mechanism in place for engineers to ensure they commit to code at least daily, they can answer the scrum three-question status update in their git commits. Leveraging smart commits for Jira, the updates would then be synchronized with the ticket and provide project managers with the same high-fidelity insights, but without engineers having to engage in Jira, but stay within the confines and comfort of their terminals to provide commits and pushes.

In Summary

Regardless of which option you advocate for, this is a cultural change initiative and you will have to sell it to the teams. You will have to explain why this would benefit both parties, how you will save them time in going to standup huddles and instead work from the comfort of their desks. Explain how this contract between you and the engineers will ensure stakeholders won’t hassle you.

Embracing the Agile manifesto

Something as a practicing program manager I tend to always use as tenets when guiding teams, is relying on the spiritual bible of contemporary project management, and that’s the Agile Manifesto. Products of the Agile Alliance, the premise of the Manifesto is to simplify the practice of project management through a lightweight framework to build software expeditiously with bias for customer validation over processes and documentation and red tape.

The two drivers behind the manifesto are iterative and incremental development, over pre-medicated and over planning, and creating higher quality software in shorter time, or more concisely, build more with less.

Something as a practicing program manager I tend to always use as tenets when guiding teams, is relying on the spiritual bible of contemporary project management, and that’s the Agile Manifesto. Products of the Agile Alliance, the premise of the Manifesto is to simplify the practice of project management through a lightweight framework to build software expeditiously with bias for customer validation over processes and documentation and red tape.

The two drivers behind the manifesto are iterative and incremental development, over pre-medicated and over planning, and creating higher quality software in shorter time, or more concisely, build more with less.

The Agile Manifesto

I see the Manifesto as guiding principles, tenets as I mentioned earlier on, rather than rigid and enforced rules, advocation for the spirit rather than the letter of the law. So does the Agile Manifesto entail?

Individuals and Interactions over Processes and Tools

To me this infers bias towards the human element over procedures. Engaging customers, stakeholders, other team-members. It is not to say that processes and tools aren’t important, but the scales should favor people over process.

Working Software over Comprehensive Documentation

Following the spirit of being lightweight, don’t focus on heavy documentation, over-planning but build early, build fast, and iterate fast. It is therefore emphasized that working software that meets user acceptance criteria, even incrementally, over detailed documentation.

Customer Collaboration over Contract Negotiation

The Agile mindset is one that is flexible, and embracing requirements that can change. Pivoting is something that has to be accepted. This is not to say that contracts aren’t also important, but getting the right requirements from customers is favorable to rigid contracts.

Responding to Change over Following a Plan

Change is inevitable, the only constant is change, and that’s why heavy documentation is doomed to failure, because of the nature of change. Instead build components in a decoupled and nimble manner that fosters change, and work in an environment that allows you to react to changes based on new understandings.

The Agile Manifesto does not suggest that we do one over the other; rather, it advocates that while all of the mentioned items are important, some are valued more than the others.

PMI-ACP Project Management Institute Agile Certified Practitioner Exam Study Guide J. Ashley Hunt

The one thing agile teams miss when WFM: Osmotic Learning

Overwhelmingly, tech companies have transitioned their sprint iterations from co-location to having teams work remotely, from home. The Covid-19 pandemic has forced teams to change how they interact with each other, perform agile rituals and deliver products. 

One thing that is missing, is osmotic communications, learning through accidentally overhearing.

Overwhelmingly, tech companies have transitioned their sprint iterations from co-location to having teams work remotely, from home. The Covid-19 pandemic has forced teams to change how they interact with each other, perform agile rituals and deliver products.

If you were to ask scrum masters and developers at large companies like Apple and Amazon, or early startups, most would concur that by-in-large, they are just as efficient working from home as they are coming into the office. Collaborative tools such as as Slack, Zoom, and Atlassian’s Jira, have made the transition smoother.

But for all the technology that aims to bring disparate teams virtually together, there is a specific element that cannot be resolved through technology, and that is osmotic communications.

What is Osmotic Communications?

Concocted by one of the founders of the Agile Manifesto, Alastair Cockburn, osmotic communications is the inadvertent overhearing of background information through co-location, that may later end up being important.

“Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis.” (Cockburn, 2005)

Source: https://www.simplilearn.com
Source: https://www.simplilearn.com

In other words, the ability for members of the team to audibly pickup information flows through background hearing of other team members, most commonly accomplished through co-location, by being in the same room. When someone is talking, another person can either tune-in or tune-out, “contributing to the discussion or continuing with their work”.

Webster’s dictionary defines the term as: “a process by which information is exchanged between individuals through a common system of symbols, signs, or behavior”.

The following video by Joshua Render provides a great mini-dive into the agile topic:https://www.youtube.com/embed/rCNlG_j_gSM?wmode=opaque&enablejsapi=1

As a real-life example, when I first moved to San Francisco, taking my MacBook with me to a coffee shop on Market street. Across the shared table there is another two guys working on an app and discussing some challenges to solve a backend problem.

They were talking about a cloud solution that at the time wasn’t as mainstream, but nowadays has become more common. Eavesdropping, I overheard their conversation, and injected myself in with my thoughts, and we ended up having a long philosophical and technical deep-dive into their problem.

Being physically present, beyond the inter-personal relationship building, you also loose the ability to exchange thoughts in an informal and accidental way.