Working with Intentionality
While most people agree with the adage to “work smarter not harder,” I’m sure we can all relate to the impulse to clock extra hours when the deadlines are lining up and work needs to go out the door. Taking time to step back, reflect on our processes, and then identify and implement new strategies to improve seems counter-intuitive when you feel like you don’t have enough time to get work done. But without taking time to step back to see the forest for the trees, a team will only maintain their status quo, where the only way to get more work done is to invest more time, and eventually we don’t have more time to give.
I often fall back on Chris Bailey’s definition of “productivity” to stay true to this adage: productivity is not getting more work done quicker; rather, it’s about getting the right work done the best way. To do this, Bailey focuses on strategies that improve the intentionality we bring to our work. In his book The Productivity Project, Bailey details strategies for individuals to step back and assess if their doing their highest-impact work or just staying busy (and working long hours) getting all work done, regardless of value or purpose. For any individual interested in getting more work done in less time, I recommend reading Bailey; for any organization, I recommend taking a look at the Agile framework.
If you work in the tech world, you’ve probably heard of Agile methodologies, which offer a framework to adapt quickly to change. While traditional Agile is born out of software teams, there are plenty of people talking about how it can benefit other types of businesses (here’s what happened when NPR went agile). For this blog post, I’m going to focus on one of Agile’s 12 principles that can be implemented by any team that wants to approach their work with intentionality: continuous improvement through retrospectives.
One of the principles of the Agile Framework is continuous improvement: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In an Agile organization, teams perform retrospectives at the end of each iteration of work (a “sprint”). But any team can benefit from a regular cadence for reflecting on their work (what went well and should be continued, what went poorly and should be fixed) and implementing ideas for how they can approach their work more productively.
Retrospectives in Action
A retrospective can last 30 minutes to an hour. A standard agenda might look something like this:
Take 10 minutes to write post-its and put them in the following 3 categories:
- What’s going well?
- What could use improvement?
- What could we be doing differently?
Once everyone is done putting their post-its in the columns, a team member facilitates discussion of each question and creates action items and process changes to try for the next iteration of work.
The questions can be modified to fit your team and your process. Two other retrospective techniques that I have enjoyed are:
- Same as – More of – Less of
- Learned – Loved – Loathed – Lacked
Ultimately, the purpose is to help the team identify what processes are working well and which ones can be improved, and then brainstorm improvements which can be tried and then assessed at the next retrospective.
If this sounds fairly simple and obvious, it is. But common sense does not always translate to action, especially in a busy workplace. And carving out time for a retrospective at regular intervals can feel ineffective because it takes up valuable time. But by stepping back and assessing their work, the team is given the opportunity to improve their dynamic and processes, which saves time in the long run. This distinguishes a team that maintains the status quo from a team that can create effective, productive, sustainable work without longer hours.
My recommendations for any team that runs a retrospective:
- Make sure the whole team is on board with the purpose and outcome: keep the conversation focused on topics that are within the control of the team. I recommend time boxing topics as they come up (i.e. “let’s take five minutes to discuss how this data is being used and what changes we’d like to see”) and ensuring that the facilitator is driving toward outlining the team’s perspective, brainstorming ideas, and then gaining consensus in order to implement changes. I also like to create a “parking lot” to put ideas that are beyond the scope of the retrospective so that I can follow up on them outside of the meeting, rather than letting them drive the discussion off track.
- The output of a retrospective should be actionable changes to process that will be put in place for the next iteration of work (or longer if they work well). When teams trust that their changes will be implemented, they become more invested in identifying opportunities and creative solutions. It’s important to trust that the people completing the work are best informed on how their process should change.
- By having a regular schedule for retrospectives, e.g. every two-four weeks, teams can trust that they will have opportunities and ownership to improve their work. This can lead to increased motivation, new ideas, and the ability to test out new processes and quickly assess, improve, or eliminate them. Change becomes less daunting when teams know that any new process will include opportunities to reevaluate and improve.
- Retrospectives and other Agile practices promote self-managing teams, and encourage the team doing the work to continuously improve their process. Thus, the team–and not management or supervisors–should be included in these retrospectives. Team members should be empowered to honestly discuss their work, trust that all members are invested in their productivity, and take ownership of improvements.
If you are interested in implementing retrospectives, there are a wealth of tools and resources available. While I’m a fan of the in-person post-it retro, there are online tools like retrospected that facilitate this process and all sorts of options for different types of retros.
Paige Normand is a Certified ScrumMaster and taught Agile at James Madison University before joining Gravity Group.