Is your development team frustrated? Do they seem like they are going slower? Maybe you ask yourself, “Are they working hard enough?”

They need something called slack — no not that chat app. They need time to reflect on their processes and try new ones to see if they can work more effectively.

“How is that possible,” you ask.

The answer is a techtro.

Techtro: is short for technical retrospective. It is a chance for your software team to focus in on the technical process, reflect, and take action.

Motivation

You might feel like something is wrong. The way to fix it isn’t necessarily to force new processes on the team. Empowering a team to design their own process — within limits — can help motivate them, resulting in increased productivity and happiness. Techtro aims to create this type of empowerment.

Within any Techtro, there are four types of reflection that a team can use to evaluate their work. They are: what needs to change, what can they celebrate, what new processes to try, and what challenges are upcoming.

If your team writes code week to week, they have things that are going well. Since positive reinforcement can be a more powerful motivator than negative reinforcement, you should give them the space to celebrate their wins.

Trying new processes and tools out can help your team learn other ways of working. These new ideas, can help them see that there might be more effective ways to deliver software, and result huge wins.

Techtro Formats

Now that you understand the core motivation of a techtro. I will outline some different formats that you could use to identify ways to improve the software process.

Observe and Discuss

Ask the team to observe the process over the next iteration, and write down pain points or wins to celebrate. Then the team can bring those to techtro.

Once the team is in a room together go through the topics one by one, creating action items to try to fix pain points.

Techtro Retro

Try running your techtro as if it is just a retrospective. Give the team time to write their ideas on stickies — one idea per — and sort them into pre-determined topics. Topics can be happy/meh/sad, liked/learned/lacked/longed-for, or any other format you like.

Once the team generates their ideas, go around the room and give each team member a chance to explain their thought, and sort it into the correct category.

With everything sorted, it is time to generate action items. Go over the pain points and decide on a small action the team can take next week.

Code and Tell

Sometimes the team needs to take a step back and celebrate. A code and tell invites the team to bring code to the attention of the team. This could be code that they are proud of, or code they think is really well-designed and want to thank a team member for creating. Time-box each person’s sharing time, so that everyone has a chance to speak.

Conclusion

Techtro can be a great tool to help them own software delivery and yield the progress that the whole team wants. Suggest that your team tries a techtro at your next retro. You might find that they enjoy it. I recently wrote about what a techtro looks like using a narrative format. Check it out here: What the Heck is a Technical Retrospective?

Photo by Francesco Gallarotti on Unsplash

• process