One of the exercises we played at our most recent retrospective was called 4Ls. Thinking about the last sprint, each participant brainstorms on Post-its for each of these 4 questions:
- What I Loved
- What I Learned
- What I Lacked
- What I Longed for
Once each participant put their Post-its onto the 4 different category posters, we split everyone into 4 sub teams, they read all the notes, identified patterns and reported their findings to the group.
What we found was the following -
- There were more “What I Loved” notes than any of the others (followed closely by the “What I Learned” category). This is good news!
- The subcategories under the “What I Loved” and "What I Learned" questions were:
- Biz dev
- The subcategories under the “What I Lacked” and “What I Longed for" questions were:
Once we had a solid discussion around all of the issues that were brought up, we started to narrow in on the key concerns around lack of TIME. Heavily related to this, is distractions. This seems to be a hot topic for us at Industrial these days. We have some great tools that help us communicate, but with additional communication, comes additional distraction. I will leave it up to a developer to write a blog post on the idea of context switching, but I will speak to the fact that the team requires solid blocks of “heads down” time in order to complete their sprint successfully. Things that have come up as “distractions” to achieving this are: meetings, Slack, Basecamp, and did I mention meetings? We need meetings in order to provide clarity and inclusivity, but it’s a delicate balance for developers and designers. As a result, we have come up with some rules as a team that will help cut distractions (and meetings) to a minimum:
- On the weeks that sprint ends, there will be meeting-free-zone where no meetings are allowed to be scheduled on Monday afternoons and all day Wednesdays.
- Mute all Slack channels that are not relevant to your day-to-day workflow
- All distractions (anything that was not planned at the beginning of sprint) must be approved by a Project Manager before it gets actioned
- Anyone can feel free to get up from their desk and go work in any quiet zone of the office or a nearby coffee shop, should they require some uninterrupted heads down time
When we first adopted Agile, we developed a Working Agreement as a team. We have honed that same agreement over the past couple years, which includes anything we have unanimously decided as a team is something we will all commit to doing.
This is what our Working Agreement currently looks like:
Agile is fundamental to our way of life at Industrial, allowing us to tackle our challenges openly with each other, continually iterating on how we do our jobs most effectively to service our clients. Just like our approach to client work, we continually iterate on our Working Agreement, our processes, and policies to provide the best possible working environment for our amazing staff.