I joined a team that doesn’t do stand-ups (SEND HELP!)

You join a team that doesn’t do stand-ups, after your initial panic what do you do? Just book the daily in? You can’t do that! You’re a leader that values your teams opinions and works to understand them, after all it’s their team as much as it is yours.

How about listing what you’re missing and see what they can do to fix that? If they fail you can justify your sorely missed daily!

Requirements List:

• You need to understand the state of the team, how tickets are progressing and how far along they are
• Knowing about blockers are a must, you need to unblock them!
• Understanding the plan for progressing the ticket is important too!

You try a daily slack reminder where people can write the old yesterday, today and blockers in, but you’ve been walking the board for years now and this feels like a step backwards!

Focus on the board seems to be important, so you propose:

• They keep tickets updated with comments on progress as they move forward
• When picking up a ticket for the first time a plan is added for the day
• At the start of each day add a plan for the day to the tickets you’re working on

This becomes very hit and miss until, you unlock the power of the WIP limit! By reducing the amount of work the team is processing at once updating the board becomes much less effort, also you can quickly digest the current state of the team!

This was me six months ago, now I can happily say I don’t miss the daily stand-up any more and asynchronous communication is a super power we should all be unlocking.

Reducing meeting pain

Our refinement sessions ran over every time without fail, we often repeated the same points and people weren’t always very engaged.

To fix this we set expectation that all tickets for the next session should be read and questions asked before the meeting. This wasn’t easy to get used to, but quickly the sessions shortened in length and everyone found that the meetings were much more valuable.

💡 If a meeting doesn’t have a pre-read & agenda then people come with different levels of understanding about the topic, and much time is spent making sure everyone understands what is being discussed. By the time you get to this point you may have lost the attention of the people who already understood.

I've tried to identify different types of meetings and suggest ideas to improve them.

Discussions

A discussion is an ad hoc focused meeting on a specific topic.

• Make sure there is a pre-read and an agenda!
• Choose just the right amount of people to get the problem solved, don’t spam invite, talk to people before hand and see if their attendance makes sense
• Encourage people to comment and ask questions on the pre-read

Regular meeting

Normally these meetings have a regular cadence, and discuss topics that affect a group of people in a similar role or domain.

• Have an agenda with the different topics
• Make the meeting optional, so people can join to discuss the topics if they are interested
• Record the meeting per topic, this is high effort but great for sharing after
• Try to use a task board rather than a document for running meetings
• Focus on discussions, announcements can go in slack or document based communication

Status meetings

In these meetings often groups of people give updates on current progress, such as standups or project meetings. With stand-ups there has been a move from yesterday, today, blockers to walking the board, but the next step remotely seems to me to be everything should just be updated regularly.

• There should be somewhere, preferably automated where I can see the current state of a project/team quickly
• These meetings are often low value for the majority of people, high value for a few and get worse the bigger the group
• Try to automate status updates and have meetings for specific discussions

Information Streaming

Normally a big group of people with a small group of talkers

• Could we just record videos or write articles to replace these?
• Individual videos & articles are preferred as people can skip/skim the ones that aren’t relevant rather than forcing peoples attention

1:1s

• High value!
• Have an agenda!

Social Meetings

• Most important meetings in the calendar!
• Try not to mix with work, these meetings are pure social so we can keep work meetings short and people can have breaks in between meetings
• only meetings that should run to fill time, all other meetings we should be trying to reduce the amount of time, except maybe 1:1s?

Conclusion

The point here is not to have no meetings, but to make sure our meetings have the right amount of people for a reasonable amount of time. Freeing up more time can help give us more bandwidth for high value activities that come from the same bucket. 1:1s, pairing, etc. We can only really unlock the value from those if we don't ask people to use their energy on the others.

Call to action

Try out some tips, share your own! and we can all look forward to higher quality meetings!

Why I rush into things (with rockets!)

This is starhopper, starhopper flew 150 meters into the air on the 25th July 2019, SpaceX had wanted to fly it higher but the FAA limited the flight to 150 meters. When it landed it smashed into the concrete landing pad, if it had gone higher it probably would have blown up.

Starhopper was just about good enough to fly, it had a high chance of failure and SpaceX learned a lot from flying this early prototype.

This is SN24 and booster 7, which may be the first prototypes to reach orbit (hopefully in the next couple of months) as you can see a lot has changed!

In between these there have been many prototypes and many tests.

Apparently a green flame indicates engine rich exhaust, or your engine is burning up!

Through lots of iteration and testing often they have improved their next generation rocket a lot!

We generally build our software like this, but can we do everything like this? Don’t design things to be perfect, design them to learn and test them as soon as you can! Real world feedback is the only way to know for sure, and by showing people something early they suggest things that you wouldn’t have thought of!

Recently I've started running experiments to change meetings to be asynchronous, there's always the thought that it could have been organised better, or we should have tried something different. But the most important thing was we tried something, it was just about good enough, then we collected feedback. The feedback will get us to a great solution a lot faster than trying to answer questions ahead of time.

What is async working and why should you be learning from it

Long before covid hit there were fully remote companies, some forced to be that way through being spread around the globe. They had to solve problems like how a team works together if they never had a time of the day when they can all interact through a meeting. These companies use what's known as asynchronous ways of working the main challenge being you probably won't get a reply from anyone quickly.

The practices focus around documentation first communication and empowering employees to do their job without the need for quick responses.

If you were working for a non-remote company when covid hit the cost of arranging a meeting was hugely reduced, we used to have limits like the number of rooms or the number of seats in a room. Now we could book a meeting to solve every problem and we did. In lots of companies, this is having a big impact, huge reductions in focus time! Also, the expectation of quick slack responses means constant interruptions further reducing focus time.

By looking at async ways of working we can really start to take advantage of being remote, reduce meeting fatigue and increase productivity. Some of the advantages are:

• Empower employees and give them ownership
• Reduce the pain of employees in different timezones
• Increase focus time, often leading to higher productivity
• Stress-reducing, zoom fatigue is real
• Gives people time to think and research before answering
• Increases the quality of documentation (this has many benefits)

A great example of how to supercharge your workflow with async practices is to expect everyone to comment and ask questions on tickets before your refinement sessions. If you're like me you'll find that refinement zoom calls often overrun and aren't very engaging. By setting the expectation that everyone has read the ticket, understood the problem, and suggested approaches before the meeting these meetings will be supercharged!

Trying out a WIP limit

Work-in-progress limits are used to reduce the number of things that are actively being worked on by your team at once. The columns on our board that represent in progress are developing, reviewing, and deploying.

We could assign limits to the number of cards in each column, all in progress columns or per user. For our experiment, we chose to assign the WIP limit across all 3 columns. So for the first two days, we could only have 2 items across all columns. 

After activating this rule lots of things changed very quickly... 

Quality improvements

parts of our process that were not writing code increased in quality, we found that reviews had more people in them and were getting processed faster and with what felt like more detail in them. 

Our process includes people reading and commenting on tickets before our elaboration sessions, in order to have a base understanding and shorter meetings. Sometimes it can be difficult to make sure this is being followed, this quickly improved and there were many insightful questions on the upcoming tickets as well as extra tickets not scheduled for elaboration. 

Easier to understand what was happening 

As lead engineer i found it much easier to know what was going on, on the team. We dont have stand up meetings but follow some simple rules for ticket updates: comment an update on the ticket when picking it up, showing your plan for the day. 

• Comment an update each morning on tickets you own showing the plan to move it forward that day.
• Comment general updates on tickets so people know what is going on.
• Prefer talking on tickets over talking on slack, if you do talk on slack link in the ticket. 

This mixed with having less things on the board meant it was really easy to know the current state of the team with a glance at our board. It also made it a lot clearer what the bottlenecks in our process were, before we would not notice that a deployment of stored procedures took a long time, but after the change it became very painful and we had to address the problem. 

Increased collaboration

By having a limit that was less than the number of engineers on the team often people found themselves pairing on work more frequently in order to push tickets across the board. Collaboration is one of our teams values and our preferred way of working, the lower wip limits have really increased the amount of pairing going on!

Interesting points 

we had to be careful to split tickets so that we avoid enforced waits, as a blocked ticket would count against our wip limit. For example we might have to wait for a 3rd party to respond before we can continue working on a ticket. To get around this we would split the ticket around the wait so we have two tickets, one to send out information and one to process received updates. Sometimes even with a wip limit of 2 we still only had 1 ticket in play, im not 100% on what caused this but one thought is that once an engineer picks up an idle task such as doing some learning if a space then became available they wouldnt notice for a while. 

Conclusion 

looking at our cycle time and ticket velocity from just after the experiment started, it appears that our cycle time was reduced, we saw an initial spike in velocity as we completed all the tickets in progress and then returned to a similar velocity as we had before. 

This is quite interesting as based on initial data it seems that we didnt hugely increase the amount we deliver in a given period but we did reduce cycle time which would allow us to change direction faster if we need to process some incoming work quickly. As well as what appears to be a big increase in team focus and quality. So weve decided to adopt a wip limit into our team ways of working, the value we decided on for now is (engineers / 2) + 1.