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
We’re sometimes placed in situations where we need to present our software to stakeholders, business owners or end users. These users may or may not be technical, but they will most likely be the other side of the user interface you are creating. They are the reason you create software and are genuinely interested in the end result. In recent years, with Agile and Scrum, these presentations tend to take place more often and you’re in the limelight presenting the latest and greatest. Many years of honing our skills as software developers have all but prepared us for this challenge, and we may end up getting a response from the attendees along the lines of this:
Too much uptight focus on technical details, digging deep into issues that nobody cares about, discussing the framework, library or platform chosen to solve a particular problem leaves you attendees bored, confused and sometimes feeling dumb since they haven’t got the faintest idea what you’re talking about. This leads to frustration, arguments, cold-fronts or just a general feeling of “meh”, where developers, stakeholders and users just don’t get the value out of this important meeting arena they could.
So what’s a developer to do? Here are some tips and thoughts for preparing for, presenting and participating in more technical presentations.