Updated: Jun 14, 2020
Over the course of last year, the Bear Analytics team has been meticulously looking into ways for improving our team’s efficiency. During that time, agile management has emerged as a fundamental approach not only applicable to software development, but as a useful tool for team project management.
By way of a brief background, agile is an approach by which teams break large projects into more manageable tasks, which are tackled in short iterations. The goal is to provide more clarity on how to prioritize tasks, who is accountable, and most of all, enable a collaborative nature to getting work done.
I had my doubts about agile for months. I was wrong. It works and it works well.
Fast forward to today. We’ve been having conversation after conversation with event professionals who are tasked with pivoting their in-person events to virtual(or hybrid), assessing new business models, trying to renegotiate contracts with partners, all the while maintaining a level of care for their customers. It became evident that some of these agile tactics can help when the situation demands getting more done in a rapidly-evolving environment.
1. Instituted morning and evening standups. Simple in idea, yet hard in execution. A standup is meant to be a brief and highly focused meeting where each team member is afforded the ability to describe what they’re working on and where they are blocked. It took us ~4-5 months to get these from ~30 or 40-minute meetings, down to the 11-15 minute meetings they are today. Simple in principle, hard to execute. A few tips, blockers aren’t criticisms and radical transparency helps identify where the inefficiencies are – focus on the uncomfortable.
Collectively, we found that team members can often feel as if they are on an island, only looking inward for solutions to their problems. However, by bookending each day with a standup, other members began to offer their time or advice, putting onus on the team and not the individual. In terms of efficiency, daily standups lead to less rework and improved quality. Teammates were now able to express concerns as they arose and not wait for issues to pile up. This was a major inefficiency center for us as a team.
2. Adhered to project management fundamentals. Personally, this is something I struggle with MIGHTLY. I like visioning and strategy work, but it has become clear that our objectives as a company can only come into fruition if there is a pathway to execution. That pathway for us is paved in Asana, a web platform that help teams organize, track, and manager their work. This tool enables us to create bespoke project templates, collaborate on tasks, and hold each other accountable. We also use the time tracking application Harvest, which integrates nicely with Asana, and allows us to marry together specific team inputs and map them to client projects and specific project work areas - down to the task and sub-task level! When it’s rolled up, you can really start to pinpoint inefficiency – more on that later.
3. Setup team sprint boards. Calibrating a team to understand exactly how much they could get done in one day, one week, and one month is/was the hardest part. People are notoriously poor estimators; our team was no exception. How did we overcome this? It was simple, we kept pushing the team to break project goals into smaller and smaller segments and then taking advantage of our Harvest reports to support their estimation efforts on these fundamental tasks.
The result was a group who felt more in command of their daily efforts, felt progress more regularly, and were self-taught on tagging in a Bear buddy when they came to a blocker. There is also a sense of reward in crossing off a task/project segment and being able to step back and look at how that contributed to the entire team’s efforts for that sprint. This practices instilled purpose within each team member, which I believe motivates our best work.
Ultimately, agile is based on the principles of focused flexibility. You need to leave room for change and evolution. We didn’t this get right the first time, and from everyone we’ve talked to – no one has. Also, for our purposes, agile isn’t something that felt right as a strict adoption – we just did it, tweaked it, and continue to tweak it based on what the data is tell us we’re still struggling with.
This is part 1 of 3, in a blog series focused on agile teams. In the next installment we’re going to be covering the macro and micro reward mechanisms that we instituted to properly incentivize the team to keep getting better. From there, we’ll speak to how we analyzed our own data to find gaps to fill in our process and workflows.
If you’re interested in learning more about how we made the conversion to agile and its many benefits, feel free to reach out to us directly at firstname.lastname@example.org