Lorem ipsum dolor sit amet, consectetur adipiscing elit lobortis arcu enim urna adipiscing praesent velit viverra sit semper lorem eu cursus vel hendrerit elementum morbi curabitur etiam nibh justo, lorem aliquet donec sed sit mi dignissim at ante massa mattis.
Vitae congue eu consequat ac felis placerat vestibulum lectus mauris ultrices cursus sit amet dictum sit amet justo donec enim diam porttitor lacus luctus accumsan tortor posuere praesent tristique magna sit amet purus gravida quis blandit turpis.
At risus viverra adipiscing at in tellus integer feugiat nisl pretium fusce id velit ut tortor sagittis orci a scelerisque purus semper eget at lectus urna duis convallis. Porta nibh venenatis cras sed felis eget neque laoreet suspendisse interdum consectetur libero id faucibus nisl donec pretium vulputate sapien nec sagittis aliquam nunc lobortis mattis aliquam faucibus purus in.
Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque. Velit euismod in pellentesque massa placerat volutpat lacus laoreet non curabitur gravida odio aenean sed adipiscing diam donec adipiscing tristique risus. amet est placerat in egestas erat imperdiet sed euismod nisi.
“Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque velit euismod in pellentesque massa placerat”
Eget lorem dolor sed viverra ipsum nunc aliquet bibendum felis donec et odio pellentesque diam volutpat commodo sed egestas aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod eu tincidunt tortor aliquam nulla facilisi aenean sed adipiscing diam donec adipiscing ut lectus arcu bibendum at varius vel pharetra nibh venenatis cras sed felis eget.
Most developers and software delivery teams use stand-ups as their daily team update meetings. Stand-ups are a great way to align everyone on the team and ensure overall progress is being made. The problem comes in when stand-ups stop being about progress updates and identifying blockers, but rather turn into members rambling on for too long or providing unnecessary information.
In this issue we are going to break down how to give an amazing stand-up update and how to avoid wasting valuable time.
Let's dive in.
It's simple. Take 2 minutes before stand-up to just remind yourself of what you worked on the previous days.
Our minds aren't always turned on first thing in the morning and there is nothing more embarrassing than it being your turn in stand-up to provide your update and not having a clue of what you actually did the day before. Beyond the embarrassment, this would also not invoke a sense of confidence in your abilities and focus to the rest of your team members.
Use the 2 minutes prior to the meeting to take note of 3 things:
Now when it's your turn to speak, all you have to do is run through those 3 things and your job is done. You've given a great update. You've mentioned what you worked on, any issues you may have and what your plan is for the day.
Nothing more. Nothing less.
Preparing prior to stand-up also helps keep you focused.
How often have you seen someone take a second to remember what they worked on the day before and then suddenly start to ramble and provide too much information? This is because their brain is suddenly flooding with all of the thoughts, complications and solutions of the day before, which they are now trying to express into a single update.
Don't do this.
If you find yourself diving into how you solved certain problems or why certain issues are blocking you, you've gone too far. Save that information for a private conversation with the direct people that need that information. For example, if you are blocked because you haven't gotten access permissions to a particular service, don't spend 2 minutes breaking down how you figured out it was an access issue, how John Doe is the only person who can give you access and then asking John for access during stand-up. That blocker doesn't relate to everybody else and neither does the solution. Tell the team you had an access issue but you're getting it resolved. That's all. Then just message John privately and ask for access.
A trick to help keep you focused is to ask yourself: if I was another person on this team, would I care about what was being said right now?
If the answer is no, then you most likely don't need to mention it.
Preparation will help you give a focused update.
If you hopped on to a call to help another team member with one of their problems, mention that in stand-up. It shows you're a team player and it shows that you're knowledgeable and valuable to the team.
I see a lot of developers neglect to mention things like this and then wonder why their managers don't understand how much value they bring to the team. Remember: perception matters.
If in every stand-up, you're mentioning that you helped person X on with their problem and you helped person Y with theirs, you'll build up a good reputation and your perception value will increase. This will make it far easier to ask for a raise or a promotion, because everyone on the team, including your manager, has witnessed the value you provide every single day.
Word of warning: don't over-lean into this. What I mean by that is don't start mentioning "Oh, I sent an email to this person. I sent a message to this person about their problem. I had a call with this person about their specific issue". If you're doing that then you've swung too far and it can become annoying as well as being a time waster for everyone.
The best developers just casually mention their time helping the team.
It's tough for developers to avoid the rabbit hole, as we are natural problem solvers.
The stand-up rabbit hole is when 2 or more people start diving into a problem or solution in the middle of stand-up. It's great seeing minds work and come together to make something great, but stand-up is not the place or time for that.
Save those ideas and energy for a separate meeting or for the end of stand-up.
If you notice a rabbit hole forming, just mention to the team to table that for the end of the meeting. After everyone has given their update, you can offer that those who are interested in exploring that specific scenario further can stay on the call.
This works great because if it's, for example, a development related issue then it's unfair and a time waster for testers and business analysts to be held hostage while the developers explore the problem. They can stay if they want to, but you're giving them the choice to spend their time in that manner.
Always allow everyone to give their updates before drilling down further into anything specific.
Some people may disagree with this, but I stand by it.
Stand-ups should only relate to that specific project, the team and their daily work. That's how I see it.
Some teams like to use stand-up as a town hall meeting of sorts to give updates about the company, social events, good news or bad news. I believe those things can be a message, an email or a separate meeting. By doing this, you're compartmentalising different aspects of work and honouring what stand-up should be.
You wouldn't chat about retrospective action points from last sprint in your current sprint refinement meeting so don't chat about anything in stand-up that shouldn't be there.
Again - you'll either agree or disagree with me here. Do what works best for you and your team, but I always prefer to honour everyone's time and keep things as focused as possible to ensure productivity, effectiveness and enjoyment stays high.
If any of these tips are new to you, please implement them in your next stand-up and let me know if you feel it's helping you come across as more informed and more focused.
See you again next week.