Many software development teams have a process including retrospective meetings. An opportunity for the team to look back at a period of time and assess how it has functioned. It’s often connected to the Scrum, but you don’t need to be adhering to any process / approach to see the value of having retrospective meetings. The goal of the retrospective is learning. What worked? What didn’t work? How can we improve something that’s broken? Should we continue with something that’s working?
Another aspect of the retrospective is that it’s meant to be a safe place for team members to speak their minds. The idea being that given a safe place, a team can figure out its own problems and possibly even solutions.
To create that safe place there needs to be trust. Enough trust so that team members can be candid with each other about issues that arise while working together. Enough trust that allows the team members to be vulnerable, and know that they won’t be judged. Where blame isn’t handed out, but rather bonds created and learnings are formed.
But how do we create a space in the busy life of a software development team, where deadlines and bugs are commonplace and there’s often a pressure to deliver something that will create value? Continue Reading
I recently wrote about candor as a better way to achieve truly open and honest communication. Candor Inc created the framework of “Radical Candor” as a way to categorize your feedback and communication.
What I didn’t do in my previous post, is dive into how the different ways of communicating actually would sound like. In this post I’ll explore the framework more deeply and also look at an example.
Working in any team environment will involve communication between its members. To really bring the best out in others and yourself, having a culture of where honesty is important. It’s also something almost anybody will verbally agree to. Yet being open and honest in a good way is extremely hard. How often do you refrain from saying something completely honestly because you don’t want to embarrass someone. Or what about the time somebody called you out on something in front of the team? Sure you may have needed that feedback, but what happens to your relationship with that person? What about the team dynamics?
Blunt honesty can not only be harsh, but downright devastating to hear. How then are we meant to move beyond the complications of honest communication and get to a place where our being honest actually provides room for everyone to grow? Continue Reading
The video in question is #43 in the funfunfunction series and addresses a very important subject: “Does a developer need to be nice?”. I’ve written a summary of the video, and added a few of my thoughts a the end.