“I see a problem.”
Every successful project faces challenges and has room for improvement, so it was no surprise to get a message like this from a developer. We were a week into a project with a very aggressive timeline and a new developer on the team. The problem was that during the first, foundational week, we made decisions that were right for the project but required some pretty advanced coding techniques that were outside the new developer’s wheelhouse.
Within a few hours of the message being sent, the full team talked openly about how things were going at a retrospective. Thanks to everyone’s honesty and the new developer’s vulnerability with the team, we were able to quickly come up with a plan at the first sign of friction. The new developer would take on cards that were good fits and occasionally pair with other developers on more advanced cards. The client and the Sparkbox team all benefited from the new developer producing valuable work, and the new developer grew while being an extra set of eyes on more complex code that needed it anyway. The project was a big success.
Sadly, this doesn’t happen in many organizations. It’s rare for people to sound the alarm and even rarer for someone who’s not performing well to speak honestly about personal areas for growth. Discussing how issues impact your team enables everyone to work on a solution. In the absence of open dialogue, you lose the chance to improve.
While leading Sparkbox Discovery efforts with clients, I’ve grown to appreciate how important this retrospective model, honesty, and vulnerability are to iterative improvement.
What’s a Discovery?
Sparkbox has been earnestly investing in Discovery efforts with our clients since we first worked with Dan Mall four years ago (which initially inspired our approach). “Discoveries,” as we call them, are client engagements in which we deep dive into our client’s unique business goals, challenges, and risks to best identify and crystallize the vision for project success. As part of these efforts, we review what we’ve learned (the good, the bad, and the ugly) and discuss what we should do. Knowing the natural discomfort caused by this level of feedback, I’ve been sharing the following Agile Manifesto quote before we dig into our research findings:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what was known at the time, their skills and abilities, the resources available, and the situation at hand.” —Norm Kerth, Project Retrospectives: A Handbook for Team Reviews
That quote is often referenced when teams perform retrospectives as part of the Scrum/Sprint process. And the more I reflect on these meetings with that framework, the more I realize these are really just our first retrospectives, and they require the same honesty and vulnerability all retrospectives require for iterative improvement.
What’s a Retrospective?
In a typical Scrum framework, teams work in small, repeated chunks of time (Sprints). At the end of a Sprint, which lasts usually one or two weeks, that team holds a retrospective as part of transitioning from one Sprint to the next. In retrospectives, teams are typically looking to celebrate high points and reflect on what went well, what could be improved, and where they could adjust to make future Sprints better. Some teams (especially larger ones) use tools like FunRetro, which allow members to anonymously share thoughts on successes and difficulties and vote on which items merit discussion. But the team’s output is only as good as their input. A fearful team concerned about negative repercussions from surfacing issues is never going to get better—it’s doomed to repeat past mistakes with increased tension each week. Teams must be courageous enough to honestly surface the right information to improve.
The great news is that it gets easier over time. As research professor and author Brené Brown has said,
“The willingness to show up changes us, It makes us a little braver each time” (from Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead).
As in most areas of life, practice makes better.
Discoveries are the First Project Retrospective
Just as retrospectives help surface the highs and lows a project team is facing, our Discovery efforts are designed to surface the highs and lows an organization is facing. Examining where your organization, team, product, etc. is right now allows you to look beyond the day-to-day and see the trends in order to determine the most important areas on which to focus. As a consultant, doing this allows us to help our clients understand how we can help them rise above those issues and arrive at the right solutions. It’s not always easy, but the same transparency necessary for a successful Sprint retrospective is just as critical during a Discovery and sets the tone for continued transparency throughout the project.
Let’s Be Honest: Vulnerability is a Prerequisite to Iterative Improvement
As Brené Brown said in her popular TED talk,
“vulnerability is the birthplace of innovation, creativity, and change.”
Improvement requires vulnerability. We can follow all the steps in the Scrum process and still wind up in the wrong place. An iterative model doesn’t equal success. Iteration is pointless without reflection, and reflection is pointless without vulnerability.
Discovery projects require tremendous transparency from our clients in order for us to successfully identify how we can deliver value together.
Hard truths presented in the light are needed to create solutions that cut through and impact real organizational success.
So let’s be honest.
