Tag: Scrum

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.

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

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)

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.