You Don't Know What You Don't Know
You Don't Know What You Don't Know
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
More or less since the start of my assignment at my current client, four years ago, we have had some form of a cross-team stand-up at 10:00 every day (often named Scrum-of-Scrums). But now that we have around 10 teams, we started to notice some issues lately. People joined too late or didn't even show up at all. And if they were there, some of them didn't share much or were clearly bored by the things people were sharing. Nothing is more painful than a few people standing in a circle, playing with their phones and picking their noses.
I found that pretty frustrating, especially since I really valued that stand-up. In my role as chief architect, I'm working mostly on technical projects and long-term architectural guidance. Only when teams have to complete architectural changes as part of bigger functional user stories, I get involved. So spending 10 minutes a day on hearing what people are doing is a great investment for me. The only other colleague who felt the same was our support and release manager with which I collaborate a lot, often on cross-team topics like these:
- Detecting dependencies between teams on both architectural level as well as on release level
- Detecting teams working on the same things or overlapping on certain aspects
- Detecting problems one team has that we know the other has already solved or is solving
- Detecting problems or challenges that we or somebody we know can solve
- Hearing about some story we need to review to see if it aligns with the architectural vision
- Pick opportunities to adapt or improve the development process
I had a hard time accepting that people wouldn't be as interested in this as me, so after consulting with our in-house agile coach, we decided to interview all Scrum Masters individually in the hopes of getting some usable feedback. In short, we asked them what kind of value they would like to get from that sync-up and what topics they would be interested in. Here's a summary of the topics people proposed.
- Reminders on writing a blog post (which we use internally for sharing technical and functional changes) or blog posts that require special attention by certain teams
- Reminders of upcoming deployments, unresolved support issues
- Sharing something a team is working on
- Upcoming code merges that they don’t realize might affect other teams
- Upcoming process or development environment changes
- General announcements, new hires, important client stuff
- Screw-up stories that you might mention for those that are interested
- Experiments and outcomes that were done in a team
- Successes and failures and what we learn from that
- Discuss upcoming large and/or complex stories
Are you're noticing this at well? Those are a lot of great things to discuss. So apparently nobody had any real objections on the contents after all. They just wanted all participants to be sharing something rather than standing there with sheepish eyes. The biggest annoyance was caused by people not showing up (ironically by those exact same people). But what really reinforced my believe in the standup was a remark that one of the quality engineers made. She said "You don't know what you don't know". And with that she nailed the very purpose of a daily stand-up.
With that renewed insight we decided to reboot the standup with a very clear agenda (which we’ve put on the wall at our regular standup location), a reminder of the startup time, and explicit 'rules' on who should be there and what to do if he or she couldn't be there. Now each team shortly shares:
- What problems worth mentioning happened yesterday
- What large and/or important stories/epics they will be working on today
- Which impediments exist they need help with
Next to that, we will always consider whether any of the following is worth mentioning
- Upcoming merges, releases
- Any blog posts or process changes worth emphasizing
- Any screw-up stories to mention
- Experiments and/or outcomes
- Any successes and failures we can learn from?
We're just four weeks further, but I think it's working very well, especially after we decided to tune down the frequency to three stand-ups per week. Everybody has plenty to share and many dependencies and conflicts were detected since then. But are we done? Of course not. I'm pretty sure this isn't the last time we talked about this.
So what do you do to regularly align teams? Let me know by commenting below or tweeting me at @ddoomen.
Published at DZone with permission of Dennis Doomen , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.