Software Development

Rituals are defined as a series of “actions or type of behavior regularly and invariably followed by someone.” No where is this truer than in Scrum rituals. So many Scrum teams repeat rituals so regularly, invariably, and mindlessly that they end up losing the benefits these rituals provide..

Like all things Agile, responding to change > mindlessly following a plan (or process) and teams should not be afraid of “retro-ing rituals” i.e. frequently assessing and enhancing their Scrum rituals through the use of ritual retrospectives.

Below are some of the most useful Scrum ritual changes I’ve learned, encountered, and/or implemented over the last 8+ years.

Daily Standups

Daily standups are one of the most abused Scrum rituals. An objective of having quick 10–15 minute alignment can quickly and easily turn to an hour of intense discussions. Not assessing and enhancing standups can easily lead to loss of interest, and a dip in attendance and productivity.

Here are a some of the most useful examples of evolution of the daily standup as a result of retro-ing:

To ensure focus and that people shift their mindset, start your standup with a 1–2 minute warmup exercise; nominate someone to ask a question that requires a one-or-two word response, ideally somewhat related to what everyone is working on. Some examples include “What is the feature that you are most excited about in the new module?” or, on a somewhat lighter side, “What did you have for breakfast?”
If you are late to the standup, or missed a couple of consecutive standups, don’t ask “what did I miss” in the middle of the standup. To get up to speed, schedule a quick discussion with your Scrum master.
Remote joiners need to be logged in 5 minutes ahead of the standup. Any setup to facilitate remote joiners needs to be setup 5 minutes ahead of the standup.
Conduct a standup retrospective surveys (use anonymous surveys) after 10 consecutive standups. Use feedback and learnings to reassess and enhance.
Absolutely no cell phones! (my personal favorite)

Sprint Demos

Demoable code a the end of a sprint is one of the key tenants of Agile & Scrum. Let’s face it, demos can also very easily turn into just another meeting or a one-sided talk that does not foster any kind of engagement or excitement. In addition, demos can become a very formal affair where feedback and discussions are discouraged, or limited to just key stakeholders.

Some of the most impactful demo changes I’ve encountered fall under the umbrella of openness/encouraging participation, and “switching it up”.

Encourage inactive participants to share their inputs openly; questions, and feedback should always be welcomed.
Enable typical non-presenters, like engineers, to conduct the demos.
Have a varying mix of participants in every demo; invite people from outside your direct teams. Cross pollination is important!

Sprint Retrospectives

The least popular, most misused and misunderstood part of all Scrum rituals.

The reasons retros are not conducted as seriously or frequently as other rituals is that Product teams don’t equate the importance of internal feedback with the importance of external one.
In addition, it’s never easy to be completely candid around your team ; fear and anxiety seem to always get in the way.

One cannot possibly fix something without knowing it’s broken to begin with.

Some of the changes that I’ve seen and conducted make feedback more actionable and attempt to ease fear and anxiety to really enable people to talk.

Feedback without action is pointless. Apart from simply discussing the “what went well, what did not go so well, and what we can do to change?”, the feedback should be translated into actual tangible and measurable improvements that have to be discussed and reviewed at the beginning of the subsequent retros.
To enable people to speak freely, I experimented with coloring (yes, coloring as in adult coloring books) during my retros.

According to scientific research, coloring has the ability to relax the fear center of your brain, the amygdala.

I still remember the look of shock and utter incomprehension on attendees’ faces when they walked into the retro meeting and saw coloring books and pens on the table. To everyone’s credit, they kept an open mind, and started to color. At a certain magical point, we all really felt that the mood became much more relaxed, and for the first time, the attendees starting really talking.

With constant pressure to fail fast and ship fast, digital product people oftentimes oversee a fundamental rule to any solution-driven output. They fail to dive deeper into their “raison d’etre” ; the problems they set up to solve for the people who encounter them.

Principle I: Become infatuated with a problem

As digital product people, we are entrusted with translating our understanding of a problem and its ecosystem (industry, location, environment, people, etc.) into a workable solution by using features and pieces of functionality that address the problem, and then deciding when and how to make those available to people who need them.

Without an intimate understanding of a problem and its ecosystem, to the point of making it our own, and lacking empathy towards the people encountering it (i.e. users), our solutions are bound to fail, no matter how beautiful or technologically superior we make them. For example, many tech pundits attribute the failure of Amazon’s Fire Phone to product teams falling in love with their own problems and creating solutions like “scan any item then buy it from Amazon” that do not address a concrete problem or need, and are of little-or-no-value to users.

A good analogy would be that of a doctor; No good doctor is willing to provide a diagnoses, medication, or remedy without a prior systematic and intimate understanding of the patient and the illness. A misdiagnosis would not only mistreat the underlying illness, but it could very well backfire.

Over the course of a decade in the product space, the deep understanding of problems and a user-empathy philosophy has been a rallying cry for my teams and I, and has helped us ideate and launch dozens of successful user-centric solutions for startups and Fortune 100 companies alike.

From my own experience in interviewing, hiring, training, and managing product-people, that philosophy is the differentiator between an average product-person and a stellar-product person. Instilling that philosophy and attitude cannot be easily taught, whereas other skills and processes can be.

According to various product publications and studies (from the likes of HBR, ProductSchool, ProductTalk and others) one the key characteristics to look for in a product person is empathy.

Below are some of the techniques that I continue to leverage to enable myself (and others) to truly become infatuated with a problem:

Communication

Talk to your users, and as often as you can. More specifically, actively listen and let them do the talking, whether in the form of informal chats, formal interviews, focus groups, or one-on-one sessions. Always schedule follow-up conversations, share learnings, solicit additional input, and ask for advice. Have them react to your “solutions” (ideally in the form of prototypes), attend your demos, and weigh-in on your roadmaps. Prepare questions that help focus the conversation on problems, and keepreminding your users to resist “solutioning” on-the-fly.
As you interpret the responses, don’t be afraid to admit that you may have misunderstood a problem. Sometimes, the best course of action is going back to the drawing board; that’s what a good doctor would do.

Data Enrichment

Surveys: Carefully craft your surveys, avoiding loaded questions and incomplete / incoherent response options. The most important tip is to keep your own bias in-check when interpreting the results.
Analytics: If you are not building a product from scratch, analyze behavioral data collected through like Google Analytics or Azure Insights, in parallel to your continuous conversations.
User Personas: A fictional character and state description created to represent a user type and have a common team understanding and agreement on key user characteristics, and problems /needs faced. A standard practice within many human-centered design principles, personas “help you step out of yourself(…) to identify with the user you’re designing for.”, as defined by the Interaction Design Foundation.

Immersion: Make it your own

My personal philosophy and the most powerful form of true heartware development. Although challenging to achieve, nothing beats getting first-hand experience with a problem and becoming the user. That unique perspective enables you to act, feel, think, and ultimately make the best decisions for your users.
Many successful tech startups, like WhatsApp, arose from founders who faced and became infatuated with a specific problem. Jan Koum, one of the WhatsApp co-founders, revealed that the idea for Whatsapp came about so “he could stop missing out on calls on his new smartphone”.

Force20

Posts tagged: Software Development

Better Scrum Rituals: A Retrospective