Product managers and developers love using Slack to manage their development process – whether that's reviewing and deploying code from Slack, tracking performance, resolving issues and bugs; Slack is the place where work happens for product and engineering teams.
With Polly, product managers and developers can now effectively measure and act on every workflow throughout their development process, thus becoming a more lean, mean, agile team.
Keep on reading to see how product and engineering teams today integrate Polly into their agile workflows!
More and more teams and companies don't fit the traditional office mold anymore – especially with the rise of remote workers and flexible business hours. When your colleagues work remotely or is working from home for just the day, moving your daily standup from an in-person interaction to a dedicated Slack channel makes participation for everyone easier and more efficient.
For daily standups, create a dedicated Slack channel called #daily-standup so the channel is focused and away from other channel clutter. In Polly, set up a recurring survey with the frequency set to daily (weekdays only) and the scheduled delivery in place of your normal sync time, with the following three or four questions:
Once you've set it up this one time, you won't ever need to again for future standups (minus any revisions).
Not only are your standups still just as effective, but it also removes the daily interruption of an in-person daily standup. By embracing this new habit of an asynchronous standup, your team will be a more lean, mean, and agile team. As the team lead, you can easily access your archive of all your team's responses for a more streamlined process that lives in Slack where you already work.
The modern engineering or product team don't work in silos – often times, there's a whole army of people working collaboratively on a project. From product, to engineering, to design, to marketing, to sales, it takes a lot of coordination to get a big new launch out the door.
Instead of living in silos and depending on your team's gut, get a better and more rounded worldview of how your project is going or how it went through feedback from your cross-collaborative teams.
To start, create a confidential survey so your audience's responses are anonymized and protected, but you are still able to compare and contrast responses across departments with existing demographic data.
The questions you choose to ask will vary greatly based on the project and/or product itself, but here's an example of the potential questions we might to all members of our cross-functional team soon after a big launch:
Regardless if you just launched a minor feature release, a major enhancement, version 1.0, or an MVP of the next big thing – all are equally worth celebrating about!
And while post-sprint retrospectives aren't exactly a new concept in the agile world, giving other departments a chance to be heard can be particularly more useful than just hearing from the team you sit on.
More importantly, making it an engineering-centric exercise limits the amount that you can really learn from the process. With Polly's filtering by response or by demographic attributes and cross-tabs, you can really dig into how the marketing team felt about the planning process versus your own product team.
A new feature/version release or product launch is hardly ever without some hiccups along the way. Whether that means reprioritization of features, unexpected bugs, QA and testing taking longer than expected, shipping on time can sometimes feel like you're sprinting a marathon.
Given that, you can prevent some unexpected mishaps by being proactive throughout the development process and checking in with your team often to uncover any roadblocks or potential issues before it's too late.
These can come in the form of weekly check-ins for a shorter project, bi-weekly or monthly for longer projects, or just once at the halfway point through a sprint.
Within your #release-planning channel (or whichever channel you use to for shipping products!), start by setting up a recurring survey with a frequency of your choice, depending on how long your sprint cycles normally are.
For our longer sprints at Polly when we're gearing up for a significant product release, we typically make them 2 weeks long instead of 1 week – with the entire initiative (or epic, if you will) spanning over multiple sprints.
Here's an example of some of the questions we might ask to gut check our progress:
For even the best product/engineering teams, sometimes you may find out too late that a significant percentage of stories aren't going to be completed by the end of the sprint.
Rather than scramble to re-prioritize (and inevitably throw more stories than expected back on the backlog), you can prevent underestimation mishaps from significantly affecting your sprint scope by getting frequent pulses on sprint progress.
Being actively aware and prepared for any mishaps that come up will provide for a much more flexible way for your team to respond to these types of situations accordingly. This keeps not only your team in check but your sanity in check as well.