Is your task backlog getting packed? Is it getting hard to manage priorities? Maybe the problem is with how well your development tasks are being “cooked”!
This blog post is about āfeeding the beastā. Yes you read that right:)
In early stage product-led startups, the largest department in size and in cost is the engineering team. Often referred to internally at Swimm as āthe beastā. The way we feed the beast will directly affect the product, the progress of the product, and the company. Therefore, it’s important to keep them fully utilized.
Just talking about feeding the beast to keep them busy is overly simplistic. Maximizing the utilization of this team is not enough. We don’t just need to keep them busy. We need to talk about maximizing results, which means working on making development more efficient and producing a successful product.
This is what we learned from our growing dev team at Swimm and cooking up or prioritizing delicious development tasks for our sprints (internally called heats).
Developers – this blog post can be shared with stakeholders who feed the beast in your organizations, including sales, product, marketing and DevRel, as well as the people who translate user feedback and customer requests into development tasks. You can use it to improve the way they feed the beast at your company.
Meet the chefs š§š¼āš³šØš¼āš³
Where is the food coming from? Everywhere across the board from Sales to product roadmap, user feedback or Marketing.
When the different departments supply feedback, they generate grocery items, not the actual food. And the beast, it doesnāt like to cook, so to speak. We need to take the pile of groceries and cook for the beast, to ensure it will be utilized in the best way.
So meet the chefs – the product team! The product team slices, dices and creates meals for the beast from all the groceries. Here at Swimm we are still working on the best recipe and cooking methods, but first, letās understand how to detect the symptoms.
Detecting when the food is bad š¤¢
So what are the signals that the food is bad?
- Procrastination – A āwell fedā developer will happily jump into implementing itās pending tasks. The first signal for untasty food is when it stays on the plate (or in the task management tool you use) for too long. Devās might touch it sometimes, but don’t eat it.
Procrastination causes task hoarding and makes it hard to understand what is finished and what needs more attention. - Pushbacks – A āwell fedā developer is an enabler, a one that believes that everything is possible. When you start getting push backs like āWe canāt do that in the current frameworkā or āit will take a lot of timeā or āit requires a massive refactoringā often it means that the beast is upset and there is something wrong with the food.
Pushbacks create friction and energy is lost for the wrong cause. - Alienation – Us vs. Them – A āwell fedā developer understands the joint effort and usually talks using the word āweā. When the beast starts to use the term āthe product teamā or āyouā or āThemā it is a good sign for poisoned food. Alienation causes delegation loops and breaks collaboration.
Itās all about the title
All of the symptoms above are wasting your team’s energy, tasks repeatedly overspill from one sprint to another and eventually causing you to miss the deadlines. Some of them can be avoided by the way we write our tasks.
A good task starts with a good title, good titles help developers understand and estimate the task better, managers to decide who to assign the task to and product managers to prioritize more easily and get a clear picture of a sprintās contents.
Letās look at some practical tips on writing good task titles.
Tip #1: Donāt delegate work
No one likes to do other peopleās work, so donāt delegate yours to the engineer. Specify all the details so the developer can go straight to fixing the problem, instead of trying to figure out what needs to be done. If an issue needs more product work, do it before assigning a task to a version. If youāre cutting corners, the devs will feel it.
Tip #2: Be explicit
If it is too ambiguous and requires a meeting with someone it will be postponed.
When you open the fridge hungry you just wanna grab something…
Tip #3: Be concise
A very long title makes it hard to understand the problem, it will usually cause confusion. This is where we need to balance, making it too short might break the previous tip and make it ambiguous.
Tip #4: Avoid internal terms
Terms change. In time things that we know now will be forgotten, and requires onboarding.
Tip #5: Delete generic tasks
Delete tasks that are always true, like āMake performance betterā. Itās obvious…. Unless you are making a specific effort (that needs to be explained) this task will just linger in your backlog forever, making it hard to see other tasks.
Priorities and development tasks
There are two main things Iād like to emphasize about prioritization.
Small t-shirts first
Sometimes itās hard to get the easy stuff done, and it gets postponed from version to version. This is why we created the āsmall t-shirt šā label , which is what we call small dev tasks. At the beginning of sprints we all sit together for two hours and each developer fixes two small t-shirt labeled tasks.
The boy who cried wolf
It is not uncommon to use the label āurgentā too many times as a means to indicate priority. It quickly loses its meaning. Thatās why there are a lot of urgent tasks that just get postponed to the next version. So we force ourselves to be mindful and think hard about what is really āurgentā in priority.
A better way to frame this could be thinking about the impact on the product, and not the deadline. We need to differentiate between urgency and impact. Another name for this is actually āblockingā — meaning, questioning if a version cannot go live without this tasks.
Conclusions on upgrading your task recipe:
Many times a dev tasks needs another round of cooking before it can be served as food to the R&D team.
All in all, the secret ingredients boil down to a detailed account of the task, its area in the code or product, the action it requires (fix/create/redirect) the logic and its importance. It starts with a good compelling title that the team might want to open to begin with.
By writing clear and concise tasksā titles, you can ensure the engineering team will manage and resolve your tasks quickly and efficiently.
…
If you want to see Swimm’s knowledge management tool for code, sign up for a 1:1 Swimm demo.