3 months ago I shared a few initial thoughts around standups and daily engineering activities and my thoughts have moved back to this exercise as we’ve continued to progress with our prototype and locking in on something that people really want.
And as I mentioned (and as many of you know) there are many different ways to go about doing a morning standup and the most important thing is that the team has a consistent time to discuss the project and the work that’s being done and that ultimately encourages dialogue and conversation to occur.
If those things are in place then you have the very fundamentals in place and it has all the opportunity to be a useful and beneficial block of time during the day.
Unfortunately, many of us know and have experienced a standup that is less than useful and that begs for improvement. This goes beyond the typical scrum framework of answering the three questions:
- What did you do yesterday?
- What are you going to do today?
- What impediments (“blockers”) have you encountered?
The nuances of running an effective standup are largely understood by the many, many ways in which a standup can run poorly. For instance, a poor standup might exhibit some of the following characteristics:
- Way too much detail. People spend all the time talking about the minutae of a problem.
- People are late. Basic logistics of people arriving on time!
- People are no prepared and then feel the pressure to share something unnecessary. A lot of social pressure is experienced which is not helpful.
- People are over-prepared and use it as a “show and tell” spot.
- People fight over / argue over finer details and attempt to problem-solve right then and there. Or people use it as a planning session which isn’t what a standup is for.
- Observers don’t act like observers and interject unhealthy / derailing comments.
- An over-reliance on an application or tool. Using Pivotal Tracker and walking through stories is not what a standup is for.
- People are trying to take detailed notes. Not the right time or place.
- Team Lead or Scrum Master or some other authority uses it to micromanage.
- The actual meeting is off-campus or not close to where the real work is done thus wasting a ton of time traveling from spot to spot.
- And the list goes on and on and on…
Ultimately, there isn’t a clear language, or dictionary, or method that is agreed upon by all that keeps the team’s standup on track and highly actionable.
There is definitely an “art” to this but everyone distinctly knows the feeling of an unfortunate or wasteful standup and leaves the event feeling worse than when they first started! Not exactly the most motivating ways to start a work day!
A Better Technical Standup
But what if there was a better way of doing this? What if there was a shared vocabulary or canonical source that allowed the team to get to the ground level of what’s really going on and move toward action through data-driven insights?
And, would there be a way to automate this so that zero additional work would be required? That’s something that I’ve been wrestling with over the last few weeks and I need a bit of your help.
The concept that we’ve put together (and this screenshot is old) is a jump-off point but for starters I want to learn about how you and your team do your standup and what would make it infinitely better.
So, can we have a chat about that? Email me and I’d love to hear about the following (and if you want to chat over the phone I’m down for that too)!:
- What does your standup look like today? As much detail as possible.
- What would make your standup amazing? What would you change (if you could)?
That’s it. I’d even be open to being an observer in one of your actual standups if you’d have me.
Let’s make standups useful again so that we can build software better.
Also published on Medium.