Shaking Up Our Stand Ups
Change is inevitable. That would be my executive summary of the past three months. Rather than continually follow a plan, we need to be receptive to change and adapt accordingly. With life being uncertain it’s only logical that we need to be comfortable taking chances. Being comfortable with continuously improving the format of our Agile ceremonies to is imperative for team empowerment.
Mors certa, vita incerta
Philip K. Dick, Do Androids Dream of Electric Sheep?
So far this year I’ve lead two different projects with different goals. Yet both required a reboot of their stand-ups to improve collaboration. This week I discuss the emerging trends of stale stand-ups, and reflect on how our attempts to reinvigorate daily updates have affected team collaboration.
The majority of this audience should be familiar with that age old stand-up pattern. It is the mark of Agile evangelism that is permanently branded onto our minds. For those less knowledgeable each participant outlines three key points:
- What tasks they completed yesterday.
- Their proposed agenda for today.
- Any blockers that will prevent them fulfilling today’s goals.
Think of that scene in Live and Let Die where Solitaire predicts Mr Big’s fate using the Witches Tarot Deck. Yes, I know which deck it is as I own the same set. Colleagues on a stand-up call out the past and present activities along with future challenges in much the same way. Regardless of your beliefs in fortune telling, it is worth reflecting on how effective the readings are in any format.
Lazy Poker Blues
Part of our problem was the format had become far too predicable. The regular round robin routine meant developers switched off during stand-ups and simply waited for their turn. Their updates were succinct, yes, but key details such as blockers were often missed. Issues were often voiced after the call when the relevant SME was contacted for assistance. As a lead, tracking progress with these unknown blocker variables became impossible.
With our team being distributed, over-reliance on phone also inhibited updates. Team relationships are exceptionally challenging to nurture across regions. You don’t truly connect with someone until you look then square in the eyes. Spotting their tells of frustration or concern solely based on tone is difficult.
Indirectly, programmers focus on our stand-ups was far from stellar. While waiting after giving their update, I could see local engineers browsing on their phones. If their focus was on work, they would be burried in their email inboxes. This lack of attention is clearly disrespectful to your colleagues. From a team work perspective it was also leading to a communication disconnect. Gathering in rooms certainly did help improve things for a short time. Focus continued to waver.
The stand-up routine is considered sacrosanct by many. In these circles it’s destined never to change. I’m more experimental myself. My regular reading one morning a few months ago revealed a Eureka! moment with a story oriented stand-up approach. If stories are the key features of focus for delivery, why are individuals the centre of attention?
After discussion in our retrospective, we collectively agreed to give this new format a whirl for one sprint. The approach was to apply our favourite three elements to the stories instead.
Like any change it took time for individuals to adjust. There is a danger that you inadvertently lengthen your stand-ups if discipline is not enforced. This did happen initially. With effort, we managed to shift back to our average 10 minutes stand-up duration.
Developers reported several key benefits. Status of work, including blockers, became more transparent. Assistance was offered for blockers quickly, resulting in story subtasks moving across the board more rapidly. Nevertheless, the biggest result was the engagement between colleagues. Programmers were no longer distracted by other tasks. As my job is to keep my engineers happy and engaged, this was a massive result for me.
Play Your Cards Right
Further validation of this method came a few months later. Following an organisational restructure, this rock star team was split in two. The teams we were absorbed into were following the good ol’ standup routine.
After a couple of weeks, engineers who were part of the original experiment began raising concerns. They were seeing the same issues in their new daily stand-ups. They were recommending that the same approach be adopted in both projects. Since their proposals, other teams have embraced the new format. Feedback from these teams are finding the story first approach better facilitates collaboration. In my eyes this is a fantastic validation of the initial experiment.
In this game of chance, the developers have won over the house. The Agile space is filled with numerous different techniques that teams can use to solve problems, regardless of which methodology you use. Some consider it obscene to tinker with the key ceremonies. Shake off any reluctance and be comfortable taking a gamble.
Thanks for reading!