How to run stand-ups efficiently

Stand-ups are designed to be a short, fast and efficient meeting each morning to keep projects on track and to expose and provide visibility on blockers to the team, the SCRUM master and the product owner.

Although this sounds relatively straight forward, I've seen and been involved in too many stand-ups that get distracted when its not effectively managed by the SCRUM master. Below are some areas to focus on when running and trying to improve your daily stand-ups.


Each person talks about 3 things only

Each team member has the permission to talk about 3 things only. 
  • What they did yesterday
  • What they are doing today
  • Any blockers they are facing

They do not need to go into technical implementation details, or how they solved a really hard problem. Most people can communicate the 3 points above in less than 60 seconds. Each person needs to focus on communicating to the team the highlights and not the technical details. If this doesn't happen, the SCRUM master needs to intervene, make a note of the discussion subject and take it offline.

Start the stand-up at the same place and same time every morning

Consistency is so important when it comes to stand-ups. Find a time in the day that your entire team is available and a place that is close or next to the task board.
  • If needed, you can get the team to pick the time of the stand-up so that it encourages ownership from the team to make it to the stand-up on time each morning.

Make sure everyone stands up!

Enough said - it will make your stand-ups more efficient.

Communicate with the team, not the task board

Stand-ups are about communicating progress and blockers to the team, not to the SCRUM master and not to the task board.

SCRUM master to record blockers and ensure their resolution

When a person raises a blocker, or a problem, it needs to be recorded, mostly just by the SCRUM master so they can follow up to find out if they need any help resolving, and also more importantly, so that it doesn't get forgotten and that it gets resolved.

Take technical discussions offline

If any person in the team starts going into technical details (or starts talking about their weekend), they need to be stopped by the SCRUM master and told to take the conversation offline after the stand-up. The SCRUM master can take a quick note about the subject, and grab the relevant people after the stand-up to discuss in more detail.

Team members should know what they have to say before the stand-up

Team members shouldn't spend the first 60 seconds of their update trying to remember what they did yesterday, and what they are going to do today. Everyone should prepare before hand and if they need to, come to the meeting with a list of things to talk about.

A team size of 5-8 people is ideal - don't make it larger than 12 people

12 people in a standup is large, but if everyone can stick to 60 second updates you can get it done in the 15 minutes. Essentially you want to make sure that everyone who attends the standup is providing benefit to the other people in the stand-up. If their updates are not relevant or required, think about if they need to be involved in the stand-up. 

No phones or tablets at the stand-up

People participating in the stand-up should be focused and always paying attention - there is no need for people to be on their phone checking emails throughout stand-up.

Last team member to arrive starts first

This is a good practice to help get your team to arrive promptly to stand-ups. If they are the last person to arrive in the morning, they need to go first at the stand-up (as the entire team has had to wait for them). Don't start the stand-up until everyone is present.

Randomise the order of who speaks at the stand-up

You want to keep things interesting and everyone paying attention. Some days you can go left to right, other days right to left. You can even use a 'talking token', we've previously used a football and once you have finished your update you would throw it to the next person of your choosing. People often look for the person that wasn't paying attention to throw it to - it's a great way to keep everyone paying attention.

Use a heavy ball as the 'talking token' if required

An approach to stop people from talking too much and getting into too much detail is to use a heavy object (like a medicine ball) as the 'talking token'. People usually don't want to be holding it for too long so they will tend to be more efficient in their update. Don't make it so heavy that you cause your team back damage though.

Stand close together

Huddle together as a team, there is no need to have a metre of space between each person. The SCRUM master should ensure people don't have to yell to be heard.

The team should run the meeting (not the manager)

Stand-ups aren't about providing updates to the manager (although it is a useful way for managers to stay up to date), it is about the team communicating and providing visibility about user stories to the team. The SCRUM master is there to keep the stand-ups under control and on track.

Lastly, remember to have fun at your stand-ups!

What makes you a senior software engineer?

Are you a senior software engineer?

Software engineers are a sought after resource at the moment. You will sometimes see job adverts stating someone with 4 years+ experience can satisfy the requirements of a senior software engineer. But regardless of experience, what really makes someone a senior software engineer?

1. Accountability and ownership of their code

Ownership of a project is one of the biggest steps a senior software engineer makes. No longer are they a junior engineer that can rely on their coding issues being picked up by senior engineers, now they are the last line of defence for stable, secure applications that are delivered on-time. They are 100% responsible for ensuring that the their own code and their teams code is well tested, scalable and secure.

2. They can solve complex technical problems (any problem)

Senior software engineers have the expertise to look at any problem and find a solution (or undertake the required research to find a solution themselves). They sometimes work with their team members to find a solution, but they never come back to their team lead, or manager without a solution or variation of a solution. I believe this is one of the most distinguishable traits of a senior software engineer.

3. They develop reusable code

Senior software engineers understand that the code they develop may be used through the command line, from a controller in an MVC framework, or even from within a unit test. They develop their code to be used in any environment without duplication. This essentially means building loosely coupled code within the platforms they work in.

Service Orientated Architecture (SOA) is a really good methodology that promotes decoupling of code and reduces code duplication. Also have a read of coding to interfaces to help achieve code loosely coupled code.

4. They code for the future

Senior software engineers approach coding a solution to a problem by looking into how the component they are developing may need to be used in the future or extended in the future. They write their code so it is easily extensible and doesn't require a full re-write to add additional functionality at a later date. This is easier said than done, but after working on a variety of platforms, your past experiences in software development really help you excel in this area.

5. They unit test their code

Whether you have allocated time or not, a senior software engineer should and will unit test their code. They see the benefits of automated testing and will write unit tests to cover off at least the core libraries of their codebase.

Some helpful links on unit testing

6. They can estimate work effort and gather requirements

Work effort estimation is a skill that takes many years to master. It is one skill to be able to accurately estimate work effort for your own tasks, but being able to effectively estimate work effort for your team members is a really valuable skill. Although in Agile development environments the entire team is involved in work effort estimation, senior software engineers should be able to identify when work effort estimates are too low or too high and voice their concern to correct the situation.

7. They mentor junior developers

It is the responsibility of the senior engineer to always look for continuous improvement within the team. That can be exposing the team to more efficient technologies, helping them write more secure code or ensuring the code is well written and unit tested. This mentorship from senior engineers to other software engineers in the team really helps move the team towards greatness.

8. They have a solid understanding of programming methodologies (not just a language).

Senior software engineers have either studied or been exposed to different programming methodologies. It doesn't matter which language they are coding in, software methodologies cross over the boundary of coding languages. These best practices may enhance scalability of an e-commerce website, or provide secure APIs for mobile applications. It is important to understand that senior software engineers can take their learnings from multiple languages and frameworks and apply them to their current projects. They also find it very easy to learn new languages as they already understand the theory behind programming.

9. They're always looking for areas to automate

Senior software engineers are some of the most experienced technical people within a team. They should have a good understanding of how to automate aspects of their teams work. This can include:

  • Partial automation of code reviews (eg: using GIT hooks to run automated tests of coding standards using tools like PHPCS or JSLint).
  • Unit testing code to ensure its security and stability.
  • Implementing continuous integration and deployment services - Checkout Bamboo by Atlassian

10. Complies with and promotes coding standards

Senior software engineers understand the importance of consistency of code within applications. They are responsible for ensuring coding standards are defined within their team, and that everyone within the team is following them. They should also actively review peers code and coding standards to ensure they are up to date.

11. They can explain problems and solutions to non-technical people

A senior software engineer needs to be able to communicate to non-technical people. Although I have met some great senior engineers that maybe don't excel in people skills, they are still able to communicate through the use of diagrams, presentations or user stories. Communication is a crucial skill in progressing past a senior software engineer role to a team lead role.

12. They are always up to date with latest technology

This is actually a hard thing to consistently maintain as there is so much technology out there that is constantly evolving. However, it is crucial that a senior software engineer does their best to stay updated (at least with technologies in their space). You don't always get to experiment with different technologies within the workplace, but side projects you work on outside of work are an amazing opportunity to explore a new framework or technology. Senior software engineers also take this one step further and look for ways to implement their learnings within their current organisation, as well as up-skilling their team members on what they have learnt.

If you want to read and learn about how to become better a software engineer, check out this great post by Artur Ejsmont.

So if you can cover off most (or all) of the above, you've got a pretty impressive chance of landing that senior software engineer role you have been wanting to apply for.

Good Luck!