Using root cause analysis for people problems

Let's say James (a manager) pulls me aside for a talk.

"David, my teams just don't collaborate. They work by themselves and only talk together in their morning standups. Even their planning sessions and retrospectives are silent. Because of this, the team is duplicating their work. People find out they are working on the same code as their teammate. Instead of helping each other out, they wait for the other person to finish before starting their own task. I'd like to have a workshop on collaboration - that should fix things I think."

I've had a lot of these conversations and they can be difficult requests to navigate. When I was an engineer, I could look at a bug and trace the logs to create a story of what's breaking. I could use root cause analysis to find the underlying problem. Usually, it was a problem underneath a problem underneath a problem. The beginning is tiring, but as you get good at root cause analysis, it becomes quite enjoyable. It's a mental challenge to figure out quickly what all the different causes could be.

This is how I've treated my L&D conversations until now. If I'm talking to James about his problem, I would open with a couple of questions like:

• Why do you think this is happening?
• Have the team ever collaborated together?
• Has anything changed to worsen that collaboration?

Usually, the answer is something along the lines of "They have been under a lot of stress lately". In my tradition root-cause style, the next step is to figure out the cause of stress.

• Where is the stress coming from?
• Why did they overcommit in the first place?
• Is their project manager supporting their workload?

I've asked 100 probing questions to build a full picture, and he's exhausted.

And the problem is rarely unqiue. It's usually along the lines of overcommitting, scope creep, bad management or something similar.

So let's say we identified that James' team overcommitted and are stressed as a result. As a reuslt, the team have shut down communications and blame each other when work isn't done on time.

So what's next??

We can't undo the root cause of overcommitting, only prevent future occurrences. James is looking for an answer now, not in three months time.

No matter what the outcome of the above situation is, James probably hasn't come out of our conversation with high hopes. He's just spent the last 10 minutes tirelessly digging into the teams problems. I've asked 100 probing questions to build a full picture, and he's exhausted. What happens next time he has a problem? He will think back to this conversation and remember the pain of talking to me. He'll leave it for another day and potentially leave me out of his future issues altogether.

This is the challenge with using the root cause analysis as the only tool to diagnose people problems. It's annoying to be asked "And why do you think that happened" 10 times over to find the root cause. I've always found the 5 Why's to be an irritating exercise.

Other conversational types

We've established that a single conversational tool in our toolkit is not enough. What other types of conversational tools can bring more insights and value?

Appreciative Inquiry

Appreciative inquiry focused on what's working in an individual, team or organisation. Rather than using a problem-solving approach to conversations, it looks at the individual's or group's core strengths to identify improvements. Once the person identifies their strengths, they are encouraged to dream about a vision of the future.

• What does the perfect future look like?
• What could happen if we felt like this all the time?
• What else could we do if we allowed this to happen indefinitely?

Woody Zuill took this approach in his "Turn up the good" method of team improvement. At the end of each day, he gathered his team together to ask "What went well today?" and "How do we turn it up to 10 tomorrow?" For example, if the team enjoyed programming together as a team for the two hours today, they could ask themselves "How can we do more of that tomorrow?". They might decide to program together for 4 hours the next day to see how it goes. As the team build on their strengths, they bring a new kind of energy to the day. The team is no longer concerned with the most stressful problem on the table. Now they have something to get excited about!

The Appreciative Inquiry model looks like this:

• Discover: What are the things we do best?
• Dream: What would happen if we did more of this?
• Design: What's the outcome we'd like to see next?
• Deliver: What should we try?

In Woody's case, his team's daily retro probably looked something like this:

• Discover: What did we do really well today? (eg. Our 2 hour team programming session was great!)
• Dream: What could happen if we did more of this tomorrow? (eg. We might be tired, but we also might figure out that difficult ticket we've delayed)
• Design: What would we like to see as an outcome? (eg. We would like to see our most difficult ticket resolved)
• Deliver: What experiment will we try tomorrow? (eg. We will try team programming for 4 hours tomorrow)

The team analysed their strengths and picked an experiment for the following day.

Powerful questions

Powerful questions is a coaching technique used to engage the other person with open-ended questions. Instead of directing the conversation down a specific path, we can use powerful questions to take advantage of the other person's expertise.

Powerful questions generate curiosity, encourage reflection, invite creativity and generate energy. A constant focus on the problem becomes tiring and stressful. When we ask "Why did this happen?...and why did that happen?...and why??..." to get to the root cause, this can sound urgent and stressful. Furthermore, looking at the negative problem stifles creative solutions. Powerful questions bring some energy and excitement to the conversation while keeping it solution focused:

• What opportunities do you foresee for our team to expand our skill sets and take on new responsibilities in the future?
• I'm hearing you would score your team a 2/10 in collaboration. What would 10/10 look like to you?
• What are your team's strengths? How can we use those strengths to solve this issue?
• How can we reframe this problem as an opportunity for learning?

Coaching techniques

Coaching techniques capitalise on the other person's knowledge and strengths, facilitating them to solve their own problems. Instead of giving advice, the coach guides the conversation through questions, encouraging the other person to brainstorm and test their own ideas. There are various coaching techniques:

• Active listening: Get comfortable with the silence and repeat back to the other person your understanding of what they have said.
• Goal setting: Establish clear goals together using something like the SMART framework.
• Accountability: Help the other person stay accountable to actions by checking-in frequently. This encourages them to take ownership of their development.

When practiced, these tools transform the L&D practitioner into a skilled conversationalist. They come across as clear communicators and, most importantly, creative problem solvers. The difficult problems in any industry are people problems. Therefore, having a single tool (such as root cause analysis) to solve every problem is like using only a hammer to build a chair.

How to know you're not focusing

Do you ask yourself any of these questions?

• Where am I going in my job?
• Why do I feel demotivated even though I have the position I always wanted?
• How do I get rid of the feeling of being stuck?
• Why am I not motivated to improve anything?
• Why do I feel the need to try everything?

I've had some of these questions in the past. Sometimes, I've achieved exactly what I wanted and set out to do, but I still had the feeling I wasn't progressing. Some people say "I'd love to be the CEO of a company some day". But when I hear that, I hear "I'd love to achieve the title of CEO some day". And this tells me that they probably have no idea what being a CEO entails. Because achieving the title is arguably the easiest part of being a CEO. The real journey begins after that.

And this is what I admire about people in big positions. Think CEOs, presidents, politicians, sports people. They understand there is no final destination. Once they have accomplished something big, they know they have to wake up the next day and keep moving. This mindset is different to the mindset most of us have. We generally treat the goal as the final destination. The CEO treats their accomplishment as a milestone along a bigger journey. When we treat goals as final destinations, we can get caught asking ourselves the questions like "Ok I achieve my difficult goal...what's next?". The CEO needs to start leading the company. The graduate needs to start looking for a job. The PHD graduate needs to know what to do with their PHD. The Wimbledon champion needs to prepare for next years' competition.

Developing a Vision

Goals need to have a bigger picture that include ourselves and the people around us. When the CEO wakes up everyday to a new problem that could end the company, they need to be able to say "This is worth getting up for because...". When the PHD student is feeling burnt out in their 3rd year of consecutive study, they need to be able to say "I'm going through this pain because...". The same goes for any difficult task. You need to be able to say "This is worth it because...".

The "because" is our vision.

• What will solving this problem get you?
• What step of the journey will you be closer to after today?
• Why is the pain today / this week / this month / this year worth it?

The answer is unique to everyone and can include visions like family, career, health and finances.

Writing it down

For some reason, writing down our vision and integrating our current goals gives it more power. It is difficult to write down what we want for the future, because acknowledging what could be means acknowledging what might not happen. But doing so organises our messy thoughts. We might think we know what we want becuase we've said "I've thought about this a lot". But we haven't really thought about it unless it's written down. The future is too complicated to analyze in our heads. There are too many variables, conflicts and outcomes.

For example, I recently wrote down my vision of the future. After identifying the main goals and defining the steps to getting there, I realised two goals were in conflict. I saw that developing my new hobby required me to be away every Saturday for a few hours, conflicting with another goal to spend more time with my family. Until I wrote this down, I didn't see the conflict, even though it seems obvious in hindsight.

Steps to developing a vision

If you want to try this out, you can start developing a vision by answering the following questions:

• Where do you want to be in 5 years with your job?
• Describe what your ideal family life would be like. Include parents, siblings, children, partner...
• Combine everything and describe your ideal future:
  • Where do you want to be?
  • What do you want to do?
  • What kind of person do you want to be?
  • Why do you want these things?
  • What steps will you take towards these goals?
  • When will you start each step?

Finally, describe the kind of vision you don't want. As you right out a future you dislike, you will realise that it is not only possible, but likely to happen if you don't work towards your vision.

• If you failed to achieve the above, how would you feel?
• What does the future look like with none of the above goals achieved?
• Would failing to achieve your vision cause pain or anxiety on you or your loved ones?

While the previous exercises describe a vision to run towards, this will help you build a picture of the kind of future you want to run away from.

Get better results by focusing on what's working

In his book, Extreme Programming Explained, Kent Beck describes how Extreme Programming was conceived: "My goal in laying out the project style was to take everything I knew to be valuable about software engineering and turn the dials to 10." Woody Zuill, the author of Mob Programming, took this idea with one of his teams, running a short retro at the end of each day with his team. In their 15 minute retro, they asked themselves the question: "What went well today and how do we turn it up to 10 tomorrow?" After deciding what the team did well for the day and figuring out how to turn it up to 10, they came back the next day and tried their new practice. Over time, they developed a mob programming way of working which Woody now talks about all over the world.

We often forget to look at what we're doing well. We're too focused fixing problems. And once the problems are all fixed, we make up problems to fix. For example, software teams often have an excellent 'root cause' mindset. They look to problems in their team, quickly find the root cause and fix it. But many problems have complex root causes, particularly when it comes to interpersonal, team problems. Questions like "Why is our team engagement low?" or "Why is my team not motivated?" have multiple intricate root causes. These root causes require skilled practitioners to diagnose. Turning up the good avoids this way of thinking. Instead, it focuses on what is working, encouraging people to collaborate together to come up with a new idea.

Why is it important?

Focusing on the good has multiple benefits. Firstly, focusing on growth leads a team to being excellent at their jobs. When we pick something we do well and focus on improving it further, we leverage our strengths instead of minimizing our weaknesses. If I'm the keyboard player of a band, should I improve my keyboard skills or learn the drums? Given my value as a keyboard player, I argue it is better for me to learn new keyboard skills! This will give my band a better keyboard player instead of a bad drummer. My strengths as a keyboard player are what make me valuable.

Secondly, problems seem to fade away when we turn up the good. A team that does great code reviews could turn their reviews up to 10 and create smaller code commits. Over time, this leads to more frequent code reviews, reducing the number of bugs and reducing development cycles.

Thirdly, focusing on what you do well is energising. Many teams host retrospectives with dread. "Oh great - another set of problems we haven't fixed since the last retro". Teams that have a "Good | Bad | Improve" retro often skip over the "Good" section, assuming it's there as a tickbox exercise. But what if we removed the "Bad | Improve" sections and just focused on the "Good"? The team will focus only on what they have done well and celebrate their successes.

Turning up the good in our personal lives

Take a sheet of paper and write at the top of the page "Good things I do in my life". Your list might look something like this:

• Spending time with my family after work.
• Meeting up with my friends for coffee.
• Reading fantasy books.
• Playing music in my band.

For each idea, write how you could turn it up to 10.

• Spending time with my family after work: Dedicate 2 hours after work each day focused solely on my family without any screens.
• Meeting up with my friends for coffee: Schedule a coffee every two weeks with your friend to catch up.
• Reading fantasy books: Set aside 30 minutes before bed to read a book.
• Playing music in my band: Practice an extra 30 minutes each week before band practice.

This way of continuous improvement is motivating over time. It encourages focus, ensuring you don't spread yourself thin by taking on too many new tasks or hobbies. This is particularly helpful for someone like me who wants to do new things all the time. We can do new things all the time by turning up the good.

How to turn things up

When I started diving into this concept, I quickly realised that it's easy to see what my team and I do well. The difficult part is turning it up to 10. Here are some ideas on how to turn things up to 10.

Scale it up

Apply the practice to more people or more teams. For example, if there are people that work well together, get more people on the team to work with them.

Enhance the process

Refine the good thing to make it even better, incorporate new ideas and bring in more advanced technologies. For example, a team that are known for following company security guidelines could think of a way to automate some of their practices and share it with other teams.

Share the expertise

Expand the expertise across the team or the organisation. For example: An expert in java programming could pair with some of the other java programmers to show them their techniques and tools.

Set a higher standard

Raise the bar to further increase the team's output quality. For example, if a team have great code coverage, bring in some extra rules like Sonarqube to catch and suggest better coding practices.

Reward the good thing

Celebrate the good practices and behaviours of the team. For example, a person who steps up and helps another team mate in their time of need could be called out and recognised.

Increase the frequency

If the good thing occurs frequently, see if the team could increase its frequency. For example, if the team spend 15 minutes learning together in the morning, they could boost it up to 1 hour learning per day.

Measure success more often

If the team finds that recognising their good behaviour is useful, they could increase how often they evaluate their good behaviour. For example, a team that runs the 'turn up the good' exercise in their monthly retro could think about turning up the good on a weekly basis.

I've taken this workshop format from the videos on the HBS Case Method.

Use this template to facilitate an in-person or remote learning lab where the group explores a case study. I've run this with a group of 4-6 people, but larger groups are possible.

Details

• 45 minutes
• 4-10 people
• In-person
• Use powerpoint to display details
• Use whiteboard to brainstorm with the group

Agreements

• Treat each other with Kindness, Consideration and Respect.
• No phones.

Format

1. Present scenario
2. Split into pairs & explore case.
3. Brainstorm case together.
4. Split into larger groups to practice answering the question again
5. Practice answering the question individually.
6. Retro on what we've learned.

1. Present Scenario

• Show the slide with the scenario.
• Read it aloud.
• Invite questions + clarify.

Example Scenario: The Family Gathering

• You are at a family gathering when someone asks ‘What do you do?’.  
• “I work as a software engineer in the 5G space“, you reply.  
• “That’s sounds cool! What’s 5G?“ 

How do you respond?

2. Split into pairs & explore case

• Split the group into pairs.
• Ask them to explore the question for 5 minutes

3. Brainstorm the case together

• Bring everyone back into the bigger group again.
• Ask each pair what they came up with.
• Write their thoughts on the whiteboard.
• Step back and ask for their thoughts. Further clarify the case and explore different paths.
• Cross out and add thoughts on the whiteboard to explore the case and come up with better information together.

4. Split into larger groups to practice answering the question again

• It's time to re-explore the original case again.
• Split the group into 3-4 people and ask them to re-explore the question using the new information.

5. Practice answering the question individually

• The facilitator goes around the room and asks each person to answer the original case study question.
• Facilitator: "So David, you are the actor in this scenario. How would you answer the question 'What is 5G?'."
• Go around the room and explore the question with each person.

6. Retro

• Ask the group what they have learned today and how they will bring it into their daily conversations.
• Retro on the workshop itself and ask what their favourite part of the workshop was so that you can improve it for the next one.

Posting a Question on Hackernews

I posted a question to the hackernews community asking them "Ask HN: What's the best lecture series you've seen?". Here are the highlights. You can read the full list in the comments.

Results

Free Courses

• Andrej Karpathy: "Neural Networks: From Zero to Hero".
• Andrej Karpathy: "Let's build GPT: from scratch, in code, spelled out."
• Classical Physics by V. Balakrishnan from IIT Madras, India => First lecture => Whole Series
• Gilbert Strang: Linear Algebra
• Ken Joy: Computer Graphics
• Percy Liang and Dorsa Sadigh: Stanford CS221 Learn AI (2019)
• Micromouse 2021-2022 by UCLA
• Robert Sapolsky: Human Behavioral Biology
• Feynman: Physics
• Sussman & Abelson: SICP => Particularly Streams
• Timothy Snyder: The Making of Modern Ukraine
• MIT 16.885J Aircraft Systems Engineering, Fall 2005
• Jeremy Howard: Practical Deep Learning for Coders 2022
• Andy Pavlo: Intro to Database Systems
• Robert Morris: MIT 6.824 Distributed Systems
• Christof Paar: Introduction to Cryptography
• The Maths of General Relativity
• Walter Lewin: MIT Physics
• 3Blue1Brown: Linear Algebra
• Berkeley Psych 117: Drugs and Human Behavior

Paid Courses

• The Other Side of History: Daily life in the Ancient World

Remote vs. In-person debate

As lockdowns lifted, many companies have returned to in-person working with the belief that it is overall better for collaboration and delivering immediate value. This may or may not be true, or maybe it is true in some cases and not others, or maybe collaboration and immediate value should not be the only metrics to look at. Whatever the case may be, it strikes me as obvious that there are some serious disadvantages when working remotely. But the disadvantages do not affect everyone in the same way.

I think it comes down to the question "Do you know what you have to do?" In other words, is your task well-defined enough that you can do it by yourself? In many jobs, this is the case. Developing presentations, organising people to talk to each other, updating a client - these are all well-defined tasks.

But what about writing code for a project which we don't understand? Or analyzing a bug where, almost by definition, we don't know what's causing it? Or learning the basics of a new skill that other people take years to master? How can we be expected to do this by ourselves? The answer is: We can't. And if we can't do it by ourselves, that means we need others to help and support us. We get that help by communicating with them.

Lost moments of communication

• Overhearing an ad-hoc conversation between your two teammates.
• Seeing your teammate red-faced and stressed at their desk.
• Talking to someone in-person and noticing their foot shaking as if they are agitated.
• Signalling you want to interrupt someone's monologue to correct them.
• Turning around to your team and asking them for help (ie. Not needing to setup a meeting just to talk to a teammate).
• Hearing other people laugh at a joke.
• Hearing a happy story that someone encountered this morning.
• Seeing the magic of someone else writing great code.
• Having a conversation in a meeting while your colleagues have a separate conversation across the table.

These moments are not possible in a remote environment, and we make many trade-offs for the benefits of working remotely.

This template is inspired by a number of software coaches including Woody Zuill, Kevin Meadows and Llewellyn Falco.

Background

Many teams are called 'teams' by name only. From what I can see, this is because we often do not focus on building team-specific skills. In sports, we focus on growing and developing the team because it's obvious that's how games get won. But in the software industry, we seem to think that the rules are different. Time and time again, we see that only groups of people working together on the same problem at the same time can succeed in complex domains.

This workshop gives people a sense of what it means to be a real software team. It introduces the participants to the communication tools they need to solve problems together and learn together. For people who have not had experience programming as a team before, this is always good fun and people come out of the workshop excited to bring these techniques into their day-to-day work. And that's the facilitator's goal - help your participants have fun and give them something tangible to bring back to improve their work.

Facilitator's Prep

Pick an exercise

• For a completely beginner team, I recommend working in online environments to avoid wasting time on misconfigured laptops.
• Examples:
  • hackerrank.com
  • Cyber Dojo

Invite the participants

• Best results are with 4-6 people. Consider splitting up larger groups.
• Sessions should be 90-120 minutes.

During the Session

The Tech

• Screen sharing: Each participant needs to access and hand-off the code they are working on
  • Examples: MS teams
• Timer: Any timer will do.
  • Examples: Mob-programming timer app, Google timer

The Rules

• Any code you want to write must go through the hands of someone else.
• Build on whatever code was written before you - ie. No starting from the beginning.
• Treat everyone with kindness, consideration and respect.

The Terms

• Driver: The person at the keyboard. The driver doesn't think. They just do what they are told to do.
• Navigator: The person who talks to the driver. They are the only one who is allowed to tell the driver what to do.
• Mob: Everyone else. Their thoughts, ideas and suggestions are funneled to the navigator.
• Facilitator: The person who is coaching and involving the whole team. The facilitator does not take part in the problem solving. They should ensure the team is obeying all rules and ask open-ended questions such as "When was the last time we ran the code?".

The Session

1. Someone volunteers to be the first driver.
2. Someone else volunteers to be the first navigator.
3. The driver shares their screen.
4. Everyone reads the problem statement.
5. Start the timer for 5 minutes.
6. The navigator either directs the driver straight away or consults with the mob on what to do.
7. At the end of the 5 minutes, rotate the driver and navigator. The next driver can use the 'control screen' option on the first driver's computer.

Retro

• With 15 minutes until the finish, stop the session and run a retro.

Useful questions:

• What new and useful tools did we use?
• What new thing did you see when we were coding?
• What shortcuts did we see?
• What was fun?
• What did you most enjoy in this session? How can we bring that into your team?
• How did you feel and what caused you to feel it?

Pick an experiment to bring back

• Group similar topics from the retro.
• Talk with the team to select 1 thing and decide on an experiment to bring in over the next week.

Why use different retro questions?

Most teams have workshops called 'retros' where they reflect on the previous couple of weeks and decide what to improve going forward. For most teams, the retro is treated as another obligatory meeting dictated to them by the scrum rules. Teams that have no experience in effective retros see these workshops as a waste of time, and why wouldn't they? The teams that do have retros often have them too infrequently, taking a retro once every couple of weeks. As a result, teams find retros are 'too long' or inefficient because they try to do too much. Instead of taking retros more frequently, teams stop doing them or give up in putting in effort.

One sympton of inefficient retros is to run the workshop again and again in the same way and without any variety in the questions the team ask themselves to diagnose and introduce changes. After the team has asked themselves "What was good? / What was bad? / What should we improve?" a few times, everyone gets bored. Here is a list of questions to help your team find different and interesting experiments to run.

Day to day questions

Mini 15 minute retros everyday can help supercharge the team by bringing in tiny improvements each day. It also prevents those horrendous 3 hour long meetings at the end of a sprint where the saved up all their problems and ideas.

• What was good today? How can we turn it up? "Turn up the good" is a concept from Woody Zuill and Kevin Meadows' 'Mob-Programming' book. When working with teams, they asked themselves this question at the end of each day.

• What was the best thing about working together today? This is a good question to see how the team can do more good teamwork together.

• How many hours did each person spend working with someone else? What would happen if we increased this? A team is not a team if the people are not working together. Increasing the amount of time people pair and mob-program together could supercharge the team.

• How many hours did we spend blocked by someone else this week? How can we reduce this? Blockages and work in progress are huge areas of waste for teams. Identifying where major blockages are is extremely valuable to help teams do more of the fun stuff.

• What was our favourite tasks we did in the last 3 months? How can we do more of these tasks?

• What went really poorly today? How can we prevent it in the future?

Post mortem questions

In the event the team encounter a critical problem affecting customers, they will need to run a post-mortem on the event to diagnose and prevent future issues.

• What went wrong?
• What made you nervous?
• How can we prevent this happening again?
• Why did this incident happen?
• What else could go wrong that we got lucky with?
• What's the worst thing that could happen in this situation?

Worst case scenario analysis

What's the worst thing that could happen your team? It will likely happen at some point. Don't be the team that doesn't prepare for worst case scenarios because it is too uncomfortable to think about.

• What's the worst thing that could happen us? How to we mitigate that risk?
• If component X crashes in production, how can we get it back up?
• What's our bus factor for each responsibility and how do we increase bus factors of 1?
• What's the worst thing that we own that could happen and impact our customers?

Best case scenario analysis

Analysing a perfect day in the office can give insights into improvements. This is similar to 'turning up the good'.

• When do you love doing your work?
• What does the perfect day look like for you?

General improvements

• What's one thing you've always wanted to try?
• If we were to fix something permamnently tomorrow what would it be?
• What's something you learned about recently that you would like to introduce to the team?
• What tasks feel stale for the team?
• What's the thing you hate doing? How can we make it less painful?
• What's the thing you love doing? How can we do more of that?
• On a scale of 1-10, how good are we as a team?
• What's the lowest priority thing on our Todo list? What would it take to delete this task from our Todo list?
• Whats the main thing we do or support that we are known for?

Definitions are pretty pointless...aren't they?

I remember studying for a physics exam. While my maths skills were pretty good, I never properly learned the definitions of things and, as a result, didn't get good marks in my exams. At the time, I remember thinking "It's not like I'll ever need this...what's the point in learning it?" But learning definitions is not pointless - it's necessary. When you learn a definition, you shortcut what probably took 1000s of hours from different people to get to that definition. The definition of anuthing is likely a far better summary than you could ever come up with.

But here's the catch - just because you know the definition doesn't mean you know what you're talking about. I think this is where the novice falls down. Sure, you can learn off the definition and not be an expert. But...and here's the point...you can't be an expert without knowing the definition. Almthough I complained that I had to learn off physics definitions for my exams, my (excellent) physics teacher easily cited back multiple definitions in each class without looking at any notes. The expert uses definitions to avoid reinventing the wheel.

For example, if I try to explain the software principle of DRY (Don't repeat yourself) without using the principle itself, I end up with a load of gibberish as I try to find different words to describe DRY. Even worse, someone might say "David, you're talking about DRY right?" and will soon conclude that I don't even know the thing I'm describing. Therefore, it seems to me that knowing definitions are not only important, but are necessary. So here is my attempt at gathering and recording any useful definitions I come across to 'parrot' back to the people who are unfortunate enough to listen to me.

List of Software Definitions + Phrases

Note: This is update with anything new I come across.

• DRY: Don't repeat yourself; Used to reduce repition of software patterns.
• Scrum: Empirical framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
• Agile: A philosophy of iteration and continuous improvement when delivering software; Incremental deliveries
• Kanban: Helps visualise work, maximise efficiency + continuously improve.
• Servant leader: Someone who wants to serve first, lead second;
• Satisfy the customer through early and continuous delivery of valuable software: Agile principle; Requires early and constant customer feedback; More feedback correlates to happier customers correlates to happier workers; So always seek more feedback;
• Welcome changing requirements, even late in development: Agile principle; Requirement always change.

What are the rules of chess?

Chess rules are simple: Trap your oppenent's king before they trap yours. Of course, there are other rules like how pawns should capture other pieces or how a king should castle. I know these rules and I know them well. My go-to method of procratination is to play a game of chess on lichess.org.

So here's a question: If I know the rules of chess, why can't I beat an experienced chess player?

I know that bishops move diagonally and knights make that weird "L" shape. But if you put me against an experienced chess player, I don't stand a chance. The reason for this seems plainly obvious: Knowing the rules is not enough.

The same applied to all games. While knowing the rules is essential to play the game, they do not inform the tactics and strategies of the game. The rules don't tell me what the best chess openings are or what the best endgame is. They don't explain the traps that happen when I move the queen to this position or the knight to this. They don't tell me the consequences of my move in two, three or four moves time. Knowledge of the rules alone explains none of these things.

How does this apply to the business world?

So we've established: Knowing the rules does not qualify us as a master of the game. Then why not apply the same standard to the professional world?

A Python certificate does not a Python developer make.

A Scrum certificate does not a Scrum Master make.

A Six Sigma certificate does not a Project Manager make.

We should not place blind trust in CVs or certificates that simply say that a person is qualified in subject X.

What signals mastery?

How would we know someone is good at chess? We would play them against someone else who is also good at chess.

The same goes when hiring candidates or evaluating people's expertise. Their CV says have some certificates - great! At least it means they probably have an interest. But we must make sure they can play the game.

My favourite way to evaluate expertise is to talk to the person about problem scenarios in their field. In my opinion, this is how all interviews should be conducted (not multi-day take-home assignments or leetcode exercises). If it's a programming problem, let's talk through it together and come up with a solution on paper first and then write some code. If it's a leadership problem, let's discuss the assumptions, ideas and proposals to solve it.

That's how we check for expertise - we see if they can play the game.

How can I show I'm an expert in something?

At the risk of repeating myself: Show others you can play the game.

Show them that you don't just know the rules but can apply tactics and strategies to real world problems. Write about the times you've played the game. Tell them about the mistakes you've made and what you've learned. Build things to prove that you can build them.

Of course, all of this assumes one important thing: You must know what you're talking about.

While there are shortcuts to achieve expertise quicker (namely focus), nothing replaces putting in the hard work. That doesn't mean you need to spend 2 hours everyday for the next year learning how to play the game (but if you have the time why not!?). However, it does mean that you need to keep chipping away at it. A little bit here, a little bit there - it all adds up. But please, please, don't stop after just learning the rules.

The rules matter.

But playing the game matters most.

Using root cause analysis for people problems

Let's say James (a manager) pulls me aside for a talk.

"David, my teams just don't collaborate. They work by themselves and only talk together in their morning standups. Even their planning sessions and retrospectives are silent. Because of this, the team is duplicating their work. People find out they are working on the same code as their teammate. Instead of helping each other out, they wait for the other person to finish before starting their own task. I'd like to have a workshop on collaboration - that should fix things I think."

I've had a lot of these conversations and they can be difficult requests to navigate. When I was an engineer, I could look at a bug and trace the logs to create a story of what's breaking. I could use root cause analysis to find the underlying problem. Usually, it was a problem underneath a problem underneath a problem. The beginning is tiring, but as you get good at root cause analysis, it becomes quite enjoyable. It's a mental challenge to figure out quickly what all the different causes could be.

This is how I've treated my L&D conversations until now. If I'm talking to James about his problem, I would open with a couple of questions like:

• Why do you think this is happening?
• Have the team ever collaborated together?
• Has anything changed to worsen that collaboration?

Usually, the answer is something along the lines of "They have been under a lot of stress lately". In my tradition root-cause style, the next step is to figure out the cause of stress.

• Where is the stress coming from?
• Why did they overcommit in the first place?
• Is their project manager supporting their workload?

I've asked 100 probing questions to build a full picture, and he's exhausted.

And the problem is rarely unqiue. It's usually along the lines of overcommitting, scope creep, bad management or something similar.

So let's say we identified that James' team overcommitted and are stressed as a result. As a reuslt, the team have shut down communications and blame each other when work isn't done on time.

So what's next??

We can't undo the root cause of overcommitting, only prevent future occurrences. James is looking for an answer now, not in three months time.

No matter what the outcome of the above situation is, James probably hasn't come out of our conversation with high hopes. He's just spent the last 10 minutes tirelessly digging into the teams problems. I've asked 100 probing questions to build a full picture, and he's exhausted. What happens next time he has a problem? He will think back to this conversation and remember the pain of talking to me. He'll leave it for another day and potentially leave me out of his future issues altogether.

This is the challenge with using the root cause analysis as the only tool to diagnose people problems. It's annoying to be asked "And why do you think that happened" 10 times over to find the root cause. I've always found the 5 Why's to be an irritating exercise.

Other conversational types

We've established that a single conversational tool in our toolkit is not enough. What other types of conversational tools can bring more insights and value?

Appreciative Inquiry

Appreciative inquiry focused on what's working in an individual, team or organisation. Rather than using a problem-solving approach to conversations, it looks at the individual's or group's core strengths to identify improvements. Once the person identifies their strengths, they are encouraged to dream about a vision of the future.

• What does the perfect future look like?
• What could happen if we felt like this all the time?
• What else could we do if we allowed this to happen indefinitely?

Woody Zuill took this approach in his "Turn up the good" method of team improvement. At the end of each day, he gathered his team together to ask "What went well today?" and "How do we turn it up to 10 tomorrow?" For example, if the team enjoyed programming together as a team for the two hours today, they could ask themselves "How can we do more of that tomorrow?". They might decide to program together for 4 hours the next day to see how it goes. As the team build on their strengths, they bring a new kind of energy to the day. The team is no longer concerned with the most stressful problem on the table. Now they have something to get excited about!

The Appreciative Inquiry model looks like this:

• Discover: What are the things we do best?
• Dream: What would happen if we did more of this?
• Design: What's the outcome we'd like to see next?
• Deliver: What should we try?

In Woody's case, his team's daily retro probably looked something like this:

• Discover: What did we do really well today? (eg. Our 2 hour team programming session was great!)
• Dream: What could happen if we did more of this tomorrow? (eg. We might be tired, but we also might figure out that difficult ticket we've delayed)
• Design: What would we like to see as an outcome? (eg. We would like to see our most difficult ticket resolved)
• Deliver: What experiment will we try tomorrow? (eg. We will try team programming for 4 hours tomorrow)

The team analysed their strengths and picked an experiment for the following day.

Powerful questions

Powerful questions is a coaching technique used to engage the other person with open-ended questions. Instead of directing the conversation down a specific path, we can use powerful questions to take advantage of the other person's expertise.

Powerful questions generate curiosity, encourage reflection, invite creativity and generate energy. A constant focus on the problem becomes tiring and stressful. When we ask "Why did this happen?...and why did that happen?...and why??..." to get to the root cause, this can sound urgent and stressful. Furthermore, looking at the negative problem stifles creative solutions. Powerful questions bring some energy and excitement to the conversation while keeping it solution focused:

• What opportunities do you foresee for our team to expand our skill sets and take on new responsibilities in the future?
• I'm hearing you would score your team a 2/10 in collaboration. What would 10/10 look like to you?
• What are your team's strengths? How can we use those strengths to solve this issue?
• How can we reframe this problem as an opportunity for learning?

Coaching techniques

Coaching techniques capitalise on the other person's knowledge and strengths, facilitating them to solve their own problems. Instead of giving advice, the coach guides the conversation through questions, encouraging the other person to brainstorm and test their own ideas. There are various coaching techniques:

• Active listening: Get comfortable with the silence and repeat back to the other person your understanding of what they have said.
• Goal setting: Establish clear goals together using something like the SMART framework.
• Accountability: Help the other person stay accountable to actions by checking-in frequently. This encourages them to take ownership of their development.

When practiced, these tools transform the L&D practitioner into a skilled conversationalist. They come across as clear communicators and, most importantly, creative problem solvers. The difficult problems in any industry are people problems. Therefore, having a single tool (such as root cause analysis) to solve every problem is like using only a hammer to build a chair.

Get better results by focusing on what's working

In his book, Extreme Programming Explained, Kent Beck describes how Extreme Programming was conceived: "My goal in laying out the project style was to take everything I knew to be valuable about software engineering and turn the dials to 10." Woody Zuill, the author of Mob Programming, took this idea with one of his teams, running a short retro at the end of each day with his team. In their 15 minute retro, they asked themselves the question: "What went well today and how do we turn it up to 10 tomorrow?" After deciding what the team did well for the day and figuring out how to turn it up to 10, they came back the next day and tried their new practice. Over time, they developed a mob programming way of working which Woody now talks about all over the world.

We often forget to look at what we're doing well. We're too focused fixing problems. And once the problems are all fixed, we make up problems to fix. For example, software teams often have an excellent 'root cause' mindset. They look to problems in their team, quickly find the root cause and fix it. But many problems have complex root causes, particularly when it comes to interpersonal, team problems. Questions like "Why is our team engagement low?" or "Why is my team not motivated?" have multiple intricate root causes. These root causes require skilled practitioners to diagnose. Turning up the good avoids this way of thinking. Instead, it focuses on what is working, encouraging people to collaborate together to come up with a new idea.

Why is it important?

Focusing on the good has multiple benefits. Firstly, focusing on growth leads a team to being excellent at their jobs. When we pick something we do well and focus on improving it further, we leverage our strengths instead of minimizing our weaknesses. If I'm the keyboard player of a band, should I improve my keyboard skills or learn the drums? Given my value as a keyboard player, I argue it is better for me to learn new keyboard skills! This will give my band a better keyboard player instead of a bad drummer. My strengths as a keyboard player are what make me valuable.

Secondly, problems seem to fade away when we turn up the good. A team that does great code reviews could turn their reviews up to 10 and create smaller code commits. Over time, this leads to more frequent code reviews, reducing the number of bugs and reducing development cycles.

Thirdly, focusing on what you do well is energising. Many teams host retrospectives with dread. "Oh great - another set of problems we haven't fixed since the last retro". Teams that have a "Good | Bad | Improve" retro often skip over the "Good" section, assuming it's there as a tickbox exercise. But what if we removed the "Bad | Improve" sections and just focused on the "Good"? The team will focus only on what they have done well and celebrate their successes.

Turning up the good in our personal lives

Take a sheet of paper and write at the top of the page "Good things I do in my life". Your list might look something like this:

• Spending time with my family after work.
• Meeting up with my friends for coffee.
• Reading fantasy books.
• Playing music in my band.

For each idea, write how you could turn it up to 10.

• Spending time with my family after work: Dedicate 2 hours after work each day focused solely on my family without any screens.
• Meeting up with my friends for coffee: Schedule a coffee every two weeks with your friend to catch up.
• Reading fantasy books: Set aside 30 minutes before bed to read a book.
• Playing music in my band: Practice an extra 30 minutes each week before band practice.

This way of continuous improvement is motivating over time. It encourages focus, ensuring you don't spread yourself thin by taking on too many new tasks or hobbies. This is particularly helpful for someone like me who wants to do new things all the time. We can do new things all the time by turning up the good.

How to turn things up

When I started diving into this concept, I quickly realised that it's easy to see what my team and I do well. The difficult part is turning it up to 10. Here are some ideas on how to turn things up to 10.

Scale it up

Apply the practice to more people or more teams. For example, if there are people that work well together, get more people on the team to work with them.

Enhance the process

Refine the good thing to make it even better, incorporate new ideas and bring in more advanced technologies. For example, a team that are known for following company security guidelines could think of a way to automate some of their practices and share it with other teams.

Share the expertise

Expand the expertise across the team or the organisation. For example: An expert in java programming could pair with some of the other java programmers to show them their techniques and tools.

Set a higher standard

Raise the bar to further increase the team's output quality. For example, if a team have great code coverage, bring in some extra rules like Sonarqube to catch and suggest better coding practices.

Reward the good thing

Celebrate the good practices and behaviours of the team. For example, a person who steps up and helps another team mate in their time of need could be called out and recognised.

Increase the frequency

If the good thing occurs frequently, see if the team could increase its frequency. For example, if the team spend 15 minutes learning together in the morning, they could boost it up to 1 hour learning per day.

Measure success more often

If the team finds that recognising their good behaviour is useful, they could increase how often they evaluate their good behaviour. For example, a team that runs the 'turn up the good' exercise in their monthly retro could think about turning up the good on a weekly basis.

I've taken this workshop format from the videos on the HBS Case Method.

Use this template to facilitate an in-person or remote learning lab where the group explores a case study. I've run this with a group of 4-6 people, but larger groups are possible.

Details

• 45 minutes
• 4-10 people
• In-person
• Use powerpoint to display details
• Use whiteboard to brainstorm with the group

Agreements

• Treat each other with Kindness, Consideration and Respect.
• No phones.

Format

1. Present scenario
2. Split into pairs & explore case.
3. Brainstorm case together.
4. Split into larger groups to practice answering the question again
5. Practice answering the question individually.
6. Retro on what we've learned.

1. Present Scenario

• Show the slide with the scenario.
• Read it aloud.
• Invite questions + clarify.

Example Scenario: The Family Gathering

• You are at a family gathering when someone asks ‘What do you do?’.  
• “I work as a software engineer in the 5G space“, you reply.  
• “That’s sounds cool! What’s 5G?“ 

How do you respond?

2. Split into pairs & explore case

• Split the group into pairs.
• Ask them to explore the question for 5 minutes

3. Brainstorm the case together

• Bring everyone back into the bigger group again.
• Ask each pair what they came up with.
• Write their thoughts on the whiteboard.
• Step back and ask for their thoughts. Further clarify the case and explore different paths.
• Cross out and add thoughts on the whiteboard to explore the case and come up with better information together.

4. Split into larger groups to practice answering the question again

• It's time to re-explore the original case again.
• Split the group into 3-4 people and ask them to re-explore the question using the new information.

5. Practice answering the question individually

• The facilitator goes around the room and asks each person to answer the original case study question.
• Facilitator: "So David, you are the actor in this scenario. How would you answer the question 'What is 5G?'."
• Go around the room and explore the question with each person.

6. Retro

• Ask the group what they have learned today and how they will bring it into their daily conversations.
• Retro on the workshop itself and ask what their favourite part of the workshop was so that you can improve it for the next one.

Posting a Question on Hackernews

I posted a question to the hackernews community asking them "Ask HN: What's the best lecture series you've seen?". Here are the highlights. You can read the full list in the comments.

Results

Free Courses

• Andrej Karpathy: "Neural Networks: From Zero to Hero".
• Andrej Karpathy: "Let's build GPT: from scratch, in code, spelled out."
• Classical Physics by V. Balakrishnan from IIT Madras, India => First lecture => Whole Series
• Gilbert Strang: Linear Algebra
• Ken Joy: Computer Graphics
• Percy Liang and Dorsa Sadigh: Stanford CS221 Learn AI (2019)
• Micromouse 2021-2022 by UCLA
• Robert Sapolsky: Human Behavioral Biology
• Feynman: Physics
• Sussman & Abelson: SICP => Particularly Streams
• Timothy Snyder: The Making of Modern Ukraine
• MIT 16.885J Aircraft Systems Engineering, Fall 2005
• Jeremy Howard: Practical Deep Learning for Coders 2022
• Andy Pavlo: Intro to Database Systems
• Robert Morris: MIT 6.824 Distributed Systems
• Christof Paar: Introduction to Cryptography
• The Maths of General Relativity
• Walter Lewin: MIT Physics
• 3Blue1Brown: Linear Algebra
• Berkeley Psych 117: Drugs and Human Behavior

Paid Courses

• The Other Side of History: Daily life in the Ancient World

Remote vs. In-person debate

As lockdowns lifted, many companies have returned to in-person working with the belief that it is overall better for collaboration and delivering immediate value. This may or may not be true, or maybe it is true in some cases and not others, or maybe collaboration and immediate value should not be the only metrics to look at. Whatever the case may be, it strikes me as obvious that there are some serious disadvantages when working remotely. But the disadvantages do not affect everyone in the same way.

I think it comes down to the question "Do you know what you have to do?" In other words, is your task well-defined enough that you can do it by yourself? In many jobs, this is the case. Developing presentations, organising people to talk to each other, updating a client - these are all well-defined tasks.

But what about writing code for a project which we don't understand? Or analyzing a bug where, almost by definition, we don't know what's causing it? Or learning the basics of a new skill that other people take years to master? How can we be expected to do this by ourselves? The answer is: We can't. And if we can't do it by ourselves, that means we need others to help and support us. We get that help by communicating with them.

Lost moments of communication

• Overhearing an ad-hoc conversation between your two teammates.
• Seeing your teammate red-faced and stressed at their desk.
• Talking to someone in-person and noticing their foot shaking as if they are agitated.
• Signalling you want to interrupt someone's monologue to correct them.
• Turning around to your team and asking them for help (ie. Not needing to setup a meeting just to talk to a teammate).
• Hearing other people laugh at a joke.
• Hearing a happy story that someone encountered this morning.
• Seeing the magic of someone else writing great code.
• Having a conversation in a meeting while your colleagues have a separate conversation across the table.

These moments are not possible in a remote environment, and we make many trade-offs for the benefits of working remotely.

This template is inspired by a number of software coaches including Woody Zuill, Kevin Meadows and Llewellyn Falco.

Background

Many teams are called 'teams' by name only. From what I can see, this is because we often do not focus on building team-specific skills. In sports, we focus on growing and developing the team because it's obvious that's how games get won. But in the software industry, we seem to think that the rules are different. Time and time again, we see that only groups of people working together on the same problem at the same time can succeed in complex domains.

This workshop gives people a sense of what it means to be a real software team. It introduces the participants to the communication tools they need to solve problems together and learn together. For people who have not had experience programming as a team before, this is always good fun and people come out of the workshop excited to bring these techniques into their day-to-day work. And that's the facilitator's goal - help your participants have fun and give them something tangible to bring back to improve their work.

Facilitator's Prep

Pick an exercise

• For a completely beginner team, I recommend working in online environments to avoid wasting time on misconfigured laptops.
• Examples:
  • hackerrank.com
  • Cyber Dojo

Invite the participants

• Best results are with 4-6 people. Consider splitting up larger groups.
• Sessions should be 90-120 minutes.

During the Session

The Tech

• Screen sharing: Each participant needs to access and hand-off the code they are working on
  • Examples: MS teams
• Timer: Any timer will do.
  • Examples: Mob-programming timer app, Google timer

The Rules

• Any code you want to write must go through the hands of someone else.
• Build on whatever code was written before you - ie. No starting from the beginning.
• Treat everyone with kindness, consideration and respect.

The Terms

• Driver: The person at the keyboard. The driver doesn't think. They just do what they are told to do.
• Navigator: The person who talks to the driver. They are the only one who is allowed to tell the driver what to do.
• Mob: Everyone else. Their thoughts, ideas and suggestions are funneled to the navigator.
• Facilitator: The person who is coaching and involving the whole team. The facilitator does not take part in the problem solving. They should ensure the team is obeying all rules and ask open-ended questions such as "When was the last time we ran the code?".

The Session

1. Someone volunteers to be the first driver.
2. Someone else volunteers to be the first navigator.
3. The driver shares their screen.
4. Everyone reads the problem statement.
5. Start the timer for 5 minutes.
6. The navigator either directs the driver straight away or consults with the mob on what to do.
7. At the end of the 5 minutes, rotate the driver and navigator. The next driver can use the 'control screen' option on the first driver's computer.

Retro

• With 15 minutes until the finish, stop the session and run a retro.

Useful questions:

• What new and useful tools did we use?
• What new thing did you see when we were coding?
• What shortcuts did we see?
• What was fun?
• What did you most enjoy in this session? How can we bring that into your team?
• How did you feel and what caused you to feel it?

Pick an experiment to bring back

• Group similar topics from the retro.
• Talk with the team to select 1 thing and decide on an experiment to bring in over the next week.

Definitions are pretty pointless...aren't they?

I remember studying for a physics exam. While my maths skills were pretty good, I never properly learned the definitions of things and, as a result, didn't get good marks in my exams. At the time, I remember thinking "It's not like I'll ever need this...what's the point in learning it?" But learning definitions is not pointless - it's necessary. When you learn a definition, you shortcut what probably took 1000s of hours from different people to get to that definition. The definition of anuthing is likely a far better summary than you could ever come up with.

But here's the catch - just because you know the definition doesn't mean you know what you're talking about. I think this is where the novice falls down. Sure, you can learn off the definition and not be an expert. But...and here's the point...you can't be an expert without knowing the definition. Almthough I complained that I had to learn off physics definitions for my exams, my (excellent) physics teacher easily cited back multiple definitions in each class without looking at any notes. The expert uses definitions to avoid reinventing the wheel.

For example, if I try to explain the software principle of DRY (Don't repeat yourself) without using the principle itself, I end up with a load of gibberish as I try to find different words to describe DRY. Even worse, someone might say "David, you're talking about DRY right?" and will soon conclude that I don't even know the thing I'm describing. Therefore, it seems to me that knowing definitions are not only important, but are necessary. So here is my attempt at gathering and recording any useful definitions I come across to 'parrot' back to the people who are unfortunate enough to listen to me.

List of Software Definitions + Phrases

Note: This is update with anything new I come across.

• DRY: Don't repeat yourself; Used to reduce repition of software patterns.
• Scrum: Empirical framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
• Agile: A philosophy of iteration and continuous improvement when delivering software; Incremental deliveries
• Kanban: Helps visualise work, maximise efficiency + continuously improve.
• Servant leader: Someone who wants to serve first, lead second;
• Satisfy the customer through early and continuous delivery of valuable software: Agile principle; Requires early and constant customer feedback; More feedback correlates to happier customers correlates to happier workers; So always seek more feedback;
• Welcome changing requirements, even late in development: Agile principle; Requirement always change.

What are the rules of chess?

Chess rules are simple: Trap your oppenent's king before they trap yours. Of course, there are other rules like how pawns should capture other pieces or how a king should castle. I know these rules and I know them well. My go-to method of procratination is to play a game of chess on lichess.org.

So here's a question: If I know the rules of chess, why can't I beat an experienced chess player?

I know that bishops move diagonally and knights make that weird "L" shape. But if you put me against an experienced chess player, I don't stand a chance. The reason for this seems plainly obvious: Knowing the rules is not enough.

The same applied to all games. While knowing the rules is essential to play the game, they do not inform the tactics and strategies of the game. The rules don't tell me what the best chess openings are or what the best endgame is. They don't explain the traps that happen when I move the queen to this position or the knight to this. They don't tell me the consequences of my move in two, three or four moves time. Knowledge of the rules alone explains none of these things.

How does this apply to the business world?

So we've established: Knowing the rules does not qualify us as a master of the game. Then why not apply the same standard to the professional world?

A Python certificate does not a Python developer make.

A Scrum certificate does not a Scrum Master make.

A Six Sigma certificate does not a Project Manager make.

We should not place blind trust in CVs or certificates that simply say that a person is qualified in subject X.

What signals mastery?

How would we know someone is good at chess? We would play them against someone else who is also good at chess.

The same goes when hiring candidates or evaluating people's expertise. Their CV says have some certificates - great! At least it means they probably have an interest. But we must make sure they can play the game.

My favourite way to evaluate expertise is to talk to the person about problem scenarios in their field. In my opinion, this is how all interviews should be conducted (not multi-day take-home assignments or leetcode exercises). If it's a programming problem, let's talk through it together and come up with a solution on paper first and then write some code. If it's a leadership problem, let's discuss the assumptions, ideas and proposals to solve it.

That's how we check for expertise - we see if they can play the game.

How can I show I'm an expert in something?

At the risk of repeating myself: Show others you can play the game.

Show them that you don't just know the rules but can apply tactics and strategies to real world problems. Write about the times you've played the game. Tell them about the mistakes you've made and what you've learned. Build things to prove that you can build them.

Of course, all of this assumes one important thing: You must know what you're talking about.

While there are shortcuts to achieve expertise quicker (namely focus), nothing replaces putting in the hard work. That doesn't mean you need to spend 2 hours everyday for the next year learning how to play the game (but if you have the time why not!?). However, it does mean that you need to keep chipping away at it. A little bit here, a little bit there - it all adds up. But please, please, don't stop after just learning the rules.

The rules matter.

But playing the game matters most.

I wrote previously about lessons I wish I knew when onboarding to a new project. Using the information in that post (plus some more lessons I've learned along the way), here is a useful checklist to use when onboarding to a new project.

Questions for the Team to Answer

Tips for the Team

Questions for the Team Lead to ask

Note: Team lead can refer to Scrum Master, Manager or technical lead.

Tips for the Team Lead

What is a culture?

If you want an equation, here's mine: Culture = Behaviours + Expectations + Wisdom

Cultural Behaviours

Pick any group and you will quickly see that each has their own ways of interacting and behaving with each other.

• Country
• County (especially in Ireland!)
• Village
• Local community
• Family
• Company
• Team

Cultural behaviours are unconciously picked up when we integrate into a new group of people. If you have travelled abroad to multiple countries, you know that the 'feeling' between coutries is very different. If you have stayed with another family for a few days, the 'feeling' of that family feels foreign, strange and often uncomfortable. A family member of mine says "Other people's families are always very strange". This is true. Different cultures are just that - different. People expect each other to behave in a certain way and give a strange look when that doesn't happen.

Cultural Expectations

If the first part of culture is its peoples' behaviours, then it follows that the second part is what people expect of you. When you go to France, you greet another person by kissing them on the cheek. You must point with your thumb instead of index finger in Malaysia. When you sit down for a meal with your family, you are expected to say Grace. We call these expectations 'customs'. Expectations keep people in check and produce a sense of belonging, protection and safety - an amazing evolutionary strategy we have developed.

Cultural Wisdom

Thirdly, wisdom plays a huge role in culture. Over time, the culture's behaviours and expectations become instinct to its people. In other words, the culture's people build a body of wisdom which comes naturally to them.

It is common for people who misunderstand a culture to treat it with resentment. But cultures are formed through behaviours that have given its people support to survive and thrive. In other words - cultures form over time because they work for that group of people. This doesn't mean that change should not happen. But we should be careful not to throw out the baby with the bathwater. Some behaviours are good, others are bad, and some are just different.

The body of wisdom that is built up in a culture should be treated as just that - wisdom. Not a list of rules that have come from 'back in the day' that we need to change and get rid of simply because they are old.

So when we talk about culture, remember: Culture = Behaviours + Expectations + Wisdom

What is a Learning Culture?

If Culture = Behaviours + Expectations + Wisdom, then Learning Culture = Learning Behaviours + Learning Expectations + Wisdom about Learning. You need to understand what behaviours will help your colleagues progress their knowledge. This is the primary purpose of L&D. Without knowing how people learn and what their learning needs are, any L&D individual will fail to understand what learning behaviours should be encouraged.

How is a Learning Culture Created?

Cultures are made up of complex people and, as a result, are complex things themselves. In “Toyota Kata”, Mike Rother describes structured, practised behaviours that are the building blocks of a learning culture.

Learning Behaviours

What behaviours do you want from your colleagues when it comes to learning? Narrow in on specific behaviours, right down to the scenario and task level. As you develop and support different scenarios your colleagues experience, they start building a set of behaviours condusive to their learning. Be warned though - you cannot force people to behave in a certain way. You can only encourage things that they want to do. Focus on the individual's strengths and interests to understand how they can enrich your company's learning culture. For example:

• Someone interested in coaching might be able to give workshops to teams.
• A subject matter expert might be interested in mentoring new joiners.
• A new joiner might be able to become owner of a team's documentation and improve it in some way.

List the Learning Behaviours

List down the behaviours you want to see in your organisation.

• I want people to learn everyday.
• I want teams to continuously improve.
• I want managers to enable change.

Each item is a high-level expectation. Get specific. Divide each item into specific scenarios you want to see.

For example:

Behaviour: I want people to learn everyday.

• Scenario: When someone sees something useful, they note it down and bring it to their daily work.
• Scenario: People take online courses in areas that they are interested in at least once a week.
• Scenario: People read books on topics they are interested in.

The more scenarios you can think of, the better.

Next, prioritise your list of scenarios and break them into actions you will take.

Scenario: People read books on topics they are interested in.

• Action: Create a library area in the office with 100 books.
• Action: Enable people to order any book they want to add to the library.
• Action: Have a monthly 'book' day where people share what books they've read and what they have learned.

As you can see, wishing for a learning culture to appear is not good enough - get specific! Otherwise, your colleagues will become disenfranchised with your mission and, worst of all, become apathetic.

Having said this, your goal isn't to encourage every behaviour in every individual. Some encouragement with some individuals is enough. Small wins along the way is the goal.

Learning Expectations

After you've figured out which behaviours to encourage, the next step is to look at expectations. What should your colleagues expect from each other? The lazy answer of "I just want people to be better everyday" isn't good enough.

Step back for a second. What if someone came up to you and said "I want you to be better today". You wouldn't know what to do.

It is easy to say "I expect people to learn", but without accepting the responsibility of providing encouragement and support, then they are empty words. L&D must put their money and time where their mouth is.

What About Hiring?

It is difficult enough to promote culture amongst people who agree with its principles. It is impossible to do it amongst those who don't. In his book 'Principles', Ray Dalio writes how his company, Bridgewater, hire for a specific kind of culture.

Bridgewater's culture values brutal honesty above all else. If you think this results in a nice work environment where everyone is up front with each other, you would be wrong. It results in an environment many people are not cut out for.

Imagine if every proposal was met with everyone in the room responding with "I disagree with you because XYZ". Imagine if every single action was challenged by multiple people in the room.

A look at Glassdoor reviews shows these values coming through as good and bad, depending on who is commenting.

• "Culture is huge here, managers really like to take an interest in people's inherent personalities and tendencies. As someone who likes a demarkation between work and personal life, such a probing culture isn't really conducive for that."
• "It's not for the weak-stomached. If straightforward feedback induces anxiety, this would not be a healthy work environment for you."

Are these 'bad' reviews, or is it more likely that you need suitable personality traits and values to succeed in such an environment? While this may be an extreme case, it illustrates my point. People with values anti-thetical to the culture will not thrive. So you need to be up front with potential employees from the very beginning.

If you are building a Learning Culture, it needs to be screened at the interview stage.

• Do you work better alone or with other people?
• Walk me through a time you improved someone else's job.
• What is the last project you made outside your work (technical or not)?

No interview questions are 100% perfect, but the goal of any interview is to estimate if this person would fit well in your company. If the person does not display curiosity or enjoy sharing information, then they likely won't thrive in a learning culture where these values are the foundations.

The End Result

Now that you have a list of behaviours you want to see, get to work! Over time, encouraging particular behaviours together with screening for good hires will build the culture you envisaged.

What is a Learning Cluster?

Below is the Learning Cluster template I use in my organisation.

A Learning Cluster is a selection of learning assets given to the learner at their moment of need. The biggest benefit for both L&D and the learner is that whether the learner wants to watch a video, read a book or find a quick definition, it is all provided in a single location. With a Learning Cluster, the learner chooses what they want to learn, how they want to learn and when they want to learn.

How do I give the learner what they need when they need it?

L&D's challenge is to understand and answer this question: "What does my learner need to know and how can I help them get there?". Every industry is ever changing, growing, and becoming more complex, so much so that we all need to constantly adapt to keep up. This has resulted in the rise of the L&D discipline.

However, we in L&D are still asking the question "How can I train my colleagues to be better?". This is an outdated question. Today's question is "How can I help my colleagues make better decisions when it counts?". Better decision making underpins every discipline and therefore L&D's mission must enable people to make better decisions.

Now two questions come to mind:

• How can I help my colleagues make better decisions?
• How do I know when they need that help?

I think the answer to both questions is something along the lines of "I don't know what people need or when they need it, but I'll have something ready when they come looking".

The benefit of learning clusters is that we don't need to ask questions like:

• What situation is the learner in?
• How much time do they have?
• Do they want to read a blog post, watch a video or see a live talk?

By putting all options on the table, the learner can decide themselves what they need and when they need it. In the same way that a restaurant offers you a menu of options instead of trying to understand if you're meat or vegetarian, Learning Clusters give you the option of making your own decisions.

How Do Learning Clusters Help the Learner?

Learners want to choose how, when and where to learn. This poses a challenge for L&D: How do we provide everything in a single place?

By giving the learner a cluster of options to choose from, we are more likely to meet their moment of need. It doesn't mean that every learner will look at every assets. That's not the point. By adding a cluster of options to choose from, it is more likely that the learner will use at least one of the options. We're not looking for big wins here. Incremental improvements to our colleagues knowledge is our goal.

Developing Learning Clusters

Use the template at the beginning of this article to create a cluster for any skill you want. You can probably think of a way to upgrade it and make it even more relevant for your organisation. Next, choose a topic you want to address, for example "Email Security".

What do you want to achieve with this Learning Cluster?

• I want to provide a cluster of assets about email security
• So that my colleagues do not send sensitive information or click on dangerous content.

Once your goal is laid out, fill in your cluster. You can use custom content created by your organisation or find free content online. As you get better at collating links and resources, you will develop a list of useful websites to use in future Learning Clusters.

Where did they come from?

Learning clusters are part of a larger framework called the Owens-Kadkia Learning Cluster Design Model (OK-LCD Model) which attempts to bring together and expand on learning models such as ADDIE and SAM.

The authors, Crystal Kadakia and Lisa M.D. Owens, saw poorly executed goals within L&D. Namely, that L&D were focused on a single thing - a deliverable to close the capability gap. The deliverable could be a wide range of options such as an interactive video, classroom training or a manual. But the deliverable was always just one element.

What's the problem with delivering one element for one problem? Learners don't want to be told what to learn, when to learn or how to learn. Learners want to be able to choose how, when, where and what they want learn. L&D therefore need to shift from the "1 problem = 1 deliverable" mindset and move towards a "Learning Cluster" mindset.

One problem should not be met with a single solution. It means we put all our eggs in one basket. Instead, by creating a diverse suite of deliverables, we give the power back to the learner and increase the likelihood that they will find something useful and enjoyable in our deliverables.

For more information on the wider framework, see "Designing for Modern Learning" by Kadakia and Owens.

What is Continuous Improvement?

Continuous Improvement is often an abstract and vague term to describe better ways of working. Within the context of business and technology, Continuous Improvement seeks to enhance every aspect of value in a team's processes and products. By reducing waste, reducing burden, and increasing consistency, teams boost the value they produce towards their stakeholders. It is impossible to remove all waste, burden and inconsistency completely from the team's work, but teams should work to minimize each one incrementally. This incremental change is what we refer to as Continuous Improvement. Let's look at Continuous Improvement and how we can utilize its main driver - the "Retrospective".

Continuous Improvement Lifecycle

As teams deliver value, it is important to regularly reflect and ask the question: "What can we improve next?". During this reflection, the team brainstorms ideas on what experiments they can try out (also known as actions or improvements). These experiments hope to deliver an incremental gain in the team's value. Repeated experiments encourage innovation, risk and courage, each of which are important for a team's progress. This cycle of Retrospect => Experiment => Improve => Value is called Continuous Improvement.

Continuous Improvement in Sport

Let's step back for a minute and look at Continuous Improvement in the world of sport. In 2002, Sir Dave Brailsford joined as head of the British Cycling team. Prior to Sir Dave's leadership, British Cycling had won just one gold medal in almost 80 years. In 2008 Beijing Olympics, Sir Dave led the British track cycling team to 7 out of 10 gold medals! After achieving this staggering result, he turned his focus towards "Team Sky" - Britain's first ever pro cycling team. He led Team Sky to 6 out of the last 9 Tour De France events, an impressive feat to say the least.

How did Sir Dave achieve this? Sir Dave held an MBA and used methods of Continuous Improvement when coaching his teams. He looked for small things to improve in how the team worked together, referring to these improvements as "marginal gains".

"Forget about perfection; focus on progression and compound the improvements." - Sir Dave Brailsford

The team hired a wind tunnel to understand and experiment with aerodynamics. They painted their truck's floor white to detect and reduce dirt on the bikes. They even brought their own mattresses and pillows to each hotel to get a good night's sleep! By regular retrospection, the team encouraged ownership and, eventually, everyone started to come up with their own ideas for improvements which, in the end, led to their huge success. This is the power of Continuous Improvement. "Marginal gains" made frequently in the short term encourages growth and prosperity in the long term.

Continuous Improvement is an Engine

Think of Continuous Improvement as an engine. The purpose of an engine is to drive something forward in a given direction. Continuous Improvement should be the engine that drives your team forward to deliver more and more value each iteration.

Retrospectives are the Fuel

All engines need fuel. Without fuel, the engine slows down and stops. If Continuous Improvement is your team's engine, then the Retrospective (henceforth referred to as the 'Retro') is your team's fuel. Like an engine without fuel, Continuous Improvement without Retros slows down and stops. A car that does not move forward becomes a stagnant, empty shell that is only nice to look at (many people own such cars!). We do not want to be teams that are stagnant, empty shells with nothing to drive us forward. We want to be innovative and come up with creative solutions to our own problems.

Forward progress gives us satisfaction in our jobs and without that sense of progress, we become scattered and burnt out. But to achieve progress and forward motion, we need fuel. We need Retros to provide fuel to our engine.

What is a Retro?

Team Meeting

The Retro is a team meeting where space is created for everyone to learn and brainstorm ideas. It is important that the whole team contributes towards the Retro. A Retro in which only part of the team speaks up is not a good Retro. For example, it is common for the loudest person on the team to speak the most in Retros. Or maybe people do not want to speak up because the most experienced person will argue them down. But the Retro is one of the few places where all members of the team come together as equals. The Retro facilitator should work to ensure all members contribute and have their voice heard.

Regular Schedule

If the Retro is the fuel to your team's engine, then it needs to be topped up frequently. Therefore, Retros should be scheduled on a regular basis. They should be monthly at a minimum, but ideally more often. In between Retros, the team can test their experiment ideas and gather feedback for the next Retro. The Retro should also close out your team's iteration period. For example, if your team works in cycles of two weeks, the Retro should be the last event of the cycle. By taking a Retro at the end of the cycle, it provides the team the opportunity to plan for the next cycle. If your team has no cycle time, then pick one - teams always work best with defined timelines.

Opportunity

Retros provide the opportunity for the team to give feedback about themselves, their processes, and their product. Whether you have been part of the team for a day or a decade, your opinion is equally valid in your team's Retro.

If you are new to the team, this is your opportunity to speak up about the things you find difficult and frustrating. Are you happy with the onboarding process? Are you invited to pair program on tasks? Do you understand your objectives as part of the larger team? As a new team member, it is up to both you and the team to make sure you are integrated and valuable to the people around you. If something is difficult as a new member, then have the courage to speak up and be honest in your team's Retro.

If you have been with your team for a longer period, you likely have valuable insights on the biggest problems you and your team face. Is the team's quality sufficient? Is there enough innovation and experiments happening in the team? Are you excited, bored, or burnt out with your work? With experience comes more expectations, but that does not mean you should expect to be stressed or under pressure all the time. Use the team's Retro to voice your concerns with your teammates. They just might surprise you!

Experiment

"What experiment do we want to run next?"

This is the question the team should work to answer in their Retro. Simply having a meeting called "Team Retro" will not achieve improvements without a solid outcome and plan for what happens afterwards. The real work is done between Retros where the chosen experiments are tried and tested. The Retro allows the team to learn about problems, identify solutions and pick an experiment going forward using methods like the 3 questions: "What went well? What did not go well? What should we improve?"

Think back to the experiments Sir Dave ran with his teams. White paint, mattresses, hand washing. These are not particularly profound ideas. I am sure there were many experiments and ideas Sir Dave's team tried which came to no avail. However, each time they tested something out, whether it succeeded or failed, the team learned something new. There was no single experiment that won gold for the team. Each success built on the last until, eventually, enough 1% marginal gains were made to achieve the gold.

A good Retro experiment will like the British cycling team's experiments - short, actionable, and valuable.

It needs to be short so the team can commit to it on top of their other work. "Pair program on critical tasks" is better than "Re-architect our software to support faster deployment".

It needs to be actionable so the team do not jump through hoops to complete it. "Order our stand-up tasks by priority instead of person" is better than "Suggest a new tool for ticket tracking to the organisation".

And it needs to be valuable so that the team can add it to their ways of working. "Scrum Master to close stand-up after 15 minutes" is more valuable than "Create unit tests for this deprecated piece of code".

Benefits of Retros

Develop Agency

Agency is a psychological term which means 'I can act on my own behalf'. A team with a sense of agency can act independently to control and change their surroundings. By raising their problems in the Retro, the team empowers themselves to come up with their own solutions. They develop ownership over their environment and push for change where change is needed.

Learn the Mood

"How do you feel?" "...Fine, and you?"

This is a common response when you throw the 'f' word at someone (feelings). While we don't like to share our feelings with other people, it can be a valuable piece of feedback for a team to understand each other's mood. In my team, we start off the Retro with a quick word from everyone on their mood in the past few weeks. We have yet to hear the word 'fine'. Usually we hear 'stressed', 'anxious', 'messy' or 'productive', 'fun' and 'exciting'.

Each answer gives a good insight into how the team's mood is. A positive overall answer indicates the team is doing something well and should continue to do so. A negative reaction indicates something needs to change and the retro should then focus on alleviating those negative points going forward.

Brainstorm Ideas

Any good team understands the need to innovate. Teams can only make Continuous Improvements if they have created the environment to brainstorm and innovate. Their Retro facilitates such an environment where ideas, both good and bad, are welcome. Without creative ideas, we cannot innovate. Without innovation, we cannot discover those marginal gains Sir Dave talked about. The Retro provides the space to identify these 1% improvements we can bring to the team. If each Retro facilitates just a 1% improvement to your team, imagine the massive changes that could happen over the course of a year.

What Next?

First things first - setup regular Retros with your team if you are not already doing so. Within each Retro, focus on a particular area the team would like to improve. This could be quality, bugs, meetings, processes, teamwork or anything else the team thinks is a priority. For each Retro, focus on answering the question: "What experiment do we want to run next?" Once the team picks an experiment to focus on, plan it into the next iteration and track whether it succeeds or fails.

Remember, the team's retro does not have to be a complicated or lengthy meeting. However, it does need to be taken regularly to yield those marginal gains and fuel your team's Continuous Improvement.

The retrospective occurs regularly in a high performing team and requires that the whole team come together to discuss their problems, solutions and improvements. As the team lead, if you aspire to lead a highly productive team, then the retro will be a key tool for identifying weak points in the team and working to address them.

These are some good practices that encourage teams to be open and increase the free flow of information.

Retro on the Last Day

Have retros as close as possible to the end of your sprint / team cycle. It is very easy to leave the retro until the start of the next sprint, but this leads to a couple of problems.

Firstly, your team forgets easily. After a couple of days, if you ask your team their problems for the last 3 weeks excluding the previous week, they won't remember anything. The team needs to have a fresh mind. That means having the retro as soon as your sprint is over, preferably on the same day it finishes. In my case, we take the latter half of Friday evening to relax together and go through the feedback from the previous three weeks.

Secondly, actions needs to be brought into the upcoming sprint. If your planning happens on the first day of your sprint, and you have the retro a day or 2 later, you can't address the problems on time and account for them in the sprint planning.

Make it fun

If the team don't enjoy getting together and talking, then they will not enjoy the retro. Make a game of it as much as possible.

Write feedback on colorful stickies. Bring in some biscuits or cake and have the retro over some coffee. Take a break from your usual office space and go out for lunch together.

Keep records organised

It is critical to connect each retro to the previous one. If your retro does not refer to previous retros to show progress, then the previous retro is effectively lost.

At the beginning of each retro, go through the actions from the previous retro. This develops value in the retro, because now your team feels that progress is being made.

If an item keeps coming up at every retro, address it ASAP. In my last retro, I realised that a problem (albeit small) was mentioned 5 retros in a row! That was a signal to me that it had to be prioritised.

Prioritise actions for the upcoming sprint

This is the most valuable part of your retro. Once the problems have been stated and solutions or improvements identified, prioritise them and execute on them. This could be on a technical level (test cases missing) or on an interpersonal level (manager X is interfering in the team).

Pick out the top two or three actions your team think are needed as a priority. Create tasks from these actions and bring them into the upcoming planning session to make sure they get completed.

Put the tasks front and center - don't let them get lost on a virtual document where nobody can see it. You could create physical stickies on a notice board above your team space or put them on your virtual board that you share at your morning standup.

Remember, without making an effort to improve the team's problems, the retro is of no benefit.

Don't leave problems until the retro

As the team lead, take note of the problems during the sprint. Don't let the team get into the habit of saying "It's fine for now - we'll discuss it at the retro". It is tempting to get lazy or to delay fixing problems. By the time the retro comes, they will have forgotten their pain.

Get the team to practice bringing up issues as they arise. You can discuss them further in the retro, but the right moment to discuss is now, not later.

Case Study

The following is an example of how my team performs our retrospective.

Frequency: Every 3rd Friday
Attendees: Whole team, sometimes the product owner in the background.
Preparation: Create a digital document with the following categories:

• Previous retro.
  • Fill in with the actions.
• The Good
• The Bad
• General Improvements
• Top 3 actions
• Thank yous

Schedule

Previous Actions

Briefly go through the previous retro's actions.
Were the most important actions completed? If not, why?

Example

• [John] Raise a ticket with operations to fix our test environment. DONE.

The Good

Take 5 mins for each person to write down what they enjoyed or what they achieved since the last retro. Categorize the items and pick out the common themes. This is where your team pats themselves on the back for the good work they have done.

Example

• Great communication despite working from home. [TEAM]
• Quick response to messages online from the team. [TEAM]
• Less than 5 bugs for the whole sprint. [BUGS]

The Bad

Categorize and discuss the bad things that have happened since your last retro. Make sure you attach a solution or improvement to each bad item.

Example

• Frequent missing of morning standup meetings.
  • Improvement: Move morning standup ahead by 15 mins to avoid the clash with the other meeting.
• Poor ticket writing from our QA team.
  • Improvement: Create a template for the QA team to fill out every time they write a ticket.

General Improvements

What general improvements would the team like to discuss?

Example

• A test case is missing in our test suite. We should add it before we get stung with a bug ticket.
• The morning standups are going over the 15 mins mark - set a timer to cut off the standup at 15 mins.

Top 3 actions

What are the top 3 things from 'The Bad' and 'General Improvements' we should address in the next sprint?

Thank yous (Optional)

This can be a nice way of finishing off the retro. It is surprising how powerful saying thank you to someone can be. They will be more inclined to help you in the future. Is there anyone we should thank that helped us out?

How to know you're not focusing

Do you ask yourself any of these questions?

• Where am I going in my job?
• Why do I feel demotivated even though I have the position I always wanted?
• How do I get rid of the feeling of being stuck?
• Why am I not motivated to improve anything?
• Why do I feel the need to try everything?

I've had some of these questions in the past. Sometimes, I've achieved exactly what I wanted and set out to do, but I still had the feeling I wasn't progressing. Some people say "I'd love to be the CEO of a company some day". But when I hear that, I hear "I'd love to achieve the title of CEO some day". And this tells me that they probably have no idea what being a CEO entails. Because achieving the title is arguably the easiest part of being a CEO. The real journey begins after that.

And this is what I admire about people in big positions. Think CEOs, presidents, politicians, sports people. They understand there is no final destination. Once they have accomplished something big, they know they have to wake up the next day and keep moving. This mindset is different to the mindset most of us have. We generally treat the goal as the final destination. The CEO treats their accomplishment as a milestone along a bigger journey. When we treat goals as final destinations, we can get caught asking ourselves the questions like "Ok I achieve my difficult goal...what's next?". The CEO needs to start leading the company. The graduate needs to start looking for a job. The PHD graduate needs to know what to do with their PHD. The Wimbledon champion needs to prepare for next years' competition.

Developing a Vision

Goals need to have a bigger picture that include ourselves and the people around us. When the CEO wakes up everyday to a new problem that could end the company, they need to be able to say "This is worth getting up for because...". When the PHD student is feeling burnt out in their 3rd year of consecutive study, they need to be able to say "I'm going through this pain because...". The same goes for any difficult task. You need to be able to say "This is worth it because...".

The "because" is our vision.

• What will solving this problem get you?
• What step of the journey will you be closer to after today?
• Why is the pain today / this week / this month / this year worth it?

The answer is unique to everyone and can include visions like family, career, health and finances.

Writing it down

For some reason, writing down our vision and integrating our current goals gives it more power. It is difficult to write down what we want for the future, because acknowledging what could be means acknowledging what might not happen. But doing so organises our messy thoughts. We might think we know what we want becuase we've said "I've thought about this a lot". But we haven't really thought about it unless it's written down. The future is too complicated to analyze in our heads. There are too many variables, conflicts and outcomes.

For example, I recently wrote down my vision of the future. After identifying the main goals and defining the steps to getting there, I realised two goals were in conflict. I saw that developing my new hobby required me to be away every Saturday for a few hours, conflicting with another goal to spend more time with my family. Until I wrote this down, I didn't see the conflict, even though it seems obvious in hindsight.

Steps to developing a vision

If you want to try this out, you can start developing a vision by answering the following questions:

• Where do you want to be in 5 years with your job?
• Describe what your ideal family life would be like. Include parents, siblings, children, partner...
• Combine everything and describe your ideal future:
  • Where do you want to be?
  • What do you want to do?
  • What kind of person do you want to be?
  • Why do you want these things?
  • What steps will you take towards these goals?
  • When will you start each step?

Finally, describe the kind of vision you don't want. As you right out a future you dislike, you will realise that it is not only possible, but likely to happen if you don't work towards your vision.

• If you failed to achieve the above, how would you feel?
• What does the future look like with none of the above goals achieved?
• Would failing to achieve your vision cause pain or anxiety on you or your loved ones?

While the previous exercises describe a vision to run towards, this will help you build a picture of the kind of future you want to run away from.

This is a series of exercises in preparation for scrum.org's PSM certifications. I have gathered these scenarios from the internet together with my own experiences. Any answer will be based from my understanding of the Scrum Guide.

Source by Alen Pekic on scrum.org.

Scenario

A Development Team, arguing it is self-organising, indicates it no longer needs the Daily Scrum; they collaborate throughout the day and they feel it has become a needless ritual. What should the Scrum Master do?

Answer

Re-iterate the Daily Scrum's Purpose

The Daily Scrum is an opportunity to inspect and adapt while being transparent with the rest of the team. Other collaborations during the day are great, but they do not provide the main object of the Daily Scrum: Create a 24 hour forecast of work to get closer to the Sprint Goal. The Scrum Master should bring forward examples of when the Daily Scrum recently proved useful. Similarly, examples of what could happen if the Daily Scrum was removed could help the Dev Team think about it in a more positive light.

The Root Cause

The Scrum Master must try to understand why the Dev Team find the Daily Scrum a 'needless ritual' - this is the root cause of the whole complaint. The Scrum Master should put the question to his team: "How can we make the Daily Scrum useful?"

A similar situation occurred in my team which was exacerbated during lockdown. The Dev Team felt the Daily Scrum had turned stale where nobody listened to each other. The Daily Scrum had devolved into an individual status update instead of a team collaboration event. In my case, the Dev Team's concern that the Daily Scrum was a 'needless ritual' was completely valid! A morning status meeting does not promote teamwork throughout the day. In the Daily Scrum, the team must forecast the work for the day and discuss how they will get it done.

Since the Dev Team do not find the Daily Scrum useful anymore, the Scrum Master should facilitate a brainstorming session with the team on how to make their Daily Scrum useful. For example, rather than stepping through each person saying "Yesterday I did X, Today I will do Y, No support required", the Scrum Master could suggest the team restructure their Daily Scrum around top priority issues. This could help the Dev Team to pair program on critical items and focus on what is important for the day. This would transform the Daily Scrum to create a plan on "How can we close these critical items as fast as possible?".

Here are some other ideas to help re-structure the Dev Team's Daily Scrum:

• Prioritise tickets by turnover time: The longer the ticket is open, the more priority it has.
• Keep it to 15 minutes (surprisingly many teams do not stick to the 15 minute rule!).
• Establish an 'interrupter' for each Daily Scrum - someone who steps in if a conversation goes on too long and needs to be taken offline.
• #lookForward - Only focus on the plan for the future, not what each person did yesterday.

This is a series of exercises in preparation for scrum.org's PSM certifications. I have gathered these scenarios from the internet together with my own experiences. Any answer will be based from my understanding of the Scrum Guide.

Source by Alen Pekic on scrum.org.

Scenario

You are a Scrum Master working with a Scrum Team. The Development Team constantly complain that requirements are not clear enough. The Product Owner claims she is too busy to provide extra clarity. What should the Scrum Master do?

Answer

Coach the Dev Team

Since the complaint comes from the development team, the Scrum Master should first work with the dev team to answer the question: "What criteria do we need to commit to each requirement?" The result should be a list of checkboxes, commonly known as a "Definition of Ready".

A Definition of Ready is a useful set of criteria for the team to check against each requirement they discuss. If a requirement satisfies the Definition of Ready, both the Product Owner and the Dev Team agree it is ready to be taken. This further promotes commitment to each product backlog item during the sprint planning.

Coach the Product Owner

There are different solutions for the Scrum Master to suggest to the Product Owner depending on how much time the Product Owner has available.

Firstly, the Scrum Master should remind the Product Owner of the importance of transparency between her and the Dev Team. If this transparency reduces, the team will deliver something that is not valuable to the customer, resulting in wasted sprints and, more importantly, wasted budget. The Product Backlog needs to be transparent to the dev team so that they understand what will bring value to their customers and what they need to focus on for their sprint.

Secondly, if the Dev Team continue to complain about unclear requirements, the Scrum Master can suggest a dedicated weekly sync-up between the Dev Team and the Product Owner. This meeting would serve to discuss top priority product backlog items together with any questions the Dev Team has on sprint backlog items.

Thirdly, if weekly meetings do not work, the Scrum Master should recommend the Dev Team to directly contact the customer. Although the Product Owner acts as the main interface for the customer, it does not prohibit the Dev Team from reaching out directly.

Finally, if none of these actions bring clarification, the Scrum Master can encourage the Dev Team to proceed based on their own assumptions. The Dev Team should also contact the Product Owner via email to state their assumptions and how they will proceed.

Coach the Whole Scrum Team

The Scrum Master should constantly ask questions that challenge the whole team.

• How can we commit to each product backlog increment?
• Does everyone understand these requirements?
• How can we avoid similar confusions in the future?

Asking well-placed question encourages the team to be open and have the courage to speak up when required. A clear product backlog is essential for the team to have focus and commitment towards their product increments.

Retrospectives are the team’s most valuable meeting. They enable the team to inspect and adapt their ways of working on a regular basis. Small, regular retros bring small, regular improvements to the team. Teams often launch into their retrospective meeting without a plan. The team goes into a room, writes down some thoughts on sticky notes and categorises them into “Good/Bad/Improvement ideas”. Then some (or lots of) actions are assigned and the meeting ends. A discussion is held on each item, actions are assigned and the meeting finishes.

While this can be effective, there is a better way to run retros and maximise their value. Retros usually do not deliver something tangible that is immediately obvious or valuable and so they can be taken for granted,. They are essential for long term growth but teams often feel that they are a ‘nice-to-have’ meeting.

Without well-run retros, your team cannot hope to improve significantly over time as they are removing the main opportunity to inspect and adapt. A good retro should follow the same rules as a good meeting. Think about all of the meetings you attend which are a waste of time. What do they have in common?

• They have no goal.
• They have no structure.
• They have no start or end time.
• There are too many people.
• They have no output, actions or follow up.

If our retros follow the same bad practices, why should we expect them to be anything but a wasteful meeting?

Below is a template I am developing with teams to run retrospectives. It is largely derived from Derby and Larsen’s expertise in the area, together with some additions I have found helpful for the teams. If you want to deep dive each section of the retro meeting, I suggest to read “Agile Retrospectives: Making Good Teams Great”.

You can copy this template for each retro and refine it over time for your needs.

Template

0. Preparation

Write down the list of actions taken in the previous retro.

Gather the team data to be shown and analysed. For example:

• Burndown chart
• Velocity
• Number of bugs opened
• Number of bugs closed
• Number of stories completed
• Number of stories open at the end of the sprint
• Lines of code touched

Tip: Create a Runbook on how to gather each data point above or even better - automate the whole thing for each sprint with a tool like Jira!

1. Set the stage

Welcome

You are all welcome to this sprint's retrospective. The purpose of this meeting is to look back over the last sprint and gather feedback on what went well and what went poorly.

State the Goal

The goal for this retro is to...

• General goal: Reflect on the previous sprint what went well and what went poorly.
• Refined goal: Improve our teamwork/coding standards/XP practices.

Ask for a Word (Ice breaker)

Ask each person for a quick word. Examples:

• Can each person say what their energy level was this sprint (low/medium/high)?
• Can each person give a sentence on what they hope to gain this retrospective?
• With one word can you describe your mood this sprint?
• With one sentence, describe a high point of this sprint.

Plan

1. Timebox: 90 minutes
2. Review the last retros' actions and outcomes. Discuss further if necessary.
3. Show the data.
4. What was Good/Bad/Ideas/Thank yous.
5. Actions for next sprint.
6. Retro of retro.

2. Show the Data

Last Retro’s Actions

List the 1 or 2 actions from the last retro.

• Did we accomplish these actions?
• Why did we not accomplish them?
• Should we permanently add these actions to our ways of working?

Metrics

You should have metrics prepared prior to the retro to analyze with the team. For example:

• Burndown chart
• Velocity
• Number of bugs opened
• Number of bugs closed
• Number of stories completed
• Number of stories open at the end of the sprint
• Lines of code touched

Coach your team to look for insights with questions such as:

• What problems do we see from this chart?
• Are we happy with the number of bugs closed?
• I see this bug count doubled from previous sprints. Do we need to do something about that?
• Our velocity has halved in the last 2 sprints - do we think this is a problem?

Events/Insights

Ask the team to write down their thoughts for this sprint.

If the retro is in-person, use sticky notes on a whiteboard.

If the retro is remote, use a virtual retro board such as agile.coffee

Use a list of questions to get the team to think about different things. Examples:

• What was good/bad?
• Big announcements?
• Important decisions?
• New team members?
• Celebrations?
• High points?
• Low points?
• When were you excited to come to work?
• When did you dread coming to work?

Tip: Divide the whiteboard into columns such a Good/Bad/Ideas and place the sticky notes in the appropriate column.

Comments

Ask your team to quickly comment on any observations:

• Do we see any patterns on these sticky notes?
• Are there any surprises that we didn’t expect?

3. Create Actions/Improvements/Ideas

Go through each item and ask questions:

• Why did this happen?
• What can we learn from this?
• What action can we take to keep this going/prevent it in the future?

4. Decide What to Do Next

• Ask the team to vote on their top 2 actions they would like to try next sprint.
• Create tasks or notes in the backlog for these top 1 or 2 actions.
• Assign each action to a person where possible.

5. Close the Retro

• Take a screenshot / photo / save the output of the retro somewhere.
• Thank you for joining and putting in the effort to this retro and sprint.

Retro of retro

Before closing the meeting, ask your team:

• If you could change one thing in our retros, what would it be?

If anything big comes up, setup another call to discuss how to improve your retros.

6. Post-retro Activities

• Put the most popular 1 or 2 actions into a backlog item for next sprint.
• Record the retro outcome in a document or take a photo/screenshot. You will need to look back at the actions when you prepare for the next sprint’s retro.
• Note down any suggestions from the retro of retros.

Solving performance issues is a tricky business. Teams are often not knowledgeable in performance testing. When a performance bug comes in, it could be the team's first time to witness such an issue. Furthermore, performance bugs are always critical and need to be solved yesterday. If the team has the necessary skills to solve the issue, this would be manageable. However, many teams rarely have enough experience to fix performance bugs quickly. They often end up learning on the job as they watch their house burn down. This happened to my team in October 2019. The performance team raised a ticket against a critical use case in their test suite. Let's step through the sequence of events and highlight the principles I learned as team lead in hindsight. As I write this, I'm listening to Brendan Gregg talk about performance debugging. I'll try to add his thoughts to this too.

Day 0 - Ticket created

Our team owned the failed component in question - let's call it SweetShop. SweetShop creates and manages Sweets. Historically, SweetShop has been a problem. Our most difficult tickets have been related to SweetShop in some way. Suffice to say, my team does not have a good relationship with SweetShop. In the ticket description we saw "SweetShop logs say OutOfMemory after we create 2300 Sweets".

Day 1 - First responders

We picked up the bug the next morning. After a quick review of the ticket, we logged into the system to see the SweetShop logs. We confirmed what the QA team reported in the ticket: OutOfMemoryError: Java heap space. We suggested to QA to increase heap memory for SweetShop. That was our first possible solution.

Possible Solutions

1. Increase heap memory.

Principles Learned

• Respond to critical tickets quickly with the smallest possible solution.

Day 2 - Gather info

The next morning, the QA added more details to the ticket. The test was to verify that SweetShop can create and store 3000 Sweets. In hindsight, this ticket was poorly written from the outset. There were no details of what the QA team were trying to accomplish, only some errors they found in the logs. More importantly, there was no information on the test itself. A few simple data points always help the support team to get started quickly.

• What type of test is it? eg. Load, stability.
• What are you trying to accomplish in this test? eg. Create 3000 Sweets in 3 hours, Create as many Sweets as possible, Create infinite Sweets.
• Has this test passed historically or is this a new test?
• Who is observing the problem?

We logged onto the system and ran some of the common linux commands: top, iostat -x 1, netstat and so forth. Increasing the heap capacity did not remedy the failures. We even tried to install Zabbix to do some monitoring because on of our developers used it before. There was no thought give to what we were trying to achieve. Why would there be? We had no idea what to do and wanted the ticket closed ASAP. In Netflix they call this the Street Light Anti-Method. In other words, start with the problem first, then use the right tools to figure out what is wrong. Don't start with the tools you know simply because you know them.

Possible Solutions

1. Increase heap memory.

Principles Learned

• Do not investigate any ticket until sufficient details are added.
• Ask basic questions to understand the problem.
• Once you have asked your questions, then find the tools.

Day 3 - Bring in the troops

On Day 3, our ticket appeared on the management's morning stand up. When this happens, the ticket goes straight to the top of our priority list and our mission becomes simple: Get the ticket solved. So we shifted gears. We requested to see the system logs for SweetShop and the scripts they used to create their Sweets. The QA team kindly responded with a link to a Jenkins job which supposedly ran the scripts. In other words, find the scripts yourself - lovely! To top it off, we were cc'd to a management thread with our ticket name as the title.

Possible Solutions

1. Increase heap memory.

Principles Learned

• Do not accept vague information. Make sure you get exactly what you asked for.
• If a manager wants something ASAP (as was this case when we were cc'd), don't expect anything less from their side. Escalate quickly if you don't get what you want.

Day 4 - It's Getting Hot

I should say that this was our first major performance issue. We were learning on the job and struggling to think of ideas. This meant we had no monitoring tools setup or any idea of what tools we could use. All we had was the failed system and the QA script that said Sweet123 creation successful or Sweet999 creation failed. Nevertheless, we weren't lying down. We rejected the Jenkins job link that we received the previous evening and demanded the scripts be provided. Once received, two of our teams began their investigation.

In parallel, we looked into SweetShop performance tuning. We found a troubleshooting page that said the min and max heap size should be set to the same value. We had the min heap = 2GB and max heap = 4GB. This indicated that the garbage collector could be insufficient at higher levels of load. Heap size was back on the table as a solution! We set the min heap and max heap to 4GB each. Even if it didn't fix the situation, it was recommended by the SweetShop support and so should go in.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.

Principles Learned

• Look for shortcuts to a solution. Close off as many paths as possible in parallel.

Day 5 - A Blind Scramble

At this stage we had two devs looking into the test scripts and an idea to tune the heap. Being a pessimistic team, we weren't ready to relax. We needed more information on how the system was behaving at load. We had nothing setup to monitor our systems - big mistake! This was our first performance bug. We hadn't prepared for anything like this before. We checked with other teams - they had nothing either! Fortunately, linux comes with a few handy tools. We ran the performance tests on 3 different systems. On two of those systems, we increased the heap size to see if it would help. On the other system, we created a quick python script to create batches of 10 Sweets with a delay between batches. While one of the tests was running, someone spotted that the garbage collector was slowing down significantly. The beginning of the test looked like:

tail -f /path/to/gc.log
Total time for which application threads were stopped: 0.0001006 seconds

The 500th Sweet creation looked like:

tail -f /path/to/gc.log
Total time for which application threads were stopped: 3.0001342 seconds

A few hours later, the 1500th Sweet creation looked like:

tail -f /path/to/gc.log
Total time for which application threads were stopped: 24.1947332 seconds

Then, the system started to fail. Since the heap was increased and the garbage collector was still having trouble, we decided to increase the time between batches to see what was the issue.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.

Principles Learned

• Performance testing must be accompanied by the appropriate debug tools.

Day 6 & 7 Getting Somewhere

Some good news came the following morning. With the delay of 2.5 seconds, the performance tests managed to create 2600 Sweets. Ok - we were onto something. We looked through the scripts once more to see if anything else could cause unnecessary load on the system. Wait..what's this? CONCURRENCY=20 How did we miss that the first time? That puts a huge load on the SweetShop service! We weren't even sure if it could officially handle that level of load.

We updated the test scripts and ran them again with the following parameters:

• Batch delay = 4 seconds.
• Concurrency = 10.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.

Principles Learned

• Do not blindly trust tests written by other people against your service. They may be testing something that is not supported.

Day 8 One Step Forward, Two Steps Back

The next morning we got a new result - only 1750 Sweets were created. This was frustrating! Again, we saw OutOfMemoryError: Java heap space in the logs. So none of our changes had resolved the issue. The day was spent trawling through all the logs again to see was there anything we missed. In the meantime, the performance team kicked off another run for some extra feedback.

Possible Solution

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.

Day 9 Blame Someone Else

We weren't making much progress for such a high priority ticket. We decided to take the failed system with 1750 Sweets and push it to see how far it would go. We created our own python script to create a single Sweet one at a time in sequence. We removed the batches and the time delays and connected a java monitor to the system. The result: 62 Sweets were created in 16 hours. The java monitor showed the heap was maxed out constantly at 4GB. We suspected something was happening with the createSweet method so we opened a ticket on the development team who handled some of this code. I believe this violated another one of Netflix's anti-methods - Blame Someone Else:

• Find a system you are not responsible for. In this case the java functionality - Done.
• Hypothesize that the issue is with that component - Done.
• Redirect the issue to the responsible team - Done.
• When proven wrong, go to 1 - Todo.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.

The development team observed that the system significantly slowed down after the 1000th Sweet. The CPU also maxed out a 100% - embarrassingly, we didn't spot this. The development team decided it wasn't their code and pushed it off as an internal bug to SweetShop, completing our cycle of the Blame Someone Else Anti-Method:

• Find a system you are not responsible for - Done.
• Hypothesize that the issue is with that component - Done.
• Redirect the issue to the responsible team - Done.
• When proven wrong, go to 1 - Done.

Let's update our solution list.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.

Now we had two tickets. The first was ours to figure out how to successfully create 3000 sweets. The second was the one we raised on the development team to figure out why the createSweet is inefficient at high load. The second ticket in turn was connected to a SweetShop support ticket - what a mess! Remember the manager's standup? Our ticket was front and center each morning.

Principles Learned

• Don't "Blame Someone Else". Instead pull in people to help without assigning blame to them.

Day 15 A Slow Death...Then

Days went by with no progress. Each morning, our team gave a status update like "We are trying x, y and z but no success yet". I suppose this violates the Drunk Man Anti-Method:

• Try things at random until the problem goes away. The development team attempted some improvements recommended by SweetShop support, but nothing improved the situation.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.

A week later, we found a way forward. The SweetShop support finally admitted "We don't support this number of Sweets in a system. We would expect issues with the garbage collection. Please upgrade to the latest version to resolve this." In other words, there is a garbage collection bug in SweetShop that cannot be patched. A major upgrade would take months of work, so that was not an option since our quarterly release was about 6 weeks away. But this was good news for our team. At least we now knew there was a limitation where a permanent fix was not possible. Next task: figure out a way to clear the heap and free up some memory.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop.

After some experimenting, we found that the SweetShop garbage collection could be completely cleared via a service restart. So we were left with a dilemna. Restarting services as part of a load test is not a real solution. In fact, it's a really...really bad solution. But we were in a tight situation and had no other alternative. To propose it to management, we needed a plan to completely resolve it. After pushing the SweetShop support team, they recommended upgrading our product from v2 to v6. SweetShop v6 had improved garbage collection capabilities. We added it to our solution plan:

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop to v6 in Q1.

As I said, a major upgrade would take months of work. Our quarterly release was only a few weeks away. So what could we do right now? What quick and dirty solutions are on the table? We know that a restart clears the garbage collector. So we restarted SweetShop after every 500th Sweet created. We took the QA performance scripts and added in a service restart after every 500 Sweets. On the first run, we were able to run the full script up to 3000 Sweets - fantastic!!!

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 4 seconds between batches.
   • Reduce concurrency to 10.
   • Restart SweetShop after every 500 Sweets.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop to v6.

However, upon a review of the logs, we saw that 200 out of 3000 Sweets failed to create. Still, it was good progress. We reran the test again with smaller batch sizes - every 400 Sweets. We also added in some error handling to retry if a createSweet failed. This time, we successfully created all 3000 Sweets. We updated our proposal:

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 4 seconds between batches.
   • Reduce concurrency to 10.
   • Restart SweetShop after every 500 400 Sweets.
   • If creation fails, retry.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop to v6.

The proposal was agreed along with a lengthy explanation to our release notes why this use case had a serious limitation.

Principles Learned

• Don't discount quick and dirty solutions. Every solution is on the table in a critical scenario.

The ticket was closed...until...

Day 45 Dec 6

"We see this issue again in system 6!" Considering the quaterly release was just 2 weeks away, this was not a pleasant message to see in the afternoon. Ok, let's review the situation.

• The proposal was actioned 30 days ago.
• Multiple performance tests were run since the proposal.
• No further issues were seen until now.
• No changes had been made to SweetShop.

Something didn't add up. We asked the QA engineer if they ran the exact same test as last month. They confirmed "Of course". "Of course" - two words which I now know translate to "maybe". Fortunately, we learned our lesson from Day 7: Do not blindly trust tests written by other people. We re-checked the parameters in the scripts:

• Batch size = 400 => OK
• Restart SweetShop between batches => OK
• Concurrency = 20 => not OK!!!

But "of course", the exact same test was run! I firmly responded to rerun the test with concurrency = 10. After this, the test passed and we never returned to it again.

Principles Learned

• I repeat: Do not trust tests written by other people. They may be testing something that is not supported!

Conclusion

While these couple of days were quite stressful, it resulted in a rewarding experience. We were able to attack the problem head on and rule out wrong solutions quickly. In the following sprints, we fed a lot of performance and monitoring improvements into our backlog. We didn't want to get stuck like that again. The principles we picked up along the way have been instrumental in how we handled subsequent performance tickets. Now, when a ticket comes in from the QA Performance team on SweetShop, we have a set of tools ready to analyze the problem and judge quickly what needs to be done to solve it. Here is a list of all the principles we learned along the way.

Principles Learned

• Respond to critical tickets quickly with the smallest possible solution.
• Do not investigate any ticket until sufficient details are added.
• Ask basic questions to understand the problem.
• Once you have asked your questions, then find the tools.
• Do not accept vague information. Make sure you get exactly what you asked for.
• If a manager wants something ASAP (as was this case when we were cc'd), don't expect anything less from their side. Escalate quickly if you don't get what you want.
• Look for shortcuts to a solution. Close off as many paths as possible in parallel.
• Performance testing must be accompanied by the appropriate debug tools.
• Do not blindly trust tests written by other people against your service. They may be testing something that is not supported.
• Don't "Blame Someone Else". Instead pull in people to help without assigning blame to them.
• Don't discount quick and dirty solutions. Every solution is on the table in a critical scenario.

How is time wasted in your team?

Teams require constant maintenance, updates and improvements. Otherwise, they become stagnant and inefficient. To become hyper-efficient, each team must analyse how they work. One key metric is to understand how much time your team wastes on repetitive tasks. While software developers are excellent at automating away their own problems, they often forget to focus on the team's problems.

If you analyse your team's time and value output, you will see many areas to improve. Obvious areas are poorly written bugs, too many meetings, poor communication with colleagues and so forth. But there is a category of work that is often overlooked - repetitive team tasks. Repetitive team tasks is any task that the team needs to perform on a regular basis.

Ask your team:

• What tasks do we do on a regular basis? e.g. Gather logs from a customer system.
• What topics do we constantly explain? e.g. How to install MyComponent on a Linux server.
• What issues regularly crop up? e.g. A bug with MyComponent which needs a workaround.
• What support do we regularly give? e.g. Recovering MyComponent in the event of a failure.

These examples are straightforward for the team member who knows what to do. However, team members are often out of office or unavailable to help. When this happens, something as simple as resolving a code conflict is difficult for someone who does not have the know how. This results in wasted cognitive expense as your team attempts to solve a problem that was previously solved. Your team's valuable time for new features is replaced with old, repetitive work.

We need to reduce this waste.

What are Runbooks?

Runbooks document your team's knowledge for the future. A runbook is a step-by-step recipe to solve a problem. With runbooks, your team can rely less on each other's availability. Instead, when a problem arises, they can search through a database of runbooks for a solution.

Runbooks contain clear and concise steps. They can be "How-To" guides, tutorials or any step-by-step instructions. Runbooks should not have walls of text. This is better left to blog posts and articles. Instead, sentences should be brief and bulleted.

What are the benefits of runbooks?

Most people don't write. It's not surprising - we're not paid to write. But writing down solutions to problems has a host of benefits. When teams document their solutions, they achieve hyper-efficiency quickly. With a runbook, the writer must deep dive into their problem. They must write in such a way that other people can read it quickly and efficiently.

After 6 months of documenting solutions, my team has written 114 runbooks. The top runbook has been viewed 125 times by our team of only 8 people. This top runbook is an extensive 'How-To' document which explains gotchas and workarounds when installing a dev environment. I estimate that each viewing saves about 30 mins. Therefore, this one runbook has saved the team 60 hours. If we account for another 113 runbooks, our team has easily saved 100s of hours.

What kind of runbooks can I create?

Create runbooks to solve specific problems. Not everything should be put into a runbook. Long topics do not facilitate quick and easy searching. Long form writing is also difficult to give quick information to the reader. So, what should go into a runbook?

Bug Runbooks

An in-depth analysis to my team's most difficult bugs has proved useful on multiple occasions. When I create a Bug Runbook, I ask myself: Who will need this in the future? Very often, a new bug is opened against our team where someone will say 'Hey I've seen this one before. Anyone remember how we solved it?'. When this happens, I need quick information about the previous bug.

Without runbooks, I need to go through the team's history of Jira tickets and search for keywords until I find it. Even when I find the old bug, if the assignee closed it in a hasty manner then a lot of information will be missing. Root causes are nowhere to be found. I am lucky if the assignee has even linked their code fix. On the other hand, let's say the bug ticket has a link to a runbook with the following information:

Key phrases

• RuntimeError in /path/to/logs.

Problem Statement

• User's login page failed to load.

Steps to Diagnose

• Viewed logs x and y.
• Checked the VM resources using df -h.
• Discovered the VM directory /var was full due to large logs.

Root Cause

• Customer set their logs to MESSAGE for some investigation then forgot to change back to INFO.

Steps to Fix

• Remove the log directory /path/to/logs to bring the VM back up.

Steps to Prevent

• Create an alarm to detect when the VM resources become too low.

Other things to note

• This happened to a system under heavy consumer load over the course of 2 weeks.

I now have a detailed root cause to a similar ticket. Instead of starting my investigation with no information, I have a possible root cause to quickly check if it solves my new ticket.

Runbooks with this analysis has saved us many hours of repetitive troubleshooting. I admit that most of our bug runbooks never get opened again after creation. But every so often we get a valuable analysis that is useful again and again. We think of runbooks as a method of automating our effort. Rather than spend a limited supply of brainpower repeatedly, we record it once with the hope that it will be useful in the future.

How-To Runbook

How-To Runbooks allow repetitive tasks to be semi-automated. A How-To Runbook should contain all details to figure out a particular scenario. Use these runbooks to setup dev environments, close tickets, create improvements, install software etc. Once a How-To Runbook is created, anyone in your team can use it whenever they please. Otherwise, you would have to ask your teammate to help when they already explained it to someone else. With a How-To Runbook, distractions are minimized as you streamline the team's knowledge into a shared database.

Our template for How-To Runbooks is very straightforward:

Scenario

• Explain when your team need to use this runbook.

Steps

1. Do x.
2. Do y.
3. Do z.

Process Runbook

Teams constantly shift. They get new members, people leave, they go on holidays and so forth. In many cases, the team processes are only known in depth by one or two people. If they take a sick day or leave the company, does someone know how to take over? For example, if your scrum master takes a day off unexpectedly, do you know how to plan the sprint with the dev team and product owner? Of if a new member joins the team, can they quickly learn about the team's processes?

Take a moment to think about what your team does on a regular basis. Describe that process in a Process Runbook.

For example, my team has a runbook for 'Story Workflow'.

Scenario

• A developer wants to take a story or task from the backlog to complete.

Steps

• Open your Jira ticket.
• Read the description.
• Write down anything you do not understand.
• Read the acceptance criteria.
  • Is it clear what you need to do?
  • If not, talk with your scrum master, product owner or a team member.
• What testing do you need? Comment this in the Jira ticket.
• What documentation do you need to update? Comment this in the Jira ticket.
• What tasks or steps will it take to complete this story? Comment this in the Jira ticket.
• After completing each step, add a comment to your ticket with your progress.
  • You should have at least one update per day.
• If you get stuck, request help from your team.
• Once all tasks are completed, show your team what you have accomplished. This is called a demo.
• To commit your code, follow this Runbook => Link.
• Ensure all code is reviewed by a team member and merged before closing your story.

When a new developer needs to work on a story, you can provide a workflow that is easy to follow. The developer can work by themselves (to a certain extent) without being hand-held through the process. Without a runbook for this, someone must assist the new developer to ensure that all steps are completed. This increases distractions and eats into the team's total time capacity.

Troubleshooting Runbook

Troubleshooting is a key part of any team. It can also be a frustrating part of the job, particularly for newer members. In general, teams learn new information ad hoc. Ad hoc learning results in different team members picking up different levels of information. This naturally leads to an inequality of expertise across the team. If there is a large inequality of expertise across the team, then a high dependency gets placed on one or two team members. Then, what happens when that person is absent? Or worse, what happens when that person is hit by a bus?

A couple of times a year, my team takes a meeting to ask, 'What is our bus factor?'. In this meeting, the goal is to identify each area of expertise we own and assign it a bus factor. Thereafter, we work to increase our bus factor on anything below 3. The quickest way to do this is for each expert to document their knowledge in a runbook.

Troubleshooting Runbooks are extremely beneficial to document methods of solving bugs or support issues. It will prevent trouble in your team when one or two are missing and a high priority bug comes in. Here is a short troubleshooting runbook we have in our team.

Scenario

• Developer wants to enable debug mode on MyComponent and check the debug logs.

Steps

• Open the MyComponent GUI => https://example.com/mycomponent
• Click on the 'Server' tab.
• Click on the 'Debugging' tab.
• Change the dropdown from 'Error' to 'Message'.
• Save.
• Login to your Linux terminal for your system.
• cd /path/to/debug
• You will see the debug logs are populated with new information.

Here is an example of a longer Troubleshooting Runbook.

Scenario

Developer wants to check the health of MyComponent.

Step 1. Setup SSH password-less connection.

• ssh-keygen
• ...

Step 2. Verify the following endpoints are reachable

• ping https://example.com/mycomponent/isAlive
• ...

Step 3. Run diagnostic script

• cd /path/to/diag
• ./diagnostics.py

Step 4. ...

• And so forth

With a couple of these runbooks, you can reduce stress in the team if someone is out for the day. Troubleshooting Runbooks also work as a proxy for the expert themselves. By providing some basic information in a Troubleshooting Runbook, the work can be passed to a more junior member, freeing up capacity for the more senior member. This benefits everyone in the team.

How can I get started with my team?

To get started, adopt your team's current method of documentation. Try not to introduce a new tool that your team is not used to. For example, my team uses Confluence to document everything. When we introduced our Runbook system, we created each Runbook in a Confluence page under the same heading 'Team Runbooks'. Now, our Confluence space looks something like this:

• Team Runbooks
  • Bug Runbook: JIRA-1234 MyComponent crashed under load
  • Bug Runbook: JIRA-9999 MyOtherComponent failed to upgrade
  • Troubleshooting Runbook: MyComponent
  • Process Runbook: How to create a story
  • etc.

It is important you use the easiest method for your team. Software engineers hate documentation because most practices do not encourage quick and easy changes. For your team to be enthuasiastic, pick a method of documentation that is simplest for everyone. Then, once your team gets started and sees that it saves them time and effort, they will be eager to continue. Eventually, the phrase 'Can you create a runbook for that?' will be a regular ask in your team.

Writing = Thinking

If thinking is the art of linking ideas together, then writing is the canvas upon which thoughts are painted. Like any work of art, without a canvas the painting only exists inside the artist's head. Even then, you could debate if it exists at all. In the same way, to engage in deep thought without writing is not only difficult, but impossible. Few people practice deep thinking. You are likely not one of them. Instead of thinking deeply about a topic, you experience quick thoughts in rapid succession which you forget as soon as you are distracted.

A friend once told me he concluded that God is a ridiculous concept after thinking about it for a mere 15 minutes when he was 16 years old. Let's think about this statement for a minute. Imagine that you play the piano. Think of the vast works of piano music. Think of the accomplishments people have achieved in both making and playing the piano. Think of the mastery that is required for piano composition. Now imagine someone comes along and attempts to play the piano for the first time. After failing to play for 15 minutes, they conclude the piano is a bad instrument. That is what my friend did.

Writing requires you to think for much longer than 15 minutes. When you write your thoughts, you do not have the luxury of cowardly casting off difficult opinions as if they were nothing. It is easy to discount opinions you do not understand - this is called a strawman. When you have an unpalatable thought, you can ignore it. For example, think about what it is like to lose your house, become homeless and develop crippling depression. It is difficult to consider for more than a few seconds. When you write about a displeasing idea, you do not get the luxury of changing to more comfortable thoughts. Whether you like it or not, any important idea is uncomfortable to think about. Consider the last political cause you were passionate about. Are you competent enough to argue for the opposition's side? Do you fully understand why people would vote the other way? I doubt you could. I doubt it because it is a strenuous task which takes a lot of mental effort that even sophisticated minds struggle to accomplish.

When you write, you think deeply. And when you think deeply, you discover the great void that is the understanding of yourself and those around you.

Grow Up and Be Informed

Let's face it: you're ignorant. And I'm not pointing fingers - I'm right there with you! You don't really know what to think about most things. You don't know your politics; you have a dismal view of history and you don't even know what higher purpose you believe in. This is where I'm supposed to say, "But it's ok - everyone is the same!" Yes - everyone is the same. But no, it's not ok. It's not ok that you don't know what to think about your local politics. It's unjustifiable that you have no idea of the atrocities of history. And it's inexcusable you don't know what higher purpose you believe in. So, get to work and start to write and think - nobody else will do it for you!

To start, write down what you know on an interesting topic. Do you believe in God? Write down why. Who will you vote for in the next election? Write down why. When you write your thoughts, you identify gaps quickly in your knowledge and can work to fill in those gaps. As you fill the gaps, you become an informed, mature person, capable of attacking lies and defending the values you hold dear. Of course, the alternative is to stay an adult infant. It is a blissful hell many people prefer.

Improve Your Communication

Think of a bad communicator you know. Maybe this is a work colleague or family member. What makes them a bad communicator? They do not speak well. They have poorly constructed sentences. They trip over their words. They are unsure of themselves. They are easily persuaded by an objection. They leave out crucial information. This person has certainly never written down their thoughts. This is because a single thought does not constitute an idea. We cannot think more than a single thought in a given moment. So, when you speak about your thoughts without preparation, you quickly realise it is impossible to get past one or two sentences. When you write, you write as many thoughts as necessary. Once your thoughts are written down, you can join them together in a larger, coherent idea. This enables you to weed out bad ideas. It also helps to highlight interesting or useful ideas. In this way, you develop strong ideas and arguments to defend them.

Let's return to the bad communicator. If they wrote about their ideas and opinions, they would be able to speak more coherently. They would not ramble in tangents. They would be confident. They would be able to defend their ideas against mere objections. Most importantly, they would be able to convince others that their idea is a good one. Effective communication awaits the novice writer.

Increase Your Success

If you can communicate good ideas effectively, people will listen to you and provide you opportunities. The quickest route to any kind of success is convincing people your idea is a good one. If you can write, think, and argue, you are unstoppable. Think about your career for a moment. Your dream job will require an interview process. An interview requires you to make an effective case for your skills. What happens if you do not think deeply about yourself prior to an interview? You ramble about things you don't understand. You don't form coherent arguments to show off your skills. You get distracted by the sound of your own voice. The best way to do well in an interview is to control the topics. You can only control topics if you have formulated and thought them out prior to the interview. The only way to formulate them effective is to write them down.

What if you want to ask for a raise? This requires you to make the case how a raise will benefit both you and the employer. The better your case, the larger a raise you will achieve. In recruitment, a quick way to secure employees who are good at their job is to bump those that write to the top of the hiring list. This isn't to say that the best person for the job is always a writer. I mean that the candidates who write have desirable traits of knowledge, critical thinking, and discipline. These are always ideal characteristics in a job applicant and the recruiter will recognise such. As you can see, the writer has a much better chance to defend and promote him or herself in opportunistic scenarios.

Be Disciplined Instead of Weak

I hated writing in school - it was difficult and, worst of all, I believed it was pointless. I continued to think this into my adult life. As an university student, I even opted into modules simply because I wouldn't have to write an essay. It is an attitude I regret, but one that was instilled in my school years when I was taught to hate writing.

I'm going to guess that you had a similar experience. Writing is mentally draining, onerous, and time consuming. Why then do writers do what they do? There must be something of value to be achieved. Apart from the pleasure of deep thought, writing requires you to carve out time. It requires you to organise your thoughts and ideas. It requires you to communicate each thought in words, phrases, and paragraphs. It requires you to commit to doing a task which you dislike and to fend off pleasures such as Netflix or YouTube. Even hanging up the clothes is preferable to writing! When you write, you encourage discipline. It should go without saying what any of us could accomplish with a little more discipline.

Perfect Your Ideas.

There are two ways your writing can subject your ideas to criticism. Firstly, you are your best critic. A good writer will look for gaps in their ideas. Secondly, if you publish a blog or newspaper article, your ideas are subjected to your viewers' scrutiny. The reactions of your viewers will help you to harmonize and perfect your ideas.

You may ask why you should subject yourself to criticism? You can enrich other people's lives by passing on your wisdom about a passionate topic. One of life's many pleasures is the passing on of information to those hungry to learn it. Furthermore, a unique idea grants you respect and authority over that idea.

The Problem

If you lead a software team, then a significant part of your tasks will involve some sort of bug fixing or support for other teams. In particular, if your team works on a product used by a lot of customers, you can expect to sped 10% or more of your team's time fixing bugs from your customers.

When it comes to bug fixing, your customers expect a high standard from your team, so you should expect the same from them. As part of your team lead duties, you need to look for opportunities to reduce the team's work as much as possible. In my case, I discovered that the team spent longer trying to understand a bug's description than actually fixing it.

A poorly written bug means your team is getting distracted trying to figure out what the bug means instead of fixing it. Distraction leads to context switching leads to frustration leads to slower completion of work. And there are few things more distracting than a badly written bug.

Rather than trying to fix the bug, a lot of time is wasted trying to understand the bug's context and the steps leading up to the incident. In the end, your team practically writes the bad bug themselves!

This was the case for the product I worked on a few years ago. Although the product was relatively mature, there was very little structure around the processes used to make the product better.

A quick search through the bugs history showed poorly written one-liner bugs marked as closed with no explanation or code fix attached. Clearly, the developers were conversing directly with the stakeholders via email and not attaching the information afterwards.

When my team joined the product, the most frustrating part of our days was solving bug tickets which had no useful information attached. Furthermore, we had no method of prioritising our bugs against our current list of tasks - the loudest person won the priority.

After 2 months of this and identifying it as a major pain point in our retros, we decided to fix our bug process.

The Bug Template

Our bug template was revolutionary to our workflow. First of all, by filling in a template, the bug author was required to think about their problem.

What did I do leading up to this?
How could this have happened?

Occasionally, the bug author even figured out the solution by themselves while filling in the template.

Secondly, the bug ticket required some effort to create. A good rule we discovered was if you make it easy for someone to do something, they will do it. In this case, if you make it easy to create bad bugs, then bad bugs will get created.

By putting a list of questions to answer in the template, the author is less inclined to raise trivial questions since it would be quicker to figure it out themselves. Most importantly, you won't be left with some 'critical' bugs that just have a one-liner description.

Bug Logging Template
 
1  OVERVIEW
------------------------------------------------------------
1.1. Technical problem description
------------------------------------------------------------
Give an overview of your problem.

------------------------------------------------------------
1.2. Product impact
------------------------------------------------------------
What part of the product/project/system is this impacting?


------------------------------------------------------------
1.3. Conditions
------------------------------------------------------------
Are there any unique parameters or conditions you think are relevant? 

 
2   AFTER ANALYSIS
------------------------------------------------------------
2.1. Software version
------------------------------------------------------------
  What version of software did you find this in?
 
------------------------------------------------------------
2.2. Steps to Reproduce Fault (**Mandatory**)
------------------------------------------------------------
Please give exact steps on house we can reproduce this issue.
Give specific commands if necessary.
Attach screenshots if necessary.
 
 
------------------------------------------------------------
2.3. Logs
------------------------------------------------------------
Attach relevant log files

 
------------------------------------------------------------
2.4. Frequency of fault
------------------------------------------------------------
When / how often does this occur?

 
------------------------------------------------------------
2.5. Expected result
------------------------------------------------------------
What do you expect should happen?

------------------------------------------------------------
2.6. Actual result
------------------------------------------------------------
What actually happened instead?
 
3   REACTION
------------------------------------------------------------
3.1. System restore
------------------------------------------------------------
Did you take any steps to restore the system?

 
 
------------------------------------------------------------
3.2. Temporary fix / Workaround
------------------------------------------------------------
Did you find a solution or workaround?

Whenever you see a badly written bug, attach the following to the comments section:

"Hi Sam, We need more information to begin working on this quickly. Please fill out this template with relevant details." Then paste in the above template.

Prioritise Your Bugs

As the team lead, each day you should work with your team to identify the highest priority work. If critical bugs are coming in, you may need to down-prioritise other tasks.

I have a general rule I use to decide what to prioritise:

"If it hurts, put it first."

If the ticket is a big customer or is likely to cause your team embarrassment, then get it closed out asap. It is important to keep the pressure off your team as much as possible, so getting painful bugs closed quickly can give them the head space they need.

Furthermore, there is little point in having your team work on edge case bugs that were accidentally found in-house when there are customers shouting for a fix on another bug.

Argue Against the Bug

Before you assign any bug to your team, make sure it is something suitable for your team to work on. Don't confuse a 'loud' bug with a high priority bug. Very often, there are stakeholders that create tickets and need them worked on immediately. Always question the validity of their priority.

Firstly, you don't want to be the 'pushover team' that will hop on tickets when someone shouts loud enough. It is very beneficial to your team if you can disagree against tickets with the hope of either delaying their priority (especially if your have a large backlog) or get it moved to a more relevant team.

To argue against the bug, ask a few simple questions:

• Is this bug for your team?
• Is there enough info for someone to begin working on it?
• What level of expertise is required here (senior / junior)?

By asking some basic questions, your team gets more context to the ticket and can empathise with the ticket author. If the ticket does not already have your template, make sure you attach it and ask the author to fill it out.

Emails are not Bugs!

As the team lead, I am often pulled into an email chain with stakeholders such as QA or customer support teams with questions such as:

• "David - Can you get someone to have a look at these logs?"
• "David - Can we secure someone from your team to look at this?"
• "David - It is critical that we fix this bug by Monday. Who is available to work over the weekend?"

Do not take requests like this. My response is always the same:

• "I'm sure we can help. Please raise a ticket with all relevant details so that we can track this."

Without a ticket, your team don't know where to attach their information or ask more questions. Moreover, if you revisit the bug in the future, without a ticket there is nothing for you to reference.

Transferring a software project (or indeed any project) to your team from another team is a daunting task. For the purpose of this article, let's call the giving teams the "Throwers" and the receiving teams the "Catchers". To transfer a project, the Throwers dump their brains and give their thoughts to the Catchers hoping most of it sticks.

The complexity is compounded the more teams you add to the mix. Most of the time, it is like asking a bunch of toddlers to paint a masterpiece and then getting a different bunch of toddlers to give an analysis of the artwork.

First of all, the Throwers likely don't care too much if the Catchers get it wrong. Even worse, if the Throwers are losing their jobs, as is often the case, then there is a certain level of resentment towards the Catchers.

Secondly, if you manage the project, you have to note down all the tasks, dependencies, edge cases and expertise you can think of and try to extract as much information as possible from the Throwers for each item. This includes code, product architecture, business cases, documentation, bugs, ad hoc expertise, testing...the list goes on. Even if you get the maximum amount of information from the Throwers, it doesn't really matter unless the Catchers absorb the information.

This is the position I was in a few years ago, where a large product involving 10 teams was transferred to my teams. The product came from a different part of the world in a different timezone. I was a product owner at the time.

Here are some lessons I have learned and mistakes we made that might help you if you are in a similar position. The good news is, we eventually got there and the project is now thriving, but it wasn't easy.

We didn't follow all of these suggestions, but I wish we did. We made a lot of mistakes and cost ourselves a lot of weekends and failures.

The rules to transfer a project are as follows:

• 20/80 Theory/Practice Split.
• Define team goals quickly.
• Get a backlog in place.
• Take ownership of the product.
• Brainstorm improvements.
• Keep an expert available for questions.
• Don't take on too much work.

20/80 - Theory/Practice

It is important to understand the ratio between learning something theoretically and learning something practically. In a software project, theory will only go so far.

There is a difference between thinking you understand something and being able to apply it in a practical situation. The same goes for your teams. Very often, your teams will find that theory does not apply to the practical application.

The Throwers are often tempted to make a bunch of slides and online videos detailing how they interpret the system and how they picture the software working. The problem here is while theory is nice to have as a background, it is of zero use if the Catchers do not understand how to apply it. For this reason, I suggest to spend about 1-2 hours max each day in knowledge-sharing sessions. Anything longer and your Catchers will get tired and zone out. The rest of the day should be spent on technical exercises such as writing code, debugging, writing documentation and so forth.

Let's be crystal clear on this. If your teams learn something theoretical and don't immediately put it into practice, then it has been a waste of time. In this early stage of the project, it is critical to value your teams' time as much as possible. Just because they sit at a computer and listen to someone speak does not mean their time is well-utilized.

Define Team Goals

The danger of any kind of team-based learning is that the team are left by themselves to 'transfer knowledge'. From the beginning, goals must be defined. The danger of not having any goals is that the knowledge is endlessly abstracted and taught as if the software it applies to works perfectly.

The goals should be broken down starting at a high level.

• What use cases do you want this team to understand?
• What set of tasks do they need to be able to do on a technical level?
• What questions to you want them to be able to answer?

As you break down the goals further and further, it will become clear where the gaps are. Fill in the gaps with more goals and keep going until you run out of ideas.

Once the goals have been defined, discuss them with the team and get their feedback - they may have a better idea on what they need to learn.

Backlog, Backlog, Backlog

Once the high level goals have been defined and you have discussed them with the Catchers, it's time to get the team focused. This is where the backlog of tasks comes in.

The Catchers will want to break down the high level goals so that they can identify their knowledge gaps and raise questions quickly with the Throwers. The onus for learning the project is not on the managers of the project, it is on the team. The team will be the ones developing features, solving bugs and answering questions. They need to hone their skills going forward, and that comes from the backlog.

It is tempting not to create a backlog until the project has been transferred and the teams feel 'ready' to start developing features. This is a mistake. The team need to create velocity and work as a team on the project from the beginning. The team lead or scrum master should keep a focus on the backlog so that the team can have small, manageable goals each sprint and start moving towards an ownership of the project.

Take ownership of the project

High performing teams always have ownership of a product or a subarea of that product. It is important for your team to feel they have ownership over the product as quickly as possible. This will make them feel responsible for the product and give them purpose in their daily work.

Teams take ownership by carving out responsibilities for the product.
When defining the team goals and backlog, group work into categories. Once the work is somewhat categorized, it is a good idea to assign a category of work to a single team if possible. This way, the team will get that 'feeling' they have an area of responsibility.

I have seen teams that struggle to secure a place of responsibility in the product. This decreases morale and you will hear it turn up as an issue at the retrospectives. Things like "We don't know our what we are responsible for" or "What is our team vision?" repeatedly get said. This is normal to hear at the start of transferring the product, but you should move to rectify it quickly.

Think about this when you assign the team features and backlog. If you assign a team tasks that are not related to each other, it will confuse them as to what the long term goals are and what they should concentrate on owning. By assigning tasks that are in a similar category, the team can deepen their knowledge in a particular area.

Sometimes you can directly assign an area of responsibility to a team. Here are some examples of use cases a team could be easily assigned.

• Ensure our product installs successfully.
• Develop all future features related to login.
• Develop pipelines to automatically test the product each night.

Once an area of responsibility has been established, the team can make themselves experts for their responsibility. Having at least one area of expertise (most teams have multiple) gives the team a sense of ownership over the product and purpose. This helps to gel together as a team.

Brainstorm Improvements

No software is perfect. Your teams will realise this straight away, while some more outspoken persons will comment exclusively on the quality of the software they are receiving. Hopefully, it's not as bad as everyone says!

A fun way of learning about the product is to brainstorm improvements for the difficulties your teams encounter. Very often, the Catchers find improvements that have been discussed by the Throwers. The Throwers can give the Catchers quick feedback on their ideas and whether or not it is worthwhile to improve.

Since the Catchers are a brand new team to the product, they will also find improvements to difficult problems that nobody has touched before. In particular, if the project has been under a lot of pressure for deadlines, then there will be a lot of technical debt and rushed code. The Catchers should take notes as they go through the project and keep a backlog of improvement ideas they can return to in the near future.

If capacity is available, the Catchers can even begin to work on some of these improvements. Making the product better is always a bonus, even if the improvements are small.

Fix bugs

In my opinion, this is the quickest way to learn the new product. Code is always best learned by solving practical problems. As the team work together through the problem, they will encounter pieces of code that will not make sense to them. They can record these difficulties and bring them up with the Throwers.

Once the team are aware of their responsibilities, they should research the most relevant bugs in their responsible area. Imagine having a document of problems and solutions you could search through to find answers to your questions. This is what a bug backlog does.

As an exercise, the Catchers could take some sample bugs from historic tickets and work them out themselves. If they get stuck, the answer is (or should be) in the ticket.

Keep an expert available for questions

This is crucial to a smooth transfer. As part of any project transfer, there must be a gradual period of transfer. During this period of transfer, the teams do what we have gone through above. At any point, the Catchers could have questions and ideas that need feedback from someone who understands the software. This means that the project experts should be kept on hand for questions and support.

Ideally, an expert should be kept on as long as possible. As the catchers take ownership of the product, they will find that there will always be unknowns. This is ok - it's part of transferring a product, so don't worry.

Your team needs to develop a baseline knowledge so that they have the tools to figure out the rest of the unknowns. Until this baseline knowledge is achieved, it is good to have someone close by.

Don't take on too much

A danger of transferring tasks to your team is that the team takes on too much work. You don't want to set yourselves up to fail. Ensure that whatever you take on is manageable. If you don't know, then don't agree!

My team were in charge of a particular area during the product transfer. We were given a large responsibility to make sure a particular part of the application stays functional each release.

As it turns out, this part of the product never worked properly in the first place. We didn't have the environments available to troubleshoot and our feedback loop for any single line of code was about 1 day. In the end, we failed our responsibility and the product couldn't be released that same quarter.

So be careful what you take on - don't let management force work that is not manageable onto your teams. The Catchers are new to this - it will take time to get settled so don't rush into it!

Leading a team is difficult - it's why people love or hate the job. Where a team member incorporates themselves into the people and culture around them, the team lead drives that assimilation and culture. They must understand that each person has a different personality, and therefore each team culture is different.

If this wasn't enough of a challenge, team leaders need to handle difficult members of their team. In my opinion, this is the most challenging part of the job. A team member who acts in a way that is destructive to their team them means your team suffers. In the medium to long term, if the team keeps suffering, then you have ultimately failed as the team lead.

Fortunately, there are methods and techniques to manage such people. However, it is not a simple or pleasant task. Effectively managing difficult people comes with knowledge and practice. Expect to make a few mistakes along the way. Keep the goal clear in your mind - to develop a high performing team. If you reflect on it, then you will make better judgements when it comes to difficult scenarios in your team.

Below are some of the scenarios I have come across and how I think they should be dealt with.

Proud Seniors

Every team has at least one or more seniors on the team. Let's call him Rob. Rob's role is to lead the team in a technical manner and make intelligent and informed decisions for the team while coaching less experienced members. Above all, Rob sets a standard for the team and makes sure the standard is upheld.

As Uncle Ben said, 'With great power, comes great responsibility'. When a leader within the team abuses their position, or does not know how to deal effectively with others, then it can damage other members of the team.

I have often seen Rob act inappropriately towards his team. Sometimes Rob is loud and outspoken and happy to talk over the more junior members of the team. Rob's opinions are often the only ones heard, while he snaps or condescends other opinions. This can be a natural response -  Rob feels like he has the best opinion because he is most experienced. As a result, any challenge is personal.

In a high performing team, each individual must be comfortable to speak out and voice their opinions without judgement. Even juniors who have little experience often give valuable insight into the simple things that the rest of the team have become accustomed to. You need to work to allow Rob's experience to come through in decision making, while making sure everyone on the team is comfortable voicing their opinions.

Resolution

Remember - your goal is to develop a high performing team. In the above scenario the relationship between Rob and the rest of the team is broken. So the question is, how do we repair and maintain that relationship?

In my experience, having Rob work closely with everyone else on the team is the quickest way to mend the relationships. Rather than assigning tasks to Rob and have him work by himself, assign the task to a more junior member and get Rob to oversee it. In this way, Rob will be forced to work on his communication and develop an understanding with the rest of the team.

Over time relationships grow stronger and the more junior team members voice their opinions more often since they are now more comfortable speaking with Rob. Even if Rob's attitude does not soften, at the very least everyone will know his personality well enough to be comfortable challenging it.

Too many egos spoil the broth

Working on a team with one Rob is challenging. A team with multiple Robs can be nearly impossible to handle at times. I have not worked directly on such a team, but I have experienced it by proxy in my managerial days when I had meetings with individual teams.

The most common place egos clash is in the beginning, when the team is being formed. The four team stages of team formation are commonly known as "Forming, Storming, Norming, Performing". (ref https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development ). When a team begins to form, people aren't really sure what position they have in the 'hierarchy' of the team. They're not sure what kind of personalities surround them or each other's backgrounds.

Once the team have been 'formed', in other words, once they recognise who will be on their team going forward, then they enter the 'storming' phase. This is the phase where team members challenge each other and voice their opinions. This is also the phase that is most painful for the team lead.

As the team try to familiarise themselves with the other team members, they spark and argue with ideas other team members put forward. This is amplified further in job sectors with a high competition - software for example. Each individual on the team wants to be correct and will stand by their views no matter what.

Resolution

Don't worry! This is a natural part of the team's journey and it will pass.

Once your team gets to know each other, egos will settle down and your team will enter the 'norming' phase where they get comfortable with each other and begin working as a team towards the common goal.

In the meantime, it is an opportunity for you to practice conflict resolution. Ever wonder what it would be like to be a politician? Here's your chance!

If you find that the team are still not settling in with each other, then it might be time to bring in some team practices in order to make decisions and resolve their arguing. You need to discuss this directly with the team (at a retro is a good time) and brainstorm some ways to achieve decisions.

Some ideas for achieving resolutions is to take a team vote, refer to an external expert (if one exists), lay out the pros and cons of the arguments, or refer to the technical lead within the team.

Unproductive Members

In any industry and on any team, there are some people who are highly productive and driven, and others who are the polar opposite. I once discovered someone who, hired as a software developer, had merged about 5 commits in the few years they worked in that company. In total, their code contribution amounted to a maximum of 100 lines of code. Let's call this person Mike.

The Mikes of the world are lazy, unproductive and always have an excuse why their tasks are not completed. Believe it or not, Mike could be the most dangerous and destructive person on your team. All your other team members look at Mike and see the lack of focus and output coming from him. When a difficult job comes, they wonder why they should be bothered to do a good job if Mike is getting away with doing nothing.

Furthermore, Mike brings down the team moral. He is taking up a space which could be filled by a worthwhile and valuable team member. A brand new junior just out of college is far more valuable than Mike. At least a junior is willing to work their way up the ladder and assimilate into the team. Mike has no such goals.

Resolution

How do we deal with someone like Mike? Believe it or not, Mike's problem may not be his lack of knowledge - it is his lack of accountability. Mike has gotten into the habit of working the minimal amount and discovered that by working poorly and making excuses, he can reduce his work load and take it easy.

So the question is - how to increase Mike's accountability? It's quite simple - don't let Mike work by himself!

Remember how Mike made just 5 commits at his company over a couple of years? What do you think the scrum master did? He continued to assign small tasks to Mike and leave him by himself without anyone working him. Mike had no accountability to his team, so he didn't hold himself accountable. To this day, Mike is known for doing the smallest amount of work, and nobody wants to work with him.

As team lead, you can fix this surprisingly quickly. Team Mike up with one of the more productive members (Vicky) who can guide Mike and hold him accountable. Vicky can support Mike in working on his tasks in a 'pair-programming' manner. This will prevent Mike from skipping off for a few hours or getting distracted easily.

For each of Mike's tasks, ensure that he is not working by himself - always pair him with someone else. You might think that this is a waste of Vicky's time. In the short term, this may be true. But in the long term, Mike will develop a discipline and become more productive by himself. He will gradually gain back the trust of the team and hold himself to the same accountability as the rest of the team. Over the long term, the team will benefit greatly from having the extra productive team member.

Side note: There is an argument to be made that nobody in the team should work by themselves, but that's for a different post.

Just..not...interested

In any team, there are jobs that nobody wants to do. Documentation, bugs, support, admin, testing...the list goes on. As the team lead, it should be one of your focuses to provide each team member with a balanced workload according to their skill set.

Notice how I didn't say that everyone should have an equal workload - that is a bad tactic for a high performing team. As a quick example, juniors learn quickest by getting involved in some of the boring work (testing, documentation). Whereas seniors are kept interested by removing this work from them as much as possible.

Resolution

Each person on the team needs work that is challenging according to their expertise. If one of your team says they are bored of their work, ask them politely what they find boring or tedious. Then work on speeding up the completion of that work and get them onto something they would rather do.

Look back over their previous tasks. Have they been assigned work on numerous occasions that does not challenge them? Can this type of work be shared or shifted to a more junior member? Make a note that their work needs to be more varied in the future.

Unprofessional Team Member

I find this the worst problem to have on the team. It is one thing to be unproductive or difficult to talk to, but acting unprofessionally is the most obvious and painful characteristic someone can have. Let's call our unprofessional team member John.

'Unprofessional' is a catch-all category. There are many ways John can be unprofessional. Snarky, tardy, insulting, offensive, rude..the list goes on.

John is difficult to have at meetings, especially with people external to the team. He says things on a whim without thinking about them and often insults or speaks out of turn. Sometimes, he is downright insulting.

Resolution

Since you are the team lead, it is difficult (and unadvised) for you to single out John and request that he acts more professionally. If John feels insulted, you have done a disservice to your team and damaged a valuable relationship with one of your team members.

The best thing to do is bite your tongue for now, and have a chat with the manager in charge of personnel. This could be a HR manager or more often a line manager. Frame your conversation as a 'concern' rather than a complaint. "I think John could improve his attitude in meetings by doing x".

The danger in dealing with an unprofessional team member yourself is that it could backfire on you and John could complain about you, or you could lose your cool and become unprofessional yourself.

In my case, I have a sharp temper (which regularly gets tested), so when I hear a statement that is completely out of line, I bit my tongue and either ignore it, or if it is interfering with the team's work and progress, make a note and discuss with my line manager at our monthly catchup meeting.

The worst thing I could do in these situations is to snap back. Although I may be in the right and the other person in the wrong, it is too dangerous that I say something damaging which could affect the team as a whole.

Is it unfair your team is constantly called for weekend work?
Are your team members complaining that they have no social life anymore?
Are they threatening to leave if something does not change?

The good news is, there are many scenarios where you can reduce or remove the need for your team in their downtime. First, you need to understand why you team is being called for weekend work. Let's go through a few reasons and how we might prevent them from happening.

Reasons For Weekend Work

Site Outages

A Class A, highest priority ticket has come in on Friday evening as everyone is preparing to leave - a customer's site has crashed. Your team must drop everything (including their social plans) to get online and come up with a solution.

After working all night Friday and half of Saturday, your team puts in a fix and calls it a day. But they are not happy - their weekend with their family and friends has been cancelled, and they wonder if the job is worth these weekend calls.

Prevent Site Outages

After the issue has been resolved, take a whiteboard or pen and paper and answer these questions.

• What did the user experience? For example, did they receive an alarm, get a 500 response error, etc.?
• Why did the site go down?
• Did something like this happen before?
• Who was involved / what expertise was required?
• How can we prevent this from happening ever again?

Once you have these answered, put a plan in place to mitigate this issue happening ever again. Sometimes, it can be as simple as adding a new test case. Other times it may be more complicated and involve setting up new test environments. Look at the cost/reward of fixing it going forward and make a decision.

Late Release Work

The release deadline fast approaches. There is only a few days left until the software is released. Everything is late, and your team are under pressure to deliver.

One of the tasks your team was working on is blocked because the environment was down the past two days. Now the environment is up, but management has requested the task be worked on over the weekend and completed by Monday morning.

Prevent Late Release Work

All teams understand the pressure of having features that are late and in danger of not making the deadline.
To prevent late delivery of features, here are a list of DON'Ts you can apply.

• Don't underestimate the work. Always take your final estimate and add an extra 20% onto it.
• Don't plan optimistically. Assume that things will go wrong, other teams will be late, code will break. In Ireland, there is a phrase "It'll be grand", meaning that everything will work itself out. It won't be grand. Nothing will work itself out. Plan accordingly.
• Don't promise delivery dates that are not feasible. Pressure from management may tempt you to do this. Do not give in. Have data to backup your claims.
• Don't promise delivery dates without doing your homework and gathering as much data as possible. List out as many tasks as possible and estimate each of them. What are your risks? How could your risks affect the delivery date? Are the risks low, medium or high?
• Don't hide problems from your manager during the release. Is a task going to be late? Tell your manager asap and show what you are doing to mitigate it.

An experienced team lead will have this list off by heart without even realising it. Have you got more Don'ts you have learned the hard way? Comment them below.

Late Sprint Work

This depends on your team. There are teams that are not strict on their sprint commitments, and there are other teams which require themselves to work weekends if the work is not ready to deliver.

Prevent Late Sprint Work

Late sprint work usually comes down to poor sprint planning in the first place.

• Did your sprint planning cover this task sufficiently?
• Why did the team underestimate this task in their planning?
• What can you take from this going forward to ensure future similar tasks are estimated more accurately?

Effective sprint planning is difficult, but is worth it to get the team in the habit of delivering their committed work.

Supporting Other Teams

If you are leading a high performing team, then more than likely you will have at least one or more persons who act as experts or specialists in a particular area. This is great for your team...most of the time.

A downside of being an expert is you get called up for consultation on things you were not even involved in. You could be called into an escalation because another team is behind in their commitments. I have often seen specialists called into very tricky situations like performance test failures, where an application is failing at scale and nobody knows why. Scenarios like this are dangerous for experts, because it could bleed your evening and weekends dry.

Prevent Supporting Other Teams

The title here seems unprofessional. Experts are there to act as experts, right?

This may be true, but the fact is that even experts don't like getting called on a Friday evening or Saturday morning and asked to go online. As the team lead, it is your job to protect your team as much as possible in their downtime, so that they can focus more effectively during working hours.

There is a host of reasons your team expert could be called into work unexpectedly. Work with your team to brainstorm how to reduce the need for being called to unplanned work. Here are some suggestions.

• Train a member from the other team in some debugging techniques for the particular area of expertise.
• Document troubleshooting procedures for various scenarios. Share this document with the organisation.
• If a call comes in, brainstorm some possible solutions for the caller to explore. There may not be a need for you to be online. Give enough information that they can proceed with troubleshooting.

As the team lead, your goal is to keep everyone happy as much as possible. Can you prevent the team from being called in the first place by preparing in advance during working hours? Discuss the above with the experts in your team and get a plan together to protect their weekends.

Dealing With Necessary Weekend Work

Sometimes weekend work is absolutely necessary - there is no way around it. That bug isn't fixing itself and the release date isn't moving, so your team is left with no choice.

Now your job as team lead is to reduce the team's pain as much as possible. Here are some suggestions for reducing this pain.

• Instead of John working Saturday and Sunday, can John work Saturday and Jess work Sunday?
• Challenge the work that is requested. Can some part of it can be investigated on Monday instead of now?
• Develop a rota for the next 4-8 weekends so that your team can plan in advance that they might need to be online. This will also prevent last minute requests to your team members and ruining their weekend plans.
• Is there a support team that could take some of the requested work? In my case, I discovered a 'secret' team that were setup specifically to support internal stakeholder escalations, yet my team had been supporting these cases for the past few months. Nowadays, any time an internal stakeholder asks my team directly for support, I forward their email to the dedicated support team. They're happy, I'm happy, and my team are none the wiser that I have protected their evening and weekend.
• Work smart, not hard. Most likely, your team do not need to be online 24/7. If so, propose time slots that your team will be online to check emails and answer requests. For example, when my team are asked to be online over the weekend 'just in case' something goes wrong, I insist that we give a list of times where we will be online and contactable. In general, the time slots are 10-11am and 3-4pm. Outside of these times, my team can relax and go about their day.

If all else fails and someone has to be online to support a problem, make sure they are not working alone. Any work is painful when it is done alone, and weekend work it is 10 times worse. It may be you that needs to make the sacrifice and go online to brainstorm ideas and support in the troubleshooting. They will be secretly grateful for your company, and won't feel the weight of the world on their shoulders.

TL;DR

• Subliminally Standoffish - Don't be difficult to approach with problems.
• Micro-manager - Don't be a tyrant on your team.
• The Libertarian - Don't give your team unlimited freedom.
• Defender of the Poor - Don't defend your team from every criticism.
• Team Grouch - Don't complain.

Subliminally Standoffish

What is it?

A standoffish person is someone who is difficult to approach with a problem. If you, as a team lead, are disagreeable to your team members coming with their problems, then it will cost you in the long run.

Why it's bad.

Problems left unsolved will bite you and your team. Leaving something on the long finger will cost time, effort, money and sometimes even weekends.

A backlog of problems that are not getting resolved and that you are not interested in listening to will ultimately make the team unhappy. To have a team lead who is unapproachable is the same, sometimes worse, as not having any team lead at all.

How to avoid.

Listen to your team, both as a group and individually. If you hear someone complain about the same thing again and again, sit with them to discuss a solution.

If someone raises a problem that needs some thought at your standup, ask them to stay for 5 mins after the standup is finished. Discuss possible solutions with them.

As the team lead, the responsibility is on you to have at least a plan to fix the problem. If a new recruit is struggling with their work, pair them up with another team member who can coach them through the problem.

Sometimes, you may need to step up to the mark and lead the solution yourself. The team respects you - that respect should be commanded and used in high priority scenarios.

For example, a few ago a critical bug came into our team from a performance test. After a few hours of the team going through different scenarios, it was clear that some direction and leadership was needed.

I helped the team split up the possible solutions, and assigned each solution to 2 or 3 team members. I then stayed with the solution most likely to give an outcome. In this way, we covered more ground and found a solution much quicker than if I had left the team to their own devices.

Examples and signs.

How many problems have your team reported to you recently? If the answer is none, then either you have a perfect team (which doesn't exist), or they are not willing to raise their problems with you. Maybe they feel you don't care enough about solving their problems.

If the team are requesting support often, and asking your opinion, then you know you are on the right track.

Tricky part

If you have a history of being standoffish or snappy, it will take time for your team to trust you again. Take it one day at a time - say specifically that you want to hear more of their problems. Encourage expressing problems at retros and stand-ups in particular - this is where the team are ready to help out each other.

Micro-manager

What is it?

Control - lots of it, all of the time. Control over individuals tasks, control over bugs, control over work hours...

A micro-manager will ask for more than frequent updates and pick at anything that they think is incorrect or unproductive. They will call for unnecessary updates to make sure every detail reported is on track.

Why it's bad.

A common misconception is that micromanaging is always bad. It's not. Sometimes it is absolutely necessary. A poor worker who is untrustworthy needs to be micromanaged. Anybody who cannot abide by a professional working structure needs a low level of management.

Having said that, the majority of your team will not have this problem (if they do, you're in for a rough time). When someone feels micromanaged, they feel not trusted to do their work. As the team lead, if you micromanager your team, it indicates you do not trust them to get their work done.

I once witnessed a team lead chase down a colleague who took regular coffee breaks. She then proceeded to scold him in the hall. This behaviour will  not lead to a good working environment.

How to avoid.

If someone is not pulling their weight, bring it up in a team context. If Patrick is not acting professionally, ask the team - "What can we do to help out Patrick here? Alex - can you join him this morning to try and help progress with his story? Patrick - can you update the team on your progress at the end of the day?"

In this way, you are not singling out Patrick, so he does not feel intimidated. But you are letting him know that the team sees a problem with how he is progressing.

Examples and signs.

You are constantly correcting and asking information from the the same individual again and again, more so than any other team member. A team member is getting frustrated at giving you so many updates and being told how to work.

Tricky part.

Micro-managing can be necessary. You need to balance between effective updates in a team setting while giving the freedom to work effectively.

The Libertarian

What is it?

The right to do whatever you want, maximum freedom and autonomy, little to no updates on progress at standups, and no structure on the team as a whole.

While the libertarian philosophy is ideal when talking about government and how one should live their life, it is not a good idea to allow your team absolute freedom in how they work.

Why it's bad.

Effective teams require structure and rules. You must help the team enforce those rules upon themselves. Remember, they are team rules, not yours. You are not a tyrant. A team without structure will perform poorly and get easily distracted.

How to avoid.

Encourage the rules within the team. Encourage effective updates in the standups. Ask questions and critique assumptions to encourage people to speak out.

Example and signs.

I met an old colleague of mine after he moved jobs into another software developer role at a bank. I asked him how things were going. He said it was fantastic.

His team didn't have to turn up to work by any set time. They could have their standup remotely from home and come in later on if they wanted. They didn't practice any of those 'nasty' scrum processes. Instead, they worked in an individual Kanban fashion and could take and leave tasks as they wanted. Needless to say, he was on the hunt for another job within 6 months, and the same bank made headlines for some data breach.

The above is an extreme case of 'anything goes' and on a macro scale. When it comes to your team, if you see tasks slipping, team members being absent from team meetings or complaints coming in from different team members about other team members then it might be time to revisit the rules within the team.

Tricky part.

A good team needs freedom to move. Your job is to help enforce the rules that provide that freedom. Each team will share a common rule set (eg. scrum), but certain teams require additional rules to pull together as a working unit. Your job is to figure out where the freedoms are taken advantage of and to suggest more structure.

In Defense of the Poor

What is it?

Whether you are an experienced or inexperienced team lead, you will come across colleagues that just don't want to be there. As the team lead, part of your job is to show off the team. You do this via demos, planning meetings, retrospectives etc. However, we must not confuse showing off the team with blindly defending the team at all costs. Avoid defending a bad decision made by the team or an individual in the team.

Why it's bad.

I have witnessed a few cases where a team lead was adamant that a weaker member of his team did not make a mistake. He seemed to think that by 'team lead', his job title included justifying every bad action made by his team. 

By defending the team's bad practices or habits, you damage their productivity. In particular, if a team member is consistently making bad judgements, do not defend them beyond doubt. Teams learn as individuals learn - they need to make mistakes to progress. By not admitting to mistakes and working to fix them, the team is damaged long term.

Furthermore, anyone who scratches beneath the surface of the team will quickly see the fault lines. Most importantly for you, it displays you are an incapable team lead. Your job is not to be 'nice' towards your team. It is to create an effective and high performing team.

How to avoid.

Avoid 'defending the poor' in the first place. Each individual should practice being accountable towards their team. Encourage the team to correct each other at stand-ups and other team meetings. Ask questions like  "What should we have done to avoid this mistake?".

If the issue persists, particularly with individuals who are consistently making mistakes, you may need to consult with your line manager. Sometimes it is simply the case that certain people are not fit for the team or the line of work.

If you do have a weak link in the team and you are asked to explain to an external colleague (eg. manager), respond with something like:

We recognise this is an issue - we have taken a retro internally and are working on a plan to fix it.

Remember - don't mention individuals. The team made the mistake, so you must express the mistake as a whole, not on an individual basis.

Examples & Signs

Gary has been arriving late to meetings and is merging faulty and untested code into the master branch. Your manager asked you what you were doing about it. You defended your team's pride saying that Gary turns up to all team meetings and is an excellent worker and team player. Your manager walks away unconvinced.

Notice how you have not solved the problem - you have essentially said "I don't want to know about it". Your manager won't thank you for that.

Tricky part

Very often, bad performers need to be called out. But you are the team lead so it is not up to you to call them out. Be socially intelligent enough to get the team to critique themselves and each other. This comes with practice so start now!

Team Grouch

What is it?

Everyone knows this guy. Sometimes there are a few of them. They love to complain and moan about every existing problem and every non-existing problem they can think of. They complain about management, about other teams (even their own team!), about their difficult life and so on.

In a work environment, it is bad enough to have co-workers who complain.
But as the team lead, it is not acceptable for you to complain.

Why it's bad.

Complaining displays weakness as a leader. Let's be clear here - when I say don't  'complain', I do not mean you should not recognise problems. The issue is when problems are raised for the sake of raising them. Then it becomes fruitless whining. Complaining is a childish quality and so leaders should never complain. Since you are in a position of leadership, either figure out a solution or keep quiet.

How to avoid.

Ensure any problems you raise are followed up with a potential solution. Stating problems without solutions are of no use to anyone. Finding solutions to problems is why you are in your position.

Sometimes you need to let loose to your colleagues. That's ok - we're all human. Just make sure these occurrences are rare and far between. Even if a team member is complaining, don't join in with them. Instead ask "How can we fix that?". Complaining is often used as a common ground to be friendly with others. Unfortunately, you cannot have this luxury. Find other ways of being friendly!

Examples and signs.

At the team standup this morning, John complained about the QA team lead saying they don't know anything about debugging the backend. You joined in saying "Yeah John, I've had problems with that guy too in the past".

Instead, you should have said "Ok John - can you think of any way to fix this? Would you be able to give the QA guy your debugging cheat sheet?"

Tricky part.

Not complaining is difficult. We like to let off some steam every now and again. But you represent the team and so must rise above it. If you see a problem but cannot figure out a solution, ask for help to find one. As long as you are seen to seek solutions to problems, you won't come off as the team grouch.

In the last couple of months since Ireland announced the lockdown, our team has been performing at a high pace and have become self-organised to a large extent. As a team lead, this has allowed me the privilege of stepping back to look at the broader picture of how our team works individually and, more importantly, together. Through some exercises, I have identified some methods to gather improvement ideas that can be applied to any team.

Anyone who has been a part of a high functioning team understands that continuous improvement is not optional. In order to perform better and to keep performing, the team must identify their weaknesses and plan to strengthen or mitigate those weaknesses. These improvements remedy stress points in the team, technical debt, repetitive tasks and so forth. The mindset of continuous growth is one that must be worked on and nurtured over time. Your team is not a fine wine - it will not improve if left alone in the corner. It will go sour.

It is one thing to be told to improve something. But very often, being told to improve something does not necessarily benefit you or your team. For example, if my manager comes to me and tells me my communication is poor and he wants bi-weekly emails from now on from my team's status, all he has done is improve one of his problems, not mine. Improvements must come from within the team, and they must be gathered and executed on regularly. So the question is - how do we gather improvements that are worthwhile and specific enough to solve our problems, not someone else's?

80/20 Analysis

The Pareto Principle, most commonly known as the 80/20 rule, states that about 80% of the effects come from 20% of the causes. In layman's terms, most of the good things your team is known for doing likely comes from a small subset of your total work.

In my case, my team is known for our expertise in the upgrading of our product. How much of our work is related to this each week? I'd estimate less than 10%.

S_ide note_: This wasn't always the case. When we first formed as a team, we spent about 90% of our time on this work.

Over time our mindset of continuous improvement led us to automating away most of our problems. Here is how you can utilize the 80/20 rule to find pressure points to improve. I do this regularly by myself, and occasionally with my team.

Create a chart.

Drawing on a piece of paper or whiteboard produces far more ideas than typing on a screen. So create a chart!

What is going poorly?

Always start with the bad. What makes you stressed on a Monday? Why does your team constantly get called for customer escalations on a Sunday? What makes you cry at night? (If you're crying at night you really need this).

Copy the following table onto a piece of paper and fill it out now with any ideas you have.

What is going well?

This is less effective than analyzing what is poor in the team. You should prioritise fixing the bad over improving the good. There is no point in improving what your team is already good at if there are still issues that stress them.

Ask yourself - what are your team doing well? What do you need to keep doing well? What would happen if you improved these items?

Again, copy the following table onto a piece of paper and fill it out.

You see the action columns? Take those, discuss with the team whether they agree on the actions required, and put them clearly for all to see everyday. You could create a task in your backlog that gets seen everyday on your sprint board, or print them and place them in your team's area.

Preventative Actions

Identifying Preventative Actions is something that I have recently come across. Each team in my project go through this process every 3 weeks (every sprint). Here's how it works.

A high priority bug has come into your team. You have spent all weekend pouring over it with your team, and finally came up with a solution late Sunday night, allowing your customer to continue their business as usual. Before you close the bug, there are a couple of things you need to consider and you must get answers to them. Otherwise, there will be another weekend in the future that will interrupt your team.

Why did this bug occur?

• We received a bad requirement specification from our business analysts.
• We missed a corner case in our testware.
• There were too many manual steps in the documentation which led to human error.
• We missed a critical part of our study when planning the requirement.

What correction did you apply?

• We built a patch fix and sent it to the customer.
• We clarified with the customer that the particular use case reported is not supported yet.

How will you prevent this type of issue from occurring in the future?

• We will call a 1 hour meeting with our business analyst each week to plan and clarify the feature request.
• We will build a new pipeline that will test our customer's use case each night.
• We will automate steps x,y and z in our documentation so that human error is reduced.

In my team's case, for each bug we have the following grid which we fill out.

Retrospective

If your team uses the scrum framework for their work, then you will be very familiar with the retrospective. However, you do not need to work in a scrum environment to have a team retrospective.

Team retrospectives, if taken regularly, can be a valuable tool in the team's work week and is an opportunity for the team to come together and discuss the good and bad things that have happened in the past few weeks.

A retro should be scheduled on a regular basis, and you as the team lead must lead the meeting. Make sure that everyone from the team is present for the retro, and ensure that everyone is taking part and answering the questions.

What was good that you need to keep doing?

• We closed out 100% of our stories for the sprint.
• There was good communication with our management.
• We trialed pair programming this sprint - we have seen excellent results and should continue to do this.

What was bad?

• We had poor communication within the team.
  • Improvement: We will trial pair programming for a sprint.
• The QA team raised tickets with very little detail resulting in a few days of delay in closing.
  • Improvement: Create a template that you would find helpful and send it to the QA team lead. Request that they copy this template and fill it out for all future tickets.
• We allowed untested code into the production software.
  • Improvement: Revise the +2 code review criteria with the team.

The most important part of the retro is to make sure that improvements or solutions are attached to each 'bad' item that is discussed.
At the end of the retro, prioritise the top one or two improvements, and take note of them for the upcoming sprint to execute.

Improvement Backlog

To become a top performing team, each individual must be comfortable with raising and discussing improvements as part of the team's responsibilities. A team that does not have improvement ideas is a team that is not interested in improving which will lead to stagnation and a low performing team.

An improvement backlog is a list of ideas maintained and prioritised by the team. The list can be physical, like stickies on a whiteboard, or digital, like part of your jira backlog.

For example, my team created a Jira sprint and named it 'Improvement Ideas'. We have list about 50 improvement ideas, most of which are one-liners and some of which have been discussed with details and acceptance criteria attached.

Each sprint planning, we prioritise this list and take the items we feel are most valuable to us. We have a couple of ad-hoc rules for this backlog.

• Any ideas that come up in meetings are inserted as a 'one-liners' in this backlog.
• The list is regularly prioritised each sprint.
• Each idea is explained by the team member who originally raised it.
• We take 10-20% of our sprint capacity for improvements.

Keeping this backlog up to date and prioritised will ensure that your team has consistent tasks to work on that primarily help the team.

Stakeholder Feedback

Working in a team can often be like working in a bubble. It is tempting to fall into confirmation bias. The most valuable improvements you can get for your product will come from your customers and stakeholders.

Leading the team does not only include leading the people on the team. If your team are known for building the wrong thing, or if their customers are not satisfied with their part of the product, then you as the team lead have ultimately failed.

When it comes to feedback, there is nothing more valuable than your own customers' feedback. Your customers drive your product backlog. If you are in a large company, you may not have direct contact with your customers. In big companies, customers are often separated by layers of business analysts and management. This is not ideal, but it is something you can work around.

All you need is a small list of stakeholders that consistently use your product area to gain feedback from them. Talk to your managers about the customer interface and who could give feedback. In my case, we were 6 months without any contact with stakeholders that could give us valuable feedback. Eventually we were able to make friends with two guys who act as an interface to one of our company's top customers. To get those contacts, we needed to follow the breadcrumbs, bypassing the Product Owner and manager.

This stakeholder's feedback shed light on areas for improvement that we had not even considered before. Furthermore, they were able to give valuable feedback for improvement ideas we had in our backlog and help us prioritise.

It should be possible to get at least one or two stakeholders as a personal contact. Setup regular meetings with them and take note of their feedback, in particular their problems and stresses.

Feed this feedback into your improvement backlog and make them a high priority to implement as soon as possible.

Conclusion

The above techniques have helped my team and I gather valuable feedback and improvement ideas from both internal and external stakeholders. In using these techniques effectively, your team will improve dramatically and increase their performance.

Remember, it is not enough for your team to do the work they are asked to do. It is not enough to wait to be told what needs to improve. A high performing team must churn ideas continuously and critique themselves. Improvement ideas must come from every part of the team, since every part of the team has a role to play.

In a future post, we will explore how to get individuals of a team involved in forming ideas. For now, take a workshop, brainstorm on a whiteboard and keep executing.

When we talk about teams, particularly teams in an engineering context, it is very easy to fall into the habit of viewing the team as a single leader with everyone else. This is dangerously misguided. A team should not operate as a dictatorship with the team lead telling everyone what to do and they simply follow.

Rather, we should consider the team as a car. Each individual within the team is a part of the car which has a particular purpose. We have the wheels, the engine, the body and so forth. Each part of the car is just as important as the other parts, since without any one of the single parts, there would be no car. In the same way, each team member has a unique place in the team. To replace anyone with someone else means you replace the team as a whole.

If each person has a particular place of responsibility, this means that each person must lead their responsibility. As a result, what we have in a team is not a group of interchangeable individuals, but a group of leaders, each of whom have a particular responsibility to lead.

A lot of team members don't realise this simple fact. Whether you are someone who doesn't see how important it is to lead your team from within, or if you are someone who is looking for ways to lead your team from within, you should be able to pick up some wisdom in the following paragraphs.

Be Proactive

Has your manager sent a poorly worded email to your team's distribution list without any actions attached to it? Trust me when I say your team lead hates these kinds of emails. It's one of those emails where you say "So what??" after reading it.

Rather than leaving it to your team lead to figure out, take it upon yourself to respond back and ask your manager to clarify their request. Once the request is clear, accompany the request to its completion. You will stand out to your manager and will improve the image of your team.

For example, if your team received an email asking: "Can someone on Team Xtreme meet someone from QA to figure this out?", respond back and ask for some clarification. "Hi Jane, I can help with this. I understand that X needs to be done, but can you clarify what you mean by 'figure this out'? Furthermore, who is best placed on our QA team to take this conversation with me?"

The same goes for any request that is made 'generally' without any specific actions for anyone. I often get general emails send to a distribution list with a question attached. However, when the email is addressed to 50+ recipients, everyone says to themselves "Someone else will answer that".

Rather than say "Someone else will answer that" to myself, I briefly analyze the email and see if I can answer the query directly. If not, I usually respond with something like "I think Tom worked on that before. He might be able to answer. Tom, any ideas?".

Team participation

I should go without saying, but I am surprised how often I see people not taking part in their team conversations. The worst thing anyone can do to their team is to not participate in the discussions. Silent team members who give no opinions or ideas are of little use to the team.

When you are at team meetings, speak out and argue with your team mates (politely of course). Demonstrate to your team that you are capable of free thought and happy to defend your opinions.

The same goes for team outings. Whether your like it or not, if your team are meeting up outside of work hours and you are not there, you will naturally be left out of conversations during work hours. A good leader understands that you can't have all work and no play. Attend as many gatherings with your team as possible. Show that you want to get to know everyone better.

Leading from within the team means engaging everyone in the meetings and driving the conversation. Don't wait for conversations to start from the "top" (ie. team lead, technical lead). You are as much a part of the team as anyone else, so your opinion is equally as valid.

Look Foolish

Yes - you read the title correctly. Look foolish! One of the main reasons people don't speak up when they are confused is because they are afraid of looking foolish. It is our pride that gets in the way of furthering our knowledge.

To be an effective leader, you must have the humility to ask silly questions and expect to sound foolish. If you do not take this risk, you will be very slow to learn new things.

This was the piece of wisdom that accelerated my skills forward as a team lead. By lowering the bar to a point where you don't care whether you look foolish, you will find that you can ask questions a lot easier and learn quickly.

Team Improvements

Always be conscious of the tasks you find difficult, repetitive or menial. Leading the team is about figuring out solutions to problems you regularly have. Ask yourself questions like "Is there a way we can automate this?" or "Is there a new process we could introduce?". "Why do I dislike this task?" is a good question to explore the things nobody on the team wants to do.

Request to be assigned to improvements (especially your own suggestions) as much as possible. The improvement work is often the most interesting and rewarding work. You are contributing to making the team's lives easier as well as improving your product.

Make sure you demo your work to the team - it gives them an insight into how things are improving in the background. Your team will know you are looking out for them and will appreciate your contributions.

Menial Tasks

We all know the tasks that nobody wants to do. Documentation, admin, bug reporting etc. But it has to be done for every team, including yours.

If your team lead asks for a volunteer for a task, put up your hand! Your team will thank you for taking on a menial task so that someone else doesn't have to. You have also set an example for the rest of the team to follow.

Don't Whinge

This is my pet peeve. One of the most frustrating things anyone on my team can do is to state a problem without having thought about a solution first.

When you state a problem without a solution, you essentially say "it's your problem, not mine". Instead, say to the team "I've had this problem for the last couple of weeks. Here's what I think we can do to fix it." In this way, you have switched yourself (and the team) from a state of whinging about your problems, to a state of problem solving.

As part of a team, you will regularly come up against problems that require solutions. So make sure that you get into the habit of being solution oriented, not problem oriented.

Lessons for leading a product and teams from "Extreme Ownership" by Jocko Willink and Leif Babin.

I recently had the pleasure of reading “Extreme Ownership” by Jocko Willink and Leif Babin. Jocko and Leif are two ex-Navy Seals and have spent a large portion of their training learning how to lead effectively. Their book has some excellent insights into how anyone can, and should, be a leader, no matter what their role. I read this book with the focus on Product Ownership, and have some key takeaways that I can apply everyday in my job. 

There are no bad teams, only bad leaders 

A strong leader will do everything in their power to help their team achieve their goal. They aid the team in compensating for their weaknesses, thereby continually boosting the team morale and keeping the energy levels high. 

A poor leader will do none of these things, and will always result in poor team morale. This in turn leads to bitterness and pettiness within the team, where each team member will try to pull another down rather than boosting them up. 

Have a clear vision

If a Product Owner were to begin her product vision with “I suppose we could do this” or, even worse, “I don’t have a very good product vision”, then her teams will quickly dig in their heals and be without a purpose. Team energy would immediately drop and the Product Owner would wonder why her teams were not producing good work. 

For reasons like this, leaders should be analysed and scrutinised early and often. This could be a manager, Product Owner or Scrum Master. If these key individuals do not perform from a leadership perspective, then the likelihood of a failed project inflates quickly. 

Leading the Boat Crew

In their book, Jocko and Leif give the example of a boat race they were having during training. Each boat crew had a leader. For the first race, Boat Crew II had a proven, strong and assertive leader. He was able to kick his crew into gear from the start, despite the fact he had never lead them before. 

Boat Crew VI, on the other hand, had a leader who was poor in decision making and lacked willpower. For the first race, Boat Crew II won by a large stretch. While Boat Crew II members were ecstatic and pumped at their win, Boat Crew VI were bitter and resentful towards each other. What was worse, the leader of Boat Crew VI blamed his crew for the loss, saying they weren’t up to the job. 

Then the commander had the idea to switch leaders to see what would happen. Obviously, Boat Crew II’s leader was not pleased, but Boat Crew VI’s leader was more than pleased – he was finally going to get a good team! 

The commander was surprised with what happened next. Boat Crew VI’s new assertive leader kicked them into shape from the beginning, shouting orders and getting them to work together. Boat Crew II already had some experience working together, but with a poor leader they fell apart. Boat Crew VI won. 

Leadership is the biggest factor in any team’s performance. Without a strong leader, the team will surely fail. 

Each leader should have a definite goal of what they are trying to achieve. For the Boat Crew leader, it was the beach marker. Setting small, certain goals instead of vague, far off ones will help the team focus and hold themselves accountable for reaching their target. 

Hold your team accountable

A good leader will have a high standard of performance. If she sees a weak team member, she will help in building  them up and developing the skills they lack. At the end, she is left with a better team and a grateful team member. However, people must be held accountable for substandard performance, otherwise the leader will face the situation where her team is sub-standard because she has let it become the norm. 

Above all, a leader must develop a culture of leadership. Just like a good teacher develops a culture of learning, a good leader will have junior leaders ready to step up temporarily to get a job done. She should encourage that each junior leader within the team require the highest standard of performance possible from the other team members. 

Above all, a leader must develop a culture of leadership. Just like a good teacher develops a culture of learning, a good leader will have junior leaders ready to step up temporarily to get a job done. She should encourage that each junior leader within the team require the highest standard of performance possible from the other team members. 

Check your ego 

Everybody knows and understands how many egos are associated with office politics. But it is pride that makes us think that we are never a part of it. Before you respond in a meeting or a conversation with somebody, check your ego. 

In Task Unit Bruiser, it was “insisted that our uniforms be squared away and our haircuts military regulation”. The team held themselves and each other to a high standard. They understood that humility and discipline now would lead to trust and high performance later. 

In the software industry, there are often ways that teams fall short of what is expected of them. Did you leave your documentation to the last minute? Did you avoid using Test Driven Development because it was too steep a learning curve? Did you forget to reply to that email? 

If you put your own personal incentives ahead of the team’s success or, worse yet, put more preference in your own laziness, then you will play a destructive role in the team. 

Don't give into laziness

I find it very easy to give into tiredness after a long day of meetings and not bother checking acceptance criteria correctly or leaving writing that email until the morning. It’s not that urgent, it can wait! Eventually, these shortcomings lead to some failure. They might even lead to failures you had not anticipated, and upon first glance, don’t appear that you are to blame. 

But when one of your teams makes a mistake, there is only one person to blame: you. You were supposed to lead them and in failing to do so, they have failed. Jocko advises a senior leader on what he should say for an upcoming meeting with his boss. He needs to update him and say why the product is failing miserably. 

 “Our team made a mistake and it’s my fault. It’s my fault because I obviously wasn’t as clear as I should have been in explaining why we have these procedures in place and how not following them can cost the company hundreds of thousands of dollars. You are an extremely skilled and knowledgeable superintendent. You know more about this business than I ever will. It was up to me to make sure you know the parameters we have to work within and why some decisions have got to be run through me. Now/ I need to fix this so it doesn’t happen again.” 

Are you a leader whose team suffered a heavy defeat? Don’t think it’s your fault? 

Check your ego. It’s your fault. 

Prioritise and execute 

Difficult situations often arise in the business world, particularly for team leads and Product Owners. New requirements are coming in on a regular basis for each team, new bugs are being raised against teams during their sprints, daily meeting requests fill up our calendars, and then we have to try to get some work completed. 

It is easy for any Product Owner to become over whelmed with the workload on their to-do list. In these situations, Jocko and Leif suggest you “prioritise and execute”. Leaders must remain calm in any situation. As soon as a leader loses his temper or panics, he has lost the respect of his subordinates. 

In such situations, Product Owners must take a step back to visualise the whole picture. Since the direction of projects is constantly changing, particularly in the software industry, we as Product Owners must not have our sites fixed on a single goal. Since the goal is changing, we must be able to step back to see what must be planned and prioritised. Once we have a plan and a list of priorities, we execute. 

How to prioritise and execute

Jocko and Leif give a list of tasks to prioritise and execute in a difficult situation. Practice these steps so that they become ingrained into your way of working. 

• Evaluate highest priority problem.
• Lay out highest priority in simple clear terms. 
• Develop a solution. Seek input from key leaders and team. 
• Direction the execution of solution. Focus all efforts towards that priority task. 
• Move to next priority problem. Repeat.
• When priorities shift, notify up and down the chain. 
• Don’t allow to get fixated. Step back constantly to see other problems and rapidly shift as needed. 

A key follow on from “prioritise and execute” is that we should never try to do everything at once. Trying to accomplish 5 things at the same time will lead to most of them failing or having them half completed. 

Don't panic! Prioritise and execute.

Leading down the chain of command

Most people are familiar with the concept of leading down the chain of command. Senior leaders do not need to understand the intricacies of their more junior members. By knowing too much about something, it is very possible for senior leaders to become bogged down in the details, rather than handing off the responsibility to a junior member. 

Communicate the What

As a Product Owner, I must convey the “What” to my teams as best as possible, answering their questions about requirements or at the very least, pointing them to the person that can answer the questions. Once I start delving into the “how” of a solution, I have immediately lost my position of leadership. Straight away, the team have turned from a vision-focused attitude to one of how are we to accomplish this? The Product Owner must learn to step back from the technical side and entrust it to their team. 

Communicate the Why

The above problem is common, however the more pervasive issue that occurs is where the senior leader fails to communicate the Why. Why is your team putting in this requirement? Will it help the product? How will the end user use this requirement? Without putting across the why, the team cannot understand the best solution to the problem. It is very possible that the requirement is not what the user needs to accomplish their goal. 

When a Product Owner is discussing requirements with his teams, the What and the Why are the key issues he needs to get across. By leading down the chain in this way, and entrusting the how to his teams, the requirements can move in the best direction forward. 

Leading up the chain 

Leading down the chain is a very clear concept. Essentially, it is about senior leaders leading their junior members in the best way forward by communicating the what and why. 

Leading up the chain is something many people struggle to understand. Yet once you understand it properly, it becomes a powerful skill. This lesson is the most valuable in the whole book, and rings true with my daily tasks. 

My leader isn't leading

A problem that everybody comes up against, whether you are a junior developer or project manager, is that we regularly come into situations where nobody is willing to lead. 

For example, a junior developer receives a bug in her backlog one morning when she arrives into the office. The bug contains 2 lines describing briefly what happened to the user, but there are no logs attached, no steps to reproduce, nothing except a brief overview. 

The developer looks at her screen, spends an hour trying to recreate the vague situation that has been described and eventually huffs and gives up. At lunch with her workmates she complains about how terrible the bug author is and does not know how to proceed.  

What should this developer do in such a situation? She is lacking leadership from the bug author and cannot proceed without doing something. Jocko and Leif say that if you are not being led, then lead. 

In the case of the junior developer, it is up to her to contact the bug author, and give a list of details that must be filled out before she can continue with the ticket. 

Reach out

For example, an email to the ticket author might look something like the following. 

Hi James, 

I see you raised a ticket against me this morning. Before I proceed with solving the issue, there are some details I require from your system: 

Product version 
Logs / trace files 
Steps to reproduce 

I cannot proceed with your ticket without the above details.  

Best Regards, 

clara.

Here, Clara has led up the chain of command to the bug author. 

From a Product Owner’s perspective, we come into situations constantly where no direction is being given, and communication is vague and implied. In these situations where our colleague is unwilling to lead, it is up to us to lead them. 

State the problem, propose a solution

If, for example, a senior manager contacts you as a Product Owner, asking you to assign a responsibility to one of your teams without giving any details about what is an expected outcome or what tasks are involved, do not simply say yes. 

Tell your manager that in order for your team to take on this new responsibilty, you first need a list of items that need to be completed and a list of expected outcomes. Once you have this information, you can then approach your team and communicate properly what is required of them. Otherwise, they will become frustrated that you are asking them to do something, but don’t seem to know exactly what. 

Learning to lead up the chain of command is the most valuable skill I have learned so far as Product Owner. The wall most people run into with this lesson is this: If your leader isn’t leading you, then it’s their problem. This is false. Your leader will still require you to get the job done. It is up to you to explain what you need in order to get there. If you want to stand to your senior management and colleagues, learn this and practice it every day. You will make mistakes getting it right, but will be very respected once you come out the other side. 

State the problem, propose a solution.

Summary 

Leadership is a part of every job. You do not need to be a manager or in a particular industry to utilise these techniques. Teachers, doctors, developers, recruiters can all find benefit in these skills and use them to accelerate their careers. 

If you are interested in getting started as a leader, I recommend reading “Extreme Ownership” by Jocko Willink and Leif Babin. 

To summarise: 

• There are no bad teams, only bad leaders. 
• Check your ego. 
• Prioritise and execute. 
• Lead down the chain of command. 
• Most importantly, lead up the chain of command.

tl;dr

• Take a deep breath before you walk into a conversation.
• What is the person leaving out?
• Paraphrase the other person's concern back to them.

Listen Effectively

Listening is a highly underdeveloped skill that most of us do not use. It is also a very difficult skill to develop. We spend about 50% of our time everyday listening. Despite this, only a tiny minority of us have ever been trained to listen effectively.

Nowhere is this more clear than in the workplace (and the college campus!). Daily conversations and arguments happen over lunch or in meetings that are often dominated by a minority of strong personalities.

As a result of a select few taking over the conversation, the people who are more reserved do not get the chance to make their opinion heard. Furthermore, if the louder person is particularly dismissive, then it is not uncommon that the quieter opinion gets pushed into the margins.

Apart from these cases, the average person can also use their listening skills more effectively with just a few techniques. Use these techniques when you need to clarify someone’s position or gain a greater understanding of a viewpoint.

I use these techniques everyday during meetings or conversations when somebody is explaining their idea. By asking some key questions and listening carefully, I make sure that I understand the message of the other person as well as make them feel comfortable speaking with me. If you are in a leadership position, this is extremely important. A leader who is a poor listener will not progress with their teams.

Take a deep breath

Breathing is a proven effective exercise for calming the mind and relaxing your body. By breathing deeply before having a conversation with a person or walking into a meeting, you de-stress your body so that the conversation is relaxed, friendly and professional.

Before you walk into a meeting or when you queue in the canteen for lunch, take a moment to breathe deeply and slowly. Breath in for 5 seconds, hold it for 5 and breathe out for 5. By doing this, you will relax and enable your brain to go into a conversation clear of distraction.

What is not being said?

Oscar Trimboli has written about the 125/400 rule before. To summarise, most of us speak about 125 words per minute. Moreover, we can process between 400 and 450 words per minute. When we are trying to explain a concept to somebody, our mind outperforms our mouths.

Without first thinking about what we want to say (and let’s face it – who does?), it is easy for our conversation to take tangents. Our mind starts to race ahead of what we are saying and instead of explaining a story with a beginning, middle and end, we jump from the beginning to somewhere else and only sometimes end up at the finish. It is very easy to lose context when we speak, particularly if we are not rehearsed.

To gain a deeper understanding of the person’s narrative, think about what they do not say. Are they missing out on explaining some technical details? Do they make an assumption that does not sound correct?

Of course, you should think about what they are not saying within the confines of the conversation. Don’t ask about the weather if you are talking about a new product feature.

But why Dave?

For example, say Dave wants to talk to you about a new login page for your customers. He explains in great detail what the login page will look like, how the user will use it and so on.

Dave has explained very clearly what his idea is, but he has not explained why he thinks we need a new login page. In fact, it is possible that the why here is much more important than the what. Has Dave identified a user scenario we have missed that requires this page? Does Dave have information about a customer that we have overlooked? Do we need to redesign the current login page?

As you can see, by simply asking Dave “Why do we need a new login page?”, we gain far more knowledge about his idea and the purpose behind it. If we had merely asked him to clarify about his new design for the login page, we would not discover this crucial piece of information.

Ask questions to uncover what was ­­_not­_ said. You will quickly gain insights into your conversations and develop deeper levels of listening and comprehension.

Repeat it back!

Have you ever noticed that it isn’t until you explain a topic to somebody else that you realise how many holes are in your understanding? The purest form of thinking is when we talk to people. By speaking our thoughts aloud, we quickly realise how little we truly know about a subject.

If you don’t believe me, pick a random topic that you know and try talking aloud about it for five minutes. Don’t prepare anything. You are doing very well if you reach the five-minute mark. This is because without preparation, it is very difficult to organise our thoughts enough that they are ready to pour out to somebody else when called upon.

By taking this into account when somebody is speaking with us, we can use this next technique to gain a deeper level of listening.

Paraphrase

To make sure that you fully understand the other person’s viewpoint, paraphrase back to them your understanding of the conversation thus far. The other person will either nod their head vigorously, or interrupt you to correct you.

Since we can only process so much meaning in our speech, it is important that you state the other person’s concern or idea back to them so that everyone is on the same page and the conversation can progress.

If you are wondering what ­_not_ to do, have a look at this: "So you're saying..." .

To have a meaningful discussion, it is important that you represent the person’s views fairly. In debates, we call this making a “steal man” of your opponent. It is also the opposite of “straw man”. Although you should not treat conversations as debates, this concept is very important to represent somebody and make sure they are  heard for what they think, not just what they say.

Summary

Remember to take a deep breath before you start speaking in a meeting or even in a one-on-one conversation with somebody.

Think about what the other person is not saying. They may leave out key bits of information you need to fully understand what they are talking about.

Ensure that you are on the same page as the person talking by repeating back to them what you understand about their query. They will either confirm your understanding or correct it if you misunderstood something.

tl;dr

• Avoid using vague terms.
• Use real world data.
• Use real world examples.
• Stop writing scripts.
• Involve fewer people.

Overview

Example mapping is an effective way to clearly communicate new features or user stories to a team. When used effectively, examples are shortcuts through hours of conversations and long user scripts.

Everybody who works in the software industry should understand how to map out good examples of their work. It is an extra tool in a developer’s toolkit and it is necessary if you are in a position of leadership such as Product Owner or team lead.

A prime example of example mapping is in the Friends’ episode titles. Here are a few of them:

• "The One with the Blackout"
• "The One Where the Monkey Gets Away"
• "The One with a Chick and a Duck"

If you have seen these episodes, you know immediately what these titles describe. There is no need for a description or even a list of the characters. Because the title is written as an example, is good enough for us to understand what the episode is about.

There are many ways to create examples. I have gathered five helpful tips from my own experience which you can use.

Avoid using vague terms

You should use concrete examples as much as possible to illustrate the use cases. Take a step back from your example and ask yourself “Is this as specific as we can make it?”.

For example, if my customer is using my banking system, rather than saying

• Where the customer clicks the submit button more than once and receives an error message.

You should say

• Where the customer clicks the submit button twice and receives an error message.

Be specific

Narrowing down what is meant by ‘more than once’ helps us to get a clearer picture of the example. Furthermore, it increases a shared understanding in the team. It is very possible that the first example would give confusion as to whether a button should behave differently when it is clicked twice or one hundred times.

Represent an idea with a concrete example rather an abstract example.

Use real-world data

When creating examples, one should strive to create examples using real-world data. The difficulty in creating examples with made up data is that we run into strange situations where our real-world data does not align with our fictional data.

For example, I can create the following example with my fictional data in my banking system:

• Where my customer deposits $300 into their savings account.

The team would receive a shock when their customer contacts them angrily saying that they have not taken into account their customers who are using euros!

It is easy for examples to deviate from the product specification when we fake the data inside them. Something so simple as using dollar instead of euro can easily be resolved by understanding the real-world data.

Furthermore, if we are working on a “legacy” system and use fictional data in our examples, then we cannot know with any certainty that our made-up data will fit with the data the legacy system produces.

The changing rules and data structures of legacy systems means that using real data to drive our examples is key. A simply misunderstanding in the data can very likely result in an incorrect solution.

Use real-world examples

In the previous section, we spoke about using real-world data. Following on, we should use real-world examples also.

It is important when creating examples that we capture how the end customer will use this specification. By capturing how they will use it in an example, we are able to capture what the specification involves.

If, instead, we use fictional examples, then we are creating a “what if?” scenario. Rather than focusing on what the specification ought to look like, we focus on our imaginative conception of the idea. More often than not, this will be a false conception.

Let’s go back to our banking application.

• Where the user withdraws €20.50 from the bank’s machine.

This looks good, right?  But what happens when the bank calls us back saying that they do not give change from their machines and inputting a decimal point results in a major failure?

This could have been avoided by using the real example of how a user ought to withdraw money from the bank.

Get close to the customer

It is key in these scenarios that the teams creating the specification have close access to the customer. In reality, this can be very difficult.

Large companies often have a heavy buffer between the customer and developers. If this is the case for you, then your goal is to get close to the person who is close to the customer.

Often, there will be a team that are customer facing and take on their requirements. Introduce yourself to this team and communicate frequently with them. Once you are on good terms with this team or person, you may be able to suggest that you come on board for the next customer meeting.

Stop creating scripts

Here is an example of a script:

• Enter username & password
• Click login button
• Land on dashboard
• Go to search page
• Search for “12 Passat”
• Click on first result
• Click on ‘details’ tab
• Check that car price is present

Scripts are not examples. What we are describing here is the how, not the what. By prefacing the how with the what, we are ensuring that the how follows the what and not the other way around.

What we are creating and why we are creating it is more important at this stage of discussion than understanding exactly how we are going to achieve our goal.

Furthermore, from an example perspective, we should not care how our specification is implemented.

Scripts act as anti-patterns to examples. By using examples, we can cut out the majority of a script and get to what the script is describing.

Imagine that any given feature involves pages and pages of scripts in order to correctly describe it. Now imagine what we need to look at when one of our usability tests fail. We need to comb through too many words to find what we need or where it all went wrong.

By having scripts instead of examples, we create a murky idea of what we are implementing. By using examples, our communication with the reader is much more effective and allows us to cut out a lot of writing, thereby saving us energy and lots of time.

Brainstorm with fewer people

A common issue I encounter is when there are too many people in the room for us to have a meaningful conversation. It is rare that a room consists of people who are all interested in what everyone else has to say. Most often, a subset of dominant personalities will take over the workshop and drown out the good ideas of the others.

There is a simple way to mitigate the amount of opinions in the room – reduce the number of opinions.

There may be those of you that think that having many opinions in the same room can be a good thing, and you are correct!

Very often, in order to hammer out the finer details of a user story or a feature, we need two or three strong-willed individuals to clash. In my experience, this type of conversation can be very helpful, but only if there is somebody to take charge and mitigate the conversations. This is usually the team lead’s duty.

Circular conversations

Doing workshops with large groups also increases the regularity of circular conversations. I believe circular conversations to be the most common time-waster in meetings.

By decreasing the number of persons in a workshop, we are able to take down everybody’s thoughts quickly with minimal time wasting.

At a very minimum, I suggest that three people are present in any one of these workshops.

• Product lead
• Test focused developer
• Developer

The product lead understands the product the best. This may be the product owner, team lead, or another stakeholder.

The test focused developer is important for their testing mindset. They need to be able to poke holes in what is discussed and find out where there are gaps in knowledge and understanding.

Finally, developer should be focused on understanding as much as possible from a developer’s perspective so that the how can be focused on later on.

Summary

Writing examples is a quick way to cut out needless conversation. Use examples regularly to save time and to increase communication between yourself and your team mates.

To summarise:

• Get specific - don’t use vague terms to describe your examples.
• What is actually happening? Use real world data.
• Who is doing what? Use real world examples.
• Save time - stop writing scripts.
• Circular conversations? Involve fewer people.

1. Install Cygwin

Go to https://www.cygwin.com/install.html and download setup-x86_64.exe Run it

• Select 'Install from Internet'
• Choose root directory (default)
• Choose pacakage directory to store installation files
• Use System Proxy Settings
• Select any mirror site to download

In 'Select Packages'

• Select Category dropdown and search for lynx
• Go to All -> Web -> lynx: A text-based Web Browser
• Select latest version
• Click next to complete installation

2. Install apt-cyg

This is a package manager for cygwin

To install:

• lynx -source rawgit.com/transcode-open/apt-cyg/master/apt-cyg > apt-cyg
• install apt-cyg /bin

3. Install dependencies for ansible

To install altogether

• apt-cyg install binutils curl gcc-core gmp libffi-devel libgmp-devel make python python-crypto python-openssl python-setuptools python-devel git nano openssh openssl openssl-devel

You can also install individually by using

• apt-cyg install  or by using the installation GUI

4. Install Ansible

To install

• easy_install-2.7 pip
• pip install ansible -vvv
• Here, the -vvv is used in case the install seems too slow. It will show you if everything is still working.

5. Test ansible

To test installation

• ansible
• Should receive list of options

Some configuration

Cygwin comes with some strange default settings, particularly if using vi or vim.

Open a .virc file.

• vi ~/.virc

Type in

set nocompatible
set backspace=2 

Run a playbook with Ansible

Make a new directory to test ansible with a simple playbook.

mkdir ansible-lab
cd ansible-lab

Ansible needs some configuration to work on a Windows machine. Our Windows machine is called the 'control' machine. Ansible does not officially support this.

Create an ansible configuration file.

vi ansible.cfg

Copy and paste the following into the file.

[ssh_connection]
ssh_args = -o ControlMaster=no

Now we will create our ansible playbook to test.

vi playbook.yml

Copy the following into the file.

- hosts: all   
  sudo: yes   
  tasks:   
    - name: install apache2  
      apt: name=apache2 update_cache=yes state=latest   

Bring up a virtual machine

We need a virtual machine to run this against. For this we will use a Vagrant box. Don't worry if you have not used Vagrant before. It is an easy way of installing virtual boxes on your machine and managing them.

We need a Vagrantfile to bring up our virtual machine.

vi Vagrantfile

Copy and paste the following.

Vagrant.configure("2") do | config|  
  config.vm.box = "bento/ubuntu-18.04"  
  config.vm.network "private_network", ip: "192.168.33.10"  
end

This will bring up a ubuntu virtual machine to run our ansible script against.

To bring up your virtual machine, make sure you are in the same directory as your Vagrantfile and type

vagrant up

Depending on your connection, this may take a little while to boot up.

Once your machine is booted (you can check if it was successfully booted by typing vagrant status), you need to make sure your control / Windows machine can connect to it.

Setup ssh connection

On your Cygwin terminal, generate an ssh -key.

ssh-keygen

Keep pressing enter until it is finished. Print out the .pub file where it saves the key. For example, mine looks like the following. Yours will be in the .ssh folder also.

cat /home/abcd/.ssh/id_rsa.pub

Copy the value that is printed out. Now you need to go to your vagrant machine.

vagrant ssh
vi .ssh/authorized_keys

Go to the end of the file, go to the next line (by pressing enter) and paste in your key from the id_rsa.pub file

Exit your vagrant machine.

exit

Test your ssh connection with the following.

ssh vagrant@192.168.33.10

You should be able to login to the virual machine without any prompt or failure.

Exit the machine once again.

exit

Run your ansible playbook

Make sure you are in the same directory as your ansible script. Ideally, you have your Vagrantfile, playbook.yml and ansible.cfg all in the same directory.

Ensure ansible is ready to go.

ansible-playbook --version

Now type the following.

ansible-playbook -i vagrant@192.168.33.10, playbook.yml

Your tasks should appear in a list. Once finished, the PLAY RECAP should have ok=2 and changed=1.

Congrats, you have just run your first ansible playbook!

Wouldn't it be great if we could all create clean code to a high standard from the moment we begin programming? If we could create clean and simple code that anybody could read, can you imagine the time saved on both an individual basis and on a company level?

When I began to write code, it was immediately clear to me that there are, on average, at least three obvious ways of going about a problem. If you think about the problem for longer and go into some research, then the number of solutions could go right into the double digits. Then we need to worry about which solution will yield fastest results in a short space of time, and how long will it take to code up. While doing all this, you need to write simple, clean, maintainable code. This is very difficult.

Or is it?

In fact, you can create readable and simple code from the get-go with just a few pointers. By implementing the points in this post, I was able to turn a lot of my code from a pile of spaghetti into a well-tailored suit.

In this post, I am going to show you exactly how to create great code that others, including yourself, will be happy to read and maintain long after you are finished with the project.

Beginner Coders vs. Expert Coders

When I began my coding career, I wasn't sure what the difference between a beginner, intermediate and expert coder was. All though these lines are subjective, there are some certainties that we can extract on the difference between stages.

A beginner is somebody who studies the coding language but isn't very sure about how things work or in what way they work. A lot of code gets copied and pasted from the internet without much knowledge of how it works. Often it is just a case of trial and error in seeing whether or not something works.

In contrast to this, an expert coder understands every line of code that they write. Code will rarely get copied and pasted, instead the expert coder has the ability to extract ideas and formats from the code they are reading. They can then apply these extracted concepts to their own project.

I once heard a very good statement about coders. It went something like this:

Juniors build complex solutions to simple problems. Intermediates build simple solutions to simple problems. Experts build simple solutions to complex problems.

In progressing from stage to stage in your coding career, one thing remains a constant: you need to be able to write good, clean, readable and simple code. No matter what your current skills are, you cannot progress further if you do not write clean code.

Write Clean Code

The following five posts will go through briefly what I believe to be the fundamentals of writing simple code. These are all points that you can start practising straight away, if you do not do so already.

1. Use Clear Names in Your Code
2. Silver Whitespace
3. Short Methods
4. Short Classes
5. Commenting
6. Use Libraries

After reading these articles, you will hopefully be able to put the pointers to good use, whether it be in a simple method, or developing the rest of your application using clean code.

Update 3rd February 2021: The below post has been updated with new links and clarifications. HMVC Codeigniter should work with PHP7.3 and Codeigniter 3.1.11.

Codeigniter HMVC is a transformation of the popular MVC (model-view-controller) model that is widely used today. It came about as a solution to some problems that developers came across when using the MVC framework.

Problems with MVC

• Quite often, it can be difficult to transfer features from one website to another.
• MVC does not scale very well. It discourages good design practices and can lead to a lot of spaghetti code.
• MVC doesn’t have standardised practices. As a result, we get lots of different opinions as to how one should properly use MVC
• In comparison to HMVC, adding widgets to an application designed with MVC is difficult.

HMVC solves most (if not all) of these problems.

Advantages of HMVC

• Modularization: We can separate each section of the app, dividing the app into different parts.
• Extendibility: We can add parts to the application easily with little risk of breaking the application. For example, widgets.
• Organization: Super tidy file separation and folder organization!
• Reusability: If implemented well, the developer should be able to reuse every bit of code they write.

HMVC Structure

The HMVC (Hierarchical Model View Controller) structure is a combination of multiple MVC triads. Each MVC triad is called a module. A controller of one module can call a controller of another module very easily.

Furthermore, we can call other modules from view files. This makes it very easy to insert widgets quickly.

Modules

A module contains the model, view and controller folder for a certain section of the app.

For example, if we take http://www.mywebsite.com/welcome, then we know that /welcome is actually a module! So every file that relates to my /welcome page, apart from external libraries, are placed inside the Welcome module =>

This demonstrates how easily managed apps can be, cutting down on time resolving conflicts from different versions of files, and avoiding general confusion.

Now it's time to install our own HMVC framework.

Installing Codeigniter MVC

• We need to install vanilla Codeigniter before we install our HMVC file structure.
• First download most recent version of Codeigniter.
• Install codeigniter on your computer – this is just a simple matter of copying + pasting the files into your root directory.
• If you do not have a server installed, checkout my post on installing wamp.

If you have followed the Codeigniter documentation, you should have the MVC file structure setup in your directory like below. Here we can see our controller, models and views folders – which is what the MVC framework looks like.

• Check that all is working and go to the URL /index.php/welcome
• You should see the welcome page of Codeigniter.

Install HMVC structure

• Download modular extensions
• Unzip the downloaded file
• Go into the /third_party folder
• Copy the folder /third_party/MX
• Go to your Codeigniter directory and paste into /application/third_party

• Do the same thing again except copy and paste the contents of /core in the downloaded file into /application/core in your codeigniter directory.
• You should now have something like this:

• Make sure everything still works by going to the URL /index.php/welcome

Transfer files into HMVC framework

• Create the directory application/modules/welcome/controllers
• Move the file application/controllers/welcome.php to application/modules/welcome/controllers/welcome.php
• Make sure everything still works by going to the URL /index.php/welcome
• Create the directoryapplication/modules/welcome/views
• Move the file application/views/welcome_message.php to application/modules/welcome/views/welcome_message.php
• Make sure everything still works by going to the URL /index.php/welcome

Once the above URL loads, this means that HMVC Codeigniter has been successfully loaded. Congratulations!

Redirect from /index.php/welcome to /welcome

When you first access your newly setup HMVC app, you will need to access each module via /index.php/welcome.

If you try to go to /welcome directly, you will get a 404 not found. This is a bit messy - so let's fix it.

Go to the root folder of your Codeigniter application. Create a new file called .htaccess. Paste in the following code.

RewriteEngine on
RewriteCond $1 !^(index\\.php|resources|robots\\.txt)
RewriteCond %{REQUEST\_FILENAME} !-f
RewriteCond %{REQUEST\_FILENAME} !-d
RewriteRule ^(.\*)$ index.php/$1 \[L,QSA\]

Note: There are already .htaccess files in Codeigniter - these are not the files to edit. Create a brand new .htaccess file at the root of your directory structure.

Now go to /welcome. You should be able to see your welcome page!

Next Steps

Experiment with your welcome module and learn how codeigniter works. Mess around with the controller.php, create some new views, add in some CSS and get comfortable with your new framework.

Once you are comfortable, it's time to think of an app idea -good luck!

Why use different retro questions?

Most teams have workshops called 'retros' where they reflect on the previous couple of weeks and decide what to improve going forward. For most teams, the retro is treated as another obligatory meeting dictated to them by the scrum rules. Teams that have no experience in effective retros see these workshops as a waste of time, and why wouldn't they? The teams that do have retros often have them too infrequently, taking a retro once every couple of weeks. As a result, teams find retros are 'too long' or inefficient because they try to do too much. Instead of taking retros more frequently, teams stop doing them or give up in putting in effort.

One sympton of inefficient retros is to run the workshop again and again in the same way and without any variety in the questions the team ask themselves to diagnose and introduce changes. After the team has asked themselves "What was good? / What was bad? / What should we improve?" a few times, everyone gets bored. Here is a list of questions to help your team find different and interesting experiments to run.

Day to day questions

Mini 15 minute retros everyday can help supercharge the team by bringing in tiny improvements each day. It also prevents those horrendous 3 hour long meetings at the end of a sprint where the saved up all their problems and ideas.

• What was good today? How can we turn it up? "Turn up the good" is a concept from Woody Zuill and Kevin Meadows' 'Mob-Programming' book. When working with teams, they asked themselves this question at the end of each day.

• What was the best thing about working together today? This is a good question to see how the team can do more good teamwork together.

• How many hours did each person spend working with someone else? What would happen if we increased this? A team is not a team if the people are not working together. Increasing the amount of time people pair and mob-program together could supercharge the team.

• How many hours did we spend blocked by someone else this week? How can we reduce this? Blockages and work in progress are huge areas of waste for teams. Identifying where major blockages are is extremely valuable to help teams do more of the fun stuff.

• What was our favourite tasks we did in the last 3 months? How can we do more of these tasks?

• What went really poorly today? How can we prevent it in the future?

Post mortem questions

In the event the team encounter a critical problem affecting customers, they will need to run a post-mortem on the event to diagnose and prevent future issues.

• What went wrong?
• What made you nervous?
• How can we prevent this happening again?
• Why did this incident happen?
• What else could go wrong that we got lucky with?
• What's the worst thing that could happen in this situation?

Worst case scenario analysis

What's the worst thing that could happen your team? It will likely happen at some point. Don't be the team that doesn't prepare for worst case scenarios because it is too uncomfortable to think about.

• What's the worst thing that could happen us? How to we mitigate that risk?
• If component X crashes in production, how can we get it back up?
• What's our bus factor for each responsibility and how do we increase bus factors of 1?
• What's the worst thing that we own that could happen and impact our customers?

Best case scenario analysis

Analysing a perfect day in the office can give insights into improvements. This is similar to 'turning up the good'.

• When do you love doing your work?
• What does the perfect day look like for you?

General improvements

• What's one thing you've always wanted to try?
• If we were to fix something permamnently tomorrow what would it be?
• What's something you learned about recently that you would like to introduce to the team?
• What tasks feel stale for the team?
• What's the thing you hate doing? How can we make it less painful?
• What's the thing you love doing? How can we do more of that?
• On a scale of 1-10, how good are we as a team?
• What's the lowest priority thing on our Todo list? What would it take to delete this task from our Todo list?
• Whats the main thing we do or support that we are known for?

Use Tools to Get the Job Done

It is valuable to develop a large toolset. Using tools is in our very nature. Tools help us accomplish tasks and solve problems. In the job market, nobody cares about your theoretical knowledge. No interviewer will ask you to write a paper on theoretical computer systems. Every interviewer wants to know one thing and one thing only - can you get the job done?

Stay Flexible in the Job Market

Without tools, we would not be able to accomplish most of our everyday tasks. The more tools you can use, the more problems you can solve. And the more problems you can solve, the more jobs you can do. A large toolset means you are flexible enough to apply yourself to many different jobs. If you're flexible, you can apply to other jobs should something disastrous happen such as a layoff or health issue. This gives you a lot of stability and peace of mind.

Get Good at Lots of Tools

Tools solve problems. So, what problems do you have in your job or in your personal life? Start from what you need. Do you struggle to track your money? Learn excel to record your spending and calculate your budgets. Is there something broken in your house? Learn how to use a hammer and nail to fix it. Do people often get frustrated with you at work? Learn to communicate yourself better to them. There is always a tool to solve your problem. Therefore, start with your problems and see what tools can solve them. There is a dual reward to using a tool to solve your problem. The first is that you figured out and solved your own problem - that's a great feeling. The second is that you now have a new tool in your kit for the rest of your life. When a similar problem appears in the future, you will be able to use the same tool to solve it. A life of tool learning builds on itself to become something extremely valuable. As you encounter similar problems again and again, you can use tools you know to solve them quickly.