Three Ideas for Better Remote Daily Scrums
As an extrovert who grew up mostly in the New York City area, I’m highly attuned to sense and seize the tiniest microgap in any conversation. As a reformed command-and-control IT program director, I’ve striven in my roles as scrum master and Agile coach to allow my teams the space to step up, be more self-sufficient, and take ownership for their improvement.
Nowhere does this come more into play than in daily scrum. With my collocated teams, I had been able to step back and do little more than nod or raise an eyebrow to get the next person to speak up. This low-touch style has been less effective in the new all-remote world, leading to some lengthy, awkward silences in the spaces I’ve left for my teams to contribute.
Communication style aside, the daily scrum for many teams tends to represent little more than a status meeting, where team members drone on about what they did the day before.
“Yesterday I… “
“Worked on the latest fire drill…”
“Did lots of paperwork…”
“Had a lot of meetings…”
“Ditto to what Sharon said.”
Little wonder people are disengaged and multitasking during scrum. Rather than listen to each other and being ready to interact, they’re focused on getting in and out of scrum as fast as they can
Yet despite the current challenges we face, there exists the possibility that we can not only survive, but prosper in this environment. I’ve uncovered three simple approaches that have helped revitalize my teams’ daily scrums, and if applied consistently and coached, I believe can bring significant value to your teams, as well.
The Real Value of the Daily Scrum
In my view, the two most critical reasons for the daily scrum are to
- Recommit to the sprint goal
- Recommit to each other
If you’re not accomplishing those two pieces at least to a certain degree every day, I believe you’re indeed not only wasting your time, but that of the rest of the team. And it all starts with recommitment.
Recommitting to the Sprint Goal
Without a clear goal for the sprint, the team will be scrambling, unsure of why they’re there, and what most needs to happen next.
The Sprint Goal is a high-level statement focused on the outcome of what the team’s working to deliver within the timebox (“Lay the foundation for our next-generation client experience focused on more individualized and interactive advice”). This is not the same as the list of everything in the Sprint Backlog (User Stories #142, 144, 278, 342, the output). Maarten Dalmijn has written a great piece here on Sprint Goals and their fundamental value to Agile teams during a sprint.
What Each Team Member Can Share
I believe that by encouraging people to slightly shift the content of their scrum contributions – towards a focus on how they’ve directly contributed towards the sprint goal, share what they might need, and what they can offer the rest of the team:
- How have I (personally, uniquely) contributed to the Sprint Goal?
- Where have I experienced challenges that I could use some help on?
- What insights have I gained that could benefit others?
- How and where can I be of help to anyone else on the team?
Recommitting to Each Other
In the course of recommitting to our shared purpose during this sprint, and having each person contribute how they’re bringing the team closer to the shared goal opens space for other team members to say, “Hey, I had that problem as well, and got it resolved. Let’s chat after scrum and I’ll tell you how I fixed it. Anyone else who needs help is also welcome to join.”
It Doesn’t Always All Have to be About the Work
Daily scrum can also be a great opportunity for the team to briefly reconnect on a human level – something fun you might have done over the weekend, a quick poll, a book worth reading, favorite meme, etc.. Laughing and having fun is another essential element in the recommitment process and helps bring the team closer together.
How Can We Do This Better Virtually?
With everyone now distributed, it’s trickier for people to understand who should contribute next. My aforementioned extroverted and directive nature wants to jump in and control things, where I’d like to provide the space for the introverts to have the time they need to reflect before sharing.
My Agile Coach colleague at Key, Michael D. Blackwell, provided a great suggestion that neatly ties everything together during scrum. Once the first person has shared, they each in turn pick the next person to give their contribution, going through the entire team. I’ve been pleasantly surprised to see how effective this simple technique can be in allowing all voices to be heard, opening up the space for the team to organically manage itself. It’s also cut down on multitasking, as everyone needs to be on their toes, focused on who’s talking and ready to go next if called upon.
In Summary- Recommit!
Remember…
- Recommit to the Sprint Goal (your team has a sprint goal, don’t they?)
- Recommit to each other by connecting and sharing your contributions toward the sprint goal
- Each person picks the next person to share
Try just these three small things, continue to coach and encourage your teams to make them second nature, and see how your teams start to look forward to daily scrum, nurturing a more vibrant team culture along the way. And once we’re all back standing together again in our team rooms, let’s see if we can continue to engrain these daily habits and how they continue to build collaboration through recommitment, bringing more meaning and value to our work.
Photo Credit – By PierreSelim – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=17336884
Will There Ever Be Enough Dev Cycles?
Has Agile Let Us Down?
Are developers really the bottleneck?
In a recent meeting, a senior executive asked a product manager why they couldn’t deliver more of the features requested for an upcoming quarter. The PM replied, “I would, if I could just get another four developers.”
After 20 years in tech, across a wide array of web & mobile front- and back-end technologies, with everything from tiny startups to established, 200-year-old enterprises, I’ve seen this pattern emerge consistently – the underlying assumption that software development is the blocker.
And increasingly over the past 10 years, there’s been this hope that Agile would finally fix that problem.
I believe that software engineering shortages are not a cause but a symptom. We’ll look into where the real problem lies, why asking Agile to fix the problem has created more issues. and where I believe the real solution lies.
Product teams are tasked with delivering from time-sequenced roadmaps, typically made of a random series of stakeholder commitments. Planning is done in advance either every quarter (if teams are lucky), or up to a year or more in advance.
After months of requirements gathering, when the work finally comes to the product team for action, it’s either been elaborated too far in advance in isolation from the team, or cryptically vague. Stakeholders then decry that teams aren’t moving fast enough because they’re unable to get these requests built and delivered at their arbitrarily-dictated roadmap cadence.
Agile to the rescue?
Agile was tapped by the enterprise for one reason – To fix the development team’s efficiency problem. Note one of the original Agile Manifesto signees, Jeff Sutherland, gained notoriety a few years back with his book and associated TEDx talk touting Scrum as the way to get your teams to do “Twice the Work in Half the Time.” (i.e., 4X the work…?)
This is absolute catnip for executives and stakeholders of all stripes tired of waiting for their pet projects to get delivered. So the goal of Agile in the Enterprise has really been focused on getting teams super-efficient to pushing out everything on their roadmaps.
Why are teams being asked to build these things?
With this sole focus on efficiency, and building and delivering “stuff,” that no one has thought to question-
- How good are these ideas? Are they as good as we think they are?
- Will they really make our clients happy and successful?
- How will they contribute to tangible business value?
Set Up to Fail
Given this dynamic, even when product teams are delivering efficiently, all kinds of worthless things that clients will never use can get quite efficiently pushed out the door. Worse, the really important things that clients really do need are getting missed because large enterprises tend to organize around internal silo structures, rather than end-to-end client experience value streams.
Without that client experience-centricity, it’s only natural that key pieces get over-engineered while other critical gaps occur.
And when things do go off the rails, IT continues to put product teams under the efficiency microscope (burndown), while “the business” plows ahead in isolation on an unending stream of disconnected feature request ideas, stocking roadmaps stretching off into the future.
But if the team has just shipped 2-3 features with their latest release, and one of them has not only negated the other two, but beyond that, caused entire critical segments of their user base to get frustrated and churn, what should happen then? And who’s supposed to be tracking that and take corrective action?
Product focus to the rescue
I’ve become increasingly convinced that enterprise embracement of a product focus, versus a legacy project focus, can provide a clue.
As leading product- and design-driven companies like Netflix, Amazon, and AirBnB demonstrate, the goal of modern software development is never on problem-solving over delivery, where the best teams drive a continuous organization-wide learning process, where savvy leaders strive to optimize for effectiveness, build just enough to learn from, and continuously Iterate.
What gets managed in Product Management?
Product managers manage neither the development team, nor their work. Yet without a Product Management focus it’s impossible to provide holistic meaning and clarity around what teams should be building, when, and why.
Not Just Competing Stakeholder Requests, but the Unfolding of a Vision
Instead of efficiently pushing out lists of features in isolation, product-driven teams are focused on the higher-level organizational vision – how does that flow to strategy, and how can teams continuously deliver on that strategy by delivering on measurable, data-driven changes in user behavior.
IT Project vs. Product Focus
Now take a step back and remember how IT tends to view their mission – they’re a
- Technology-led
- Cost center
- Managing Projects and Resources to
- Deliver Features
- Incentivized for an
- Efficiency-driven
- Binary feature delivery model (ship=1=good)
While the Product Organization seeks to be is teams of
- Vision- and business-strategy-led
- Value producers
- Leading Products and People to
- Deliver Business Outcomes
- Incentivized for an
- Effectiveness-focused
- Empirically data-driven,
- Problem solving model (customer behavior change+positive business value impact=good)
Asking a New Question first
So Agile hasn’t really let us down, so much as been the wrong question to ask the entire time.
Before putting pressure on Agile to optimize delivery at the team level, companies should focus on an enterprise-wide client experience product focus, which will open the door to a strategic product emphasis on delivering more rewarding user experiences as well as better business results.
The Unifying Power of Product
A truly empowered Product Organization can take a unifying vision and strategy, break that down into data-driven leading indicators of client behavior and discover how best to drive them across the business with self-organizing product teams. With a data-driven focus on the right metrics, the most inspiring vision and insightful business strategy can get transformed into motivated teams building the right things.
When teams are finally empowered to focus on solving the few, highest-priority product-driven client experiences that drive business outcomes, rather than the many disjointed feature requests, there will always be enough development cycles.
“Negative – South Melbourne, Victoria, circa 1934” by Kerr Bros Studio is licensed under CC PDM 1.0
Defensive Design and Critical Transitions
Posted on February 27, 2016
In much the same way that special teams can quickly improve a football team, defensive design can make a big difference by taking control of decisive, transitional moments.
I’ve heard it said that to have a better overall listening experience in your home stereo, it’s important to focus & spend your money in those areas where the signal transitions from one format to another (music storage system >> electronics >> sound waves)
- Turntable
- Speakers
- Headphones
By the same token, I think you can do much to improve a mobile app or web experience by focusing on those critical moments when things go wrong.
Offensive Design Choice – the Heavy-Handed Onboarding Flow
Frequently, you’ll see coach marks or a tutorial as first-time users try to start using an app. The idea is certainly logical, but these approaches tend to get in the way of the user’s intent. They just want to get started using the app, poking around, and accomplishing their goal. If you need to put a whole tutorial on how to use your app, chances are, your app will not be used that much.
The Defensive Design Prescription – Prepare the User’s Experience with Care
In the same way that most reviews are written based on negative experiences, get ahead of your users with defensive design and put a plan in place to step up in the decisive moments.
- Onboarding – How simple can you make it? Can you resist the marketing team’s desire to capture more analytics?
- Registration – Can you use social login? Make clear that this is separate by sharing to the service
- Calls to Action – Don’t keep the user guessing about how to accomplish their goals on any given screen, or at every interaction fork in the road. Make it unambiguous.
Spend the lion’s share of your time thinking through user goals and intent. Create cushions through established patterns and quick safety release valves. Allow the user to recover easily and quickly.
In that way, you’re taking care of what you need to make things right up front, instead of having to try to fix things that are broken for the rest of the experience.
Mobile Strategy Interview on the Myndset Blog
Posted on January 10, 2014
Here’s one from the archive – my old friend Minter Dial, former global head of Redken, former executive at L’Oreal, current globe-trotting consultant on digital strategy, did an interview with me towards the beginning of my tenure at Usablenet.
Read More
App or Mobile Web?
Posted on September 24, 2013 Leave a Comment
Granted, my perception right now has a great deal to do with working at one of the premier mobile web companies in the space, but for me, it’s no contest – I think that mobile web is where companies should be investing their money.
Not every phone will have or can even download your app, but every phone has a browser.
Read More
