How to decompose: the dull side
Before reading this, I suggest to read the previous part first.
I hope this one will be short.
I aim to avoid bore whatever I do, including the management routines.
Which is the case when we're talking about decomposition.
Why do I aim for it?
I have no particular answer, except that everything dull, unnecessarily slow, stupid, and bureaucratic makes me unhappy, and, yes, I do try to avoid being unhappy.
Someone says that you should buck up and keep going, that the job is not an easy walk, and blah-blah-blah. I am just a different kind of person. Sometimes we have challenges and need to pull ourselves together, but I refuse to spend 'mana' on the boring routine meeting.
The same goes for the whole team. Another 5 hours in a week of decomposition and estimation would kill all the desire to work on the new feature way before the beginning. So we really want to avoid it, and I will show you how exactly.
Let's assume that we have a more or less well-designed product:
It has wireframes and maybe even a few screens
It has a description in any suitable format to digest
Everyone on the team was at the first kick-off meeting, where this new feature was presented
The first meeting
It should be within an as minimal group as possible.
You need someone who can answer the question 'what needs to be done' and someone responsible for the 'how' part. Those usually are team leads, leading engineers, leading product and UX people. It is nice if no more than four people hold the first meeting.
It is often beneficial to plan back-end and front-end (s) separately; necessary here is an APIs, communication, and trust, but it is a whole different story we will cover later.
The result should be the dependency graph you saw in the previous article.
How fine? Oh, that depends on the people at the meeting. If you get only high-level engineering managers there, the result would be trash.
You need someone who knows the application architecture (the author is best) at the table.
Let higher-level managers (maybe you) focus on other things and give engineering lead, architects, or how you call them, space and trust to do essential things.
But what is essential
Next, you have to be in the context of our Fridge Door Feature for SuperCompany's Chat.
At this stage (yes, we're still at the first meeting) crucial is to:
Understand the feature and how it fits the whole product.
How it fits the application design you already have: should we establish some significant changes or not? For example, should we develop it as a part of the Chat or as a separate application, and if so, how do we embed it and share the host application state and APIs? And much more questions immediately pop up.
What are the main modules that we have to build (the squares on the graph)
What is also important is that this and follow-up meetings are the best place for engineers to challenge the product and UX of the feature.
Now is the time to ask all the 'inconvenient' questions and get answers.
The purpose of meetings is not just the decomposition process. But also for everyone in the team to establish the same mental model of the feature. And digest it with all the dependencies and complications inside the application.
I will probably have another article later about that, but to emphasize how important it is for everyone to keep the whole application and how it works in their heads. Especially engineers: we love to put ourselves in the cage of the modules and abstractions we're working with.
Like, 'okay, I work only with the notifications APIs, and if you're discussing Drag&Drop design, I immediately distracted by that important cat video in TikTok.' Fuck, no! That's the thing you have to minimize; that's why you should keep meetings short and interesting.
Why? Because any modern application has a complex design and many features depend on each other. If people in the team are not focused on designing the system, then well, you're fucked, and eventually, you will have an application with a shitty codebase, and I am not the one to explain why it sucks.
Okay, what is next
We have a first or second version of the dependency graph from the initial circle meetings.
The next is to invite all the people who would work on that feature and do the same exercise.
If you have a team of thinkers, expect them to demolish your first versions, and another, a better one would take place — but it will take time. Try to shift and ground the discussion in a practical direction.
On the other hand, If the team is balanced, you will get a meaningful discussion, a relatively fast process, and yes, there will be some significant changes and add-ons to the first draft, which is precisely what you want.
And suppose your team has the majority of doers. In that case, they will take your design as given, without questioning. Later, during the execution, they would have to face its imperfectness, change it on the go and make the gap between the initial plan and result tremendously huge.
That is not what you want. Try to encourage the team to challenge the graph.
Is that's it? Well, almost
In the result dependency graph, you might find items that are not your team's responsibility and someone else in the company.
In this case, you need to take the initial narrow group and representatives from the team you depend on and do the same, or ensure that they would do it inside with the feature your team is requesting.
For example, for our Fridge Door feature, we need the integration with `Mentions,` which is not your team's responsibility.
You can assign or mention someone on the Sticker, and the name token should show the profile card when the pointer is over.
That works already at the main application, but it is limited to the chat history, and you have that shiny sub-application design we talked about. So basically, you need them to make `Mentions` decoupled from the `History` and have an API to consume in other places.
It might be something they already did but have not yet released, or the opposite: this disaster project will make the Mentions team rethink their whole design, and you might not like the answer.
Anyway, without solving all external dependencies on the graph, the result is not good enough to start a proper feature estimation, which is the topic of my next article.