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.

Leadership Learning

Here is a list in no particular order of some sources of knowledge I have found inspiring lately, definitely worth a read if you manage people.

Elastic Leadership amazon

This book really helped me to fill in my thinking around why when you aim to make teams autonomous sometimes you end up falling back to a more command and control style structure, and how to get back to autonomous self-learning teams.

Drive amazon

A must-read if you're interested in what motivates people, which is often contrary to the way we operate by default.

Start with why amazon

A great look at leadership and how to inspire people. 

Leaders eat last amazon

A follow up to start with why, I love reading these books as they really draw a great picture of what a leader should be and how they should act.

Back to human amazon

Back to human is a great look at how to build a connected and engaged workforce, how to be an effective leader, and more.

No Rules Rules amazon

A great look into the thinking behind how Netflix inspires innovation through autonomy and trust, I really liked their thinking around increasing performance through talent density, basically having the most performance from the least amount of people, I can see how this will reduce work through reduced communication channels.

Spotify engineering culture youtube

A great couple of videos about how Spotify encourages innovation and learning, so many great concepts, and a fun look inside a really interesting company.

Asynchronous development for hybrid remote dev teams website

A really interesting look at how remote engineering teams can work, although not really leadership related understanding how to set up a great remote working environment is only likely to become more important in a post-pandemic world where most engineers and companies have now seen how productive remote working can be, and that was when done in a panic, how much could we get out of remote working when we really take the time to optimize it.

TDD: design later

TDD is freaking awesome!



Seriously though, for most projects, TDD is a great place to start!

Let's go on a TDD journey and see how it affects the design of a project!



So I'm working on a project, I have a reasonable idea of how I'm going to design the project and break up the abstractions. First I choose a central set of entities and begin writing tests for them.

Through doing TDD I guarantee that the project is easily testable, because I have to write tests if I choose the wrong part to test or way to test it my life is going to be painful, so I would quickly reevaluate making the wrong decisions because I'm not having TDD fun I'm having TDD pain. TDD will quickly tell you if you're doing it wrong by being extremely painful to write the tests.

As we go forward I follow my design and TDD enforces the testability of the design, and allows me to quickly refactor the design if I have miscalculated anything! Woohoo!



Another time, I'm building a new project, I have no clue about how to design it. I'm not really sure how it will interact with other systems. What the API should be and really where the abstractions lie internally.

This time I just choose what seems a reasonable place to wrap the logic and begin writing tests, I write the hackiest ugliest code in a single file to satisfy the tests and focus on the quality of the tests, not the actual code. After working on the project for some time it's really going to start creaking, there are tonnes of conditional nested logic and edge cases are starting to become quite painful. But at some point, it becomes quite easy to sit down and come up with a design that actually satisfies the project.

With design in hand, I can sit down bin off the file that I was using for the main code and leverage the tests to confirm that the new design works! GLORY!


Don't agree? Leave a comment!