Five Tips for Effective Teams

Time after time, whenever I start working in a new team, I find myself gravitating towards the same five practices. I find that once they are in place, our day-to-day work seems to become smoother.

Single backlog for all work items

One of the first things I do when I start in a new place is to consolidate all the work requests addressed to the development team. Requests might come from different tools, but I try to get them into a single backlog before a team is asked to work on them (luckily, some smart integrations can make such magic happen). Instead of going through multiple backlogs in different tools, we aim for user stories, bugs, maintenance work, random requests in the same list. This makes it easier for developers to find out what their next work item is, for product owners to prioritise the work and for everyone else to know what the team is actually working on in any given moment.

Communicate intent and results

There are many voices in the product management community promoting that a good solution is the result of the collaborative work of product, engineering and design teams.

When we work from a shared understanding, it’s much easier to agree on the best path forward.

Core Concept: Collaborative Decision-Making in a Product Trio – Teresa Torres

Rather than throwing requests over the wall that might or might not make sense, it’s easier to communicate “why” something needs to be build or, even better, involve the team early on to know themselves the reasons.

Even further, I think there is also value in keeping teams up to date with the success or failure of a new feature. Knowing why you do what you are asked to do as well as what impact it made, provides a sense of ownership and pride of your work.

Respect development recommendations

If you have watched any documentaries about big disasters, you will notice that they usually boil down to “as engineers we were too afraid/embarrassed to speak” or “the engineers warned us, but we didn’t listen” (here is an example, a documentary about the Challenger disaster). My experience is that people don’t come up with maintenance requests just for the fun of it. Either the existing situation hinders their work, or they see a risk approaching due to unmaintainable circumstances. Creating an environment where people feel safe to bring forward work that is not necessarily obvious but necessary, not only can avert failures but it can also prove beneficial for the evolution of your product in the long run.

Bring everyone along

I have yet to encounter a team that all the members have the same level of technical capabilities. That is usually due to lack of experience. That might be not only because they have not been around long enough but also because they were never given the time or opportunity to work on complex problems with someone more experienced than themselves. If it is true that “a chain is no stronger than its weakest link”, then it does make good sense for everyone to help the weaker link get stronger. Enabling people to pair on tasks helps knowledge distribution, reduces bottlenecks and makes work more fun.

---

Even though I find these five practices extremely useful to help teams work in an agile manner I don’t set it as my goal to implement them. Every team has its own maturity and can handle any transformation on their own pace. But I do stand by them and aim to work in teams that find them useful as well.