4 Tools to Help Your Product Team Become More Effective
/
Product teams can be such a beautiful thing. Watching a group of people come together to make something awesome fills my heart with joy. But often it takes time and effort for a team to really come together and start gaining momentum.
In this article, I’ll talk about a few ways that you can help accelerate your team as they move towards becoming more effective. As you consider trying these ideas with your own team, please remember that every team is unique. As product managers, scrum masters, and leaders, we should aim to defer to the team when it comes to solving problems. When they need a nudge or some structure, give these ideas a try.
Working Agreements
Working agreements can be a powerful tool for helping a team quickly come together towards a common goal. Often, the things that prevent teams from reaching their goals have nothing to do with the work. On one team, I had an engineer who consistently struggled to complete his assigned stories. Turns out he hated a dirty workspace, and his neighbor was incredibly messy — candy wrappers, soda cans, used tissues — all left on his workspace. Going through a team working agreement exercise helped uncover this problem, along with many others.
A team working agreement is very simple. It’s just a listing of items that are important to the team, and that the team agrees to abide by. In the resources section at the end of this article, I’ve linked to a simple exercise you can facilitate for your team. Using sticky notes, or a virtual alternative (like Trello.com or FunRetro.io), your team writes down what’s important to them. Common topics include: stand-up time and attendance, virtual attendance options, food day requests, taking personal calls to a separate space, and the list goes on. I am constantly amazed by the items that make it into team working agreements. Let your team amaze you too!
Daily Standup
There are so many things we could say about daily standups. And so much of it is bad. Think back to all the bad daily standup routines you’ve been a part of. I know for me it’s too many to count. But, if done right, the daily standup can be such a powerful tool to help a team make forward progress every single day. There are as many standup routines as there are teams, and there is no right answer. Shorter is almost always better, and standups should be focused (no rambling!). It can take time, and individual coaching of team members to get there. But once you have an effective daily standup, the dynamic of your entire team can significantly improve.
Standups should grow and evolve with your team. When a team is just forming, I’ll often set the focus for standup on blockers. If there is anything blocking your progress, bring it up in standup. That is an easy routine for people to get their head around. Then, as the team matures, it can change to blockers plus important updates. Importance is determined by the team, and the team should hold each other accountable.
When a team is struggling with cohesion, especially between technical roles and business or product roles, I often go against the common advice and have the product owners/managers or business analysts speak out in standup as well. This helps build transparency and trust, as well as building a foundational knowledge of what those roles do on a daily basis and the value they provide to the team.
With a team size of 6–10 people, I don’t like standups to last more than about 8 minutes. Everyone should be able to complete their own speaking portion in less than 60 seconds. The exception would be when there is a problem that needs the team’s help; that should be taken outside the standup as a separate conversation.
By keeping the standup focused and less than 10 minutes, the team will learn to consider them just another part of their daily routine. If your team is vocal about hating standup, or you have trouble with attendance, you’re doing them wrong!
Blameless Retrospectives
Most agile teams use a retrospective at the end of their sprints. Retros are a time for the team to talk about what worked and what didn’t, and to plan to avoid the same problems in the future. I suggest adding a slight twist to your retros, by setting the expectation that they are blameless. Agile teams make mistakes, and sometimes software doesn’t work the way we planned. Also, teams are made up of humans and sometimes humans act in ways that hurt feelings and cause tension.
If we start our retrospective with the expectation that there is no blame, the team owns everything. The team identifies a problem, and the team fixes it. Sometimes retrospectives can be incredibly challenging because we are all human and we all have feelings and anxieties and triggers. But if we start the tough conversations with the understanding that there is no blame, and we leave the retrospective committed to starting fresh, the team is better for it.
Honoring Commitments
Honoring team commitments is more of a culture and less of an “activity”. When a team is working in a manner where they pull work into a sprint and commit to it — sometimes teams will not meet that commitment by the end of the sprint. When this happens occasionally it isn’t necessarily a problem, but some teams get into a routine of carrying work over from sprint to sprint. This is a team integrity problem. Most of the time, teams should be delivering on what they commit to.
I once came onto a team that had been carrying work over for so long that they couldn’t remember when they last started a sprint with no carry-over work. I used an analogy to help them understand that they didn’t have to work like this. The start of a sprint is like the first day of school. It’s fresh and new and shiny, and it should be full of hope. When we carry work over consistently, we cheat ourselves of that hope because we know that we won’t finish what we start. Over time this can become very demoralizing for a team.
With the team I mentioned above, I set a guideline that we wouldn’t pull any new work into a sprint until we had finished all of our carry-over work. It took two sprints (four weeks), but they got it all finished. Then we started fresh, and when we went into planning for the first time without any carry-over work, I bought them all boxes of crayons. Like the first day of school! That was a simple, inexpensive way to celebrate the accomplishment that had been so elusive for the team.
Conclusion
Every leader needs a variety of tools in their toolbox. Because every team is unique, variety is critical. Try your favorite ideas, and if those don’t work, break out some of your lesser used ideas. Inspecting and adapting isn’t just for your software — you can use the same approach as a leader. Try an idea, and if it doesn’t work then try another idea. There is a seemingly endless supply of ideas you can use with your teams. Don’t stop trying! Eventually, you will find something that clicks with your team or something that solves a problem your team is dealing with. These are only four of many ideas that can be used together or separately to help amplify the awesome your team brings.
Resources