Shape Up, Composing the teams
It is one of the articles in the Shape Up series.
For Table of Contents go to: How to make Shape Up successful?
In many of Basecamp's writings, they mention small teams of 1 or 2 engineers and 1 designer. As we like to aim for the extreme, we may believe all projects might be built in such a team composition. Many of them do, but not all of them.
How we compose a single Shape Up team will depend on many factors, including the system’s complexity, the company’s culture, the people's skillset, and more.
Most likely, you need to find your way of composing the teams for your organisation. However, I do agree with Basecamp’s message of “try getting work done in small team“.
When composing the teams, it’s worth remembering that each individual has strengths, weaknesses, and preferences. Another aspect worth considering is whether people might be allocated to the projects in a top-down or bottom-up way.
When does allocation happen?
It may happen on the very first day of the Building phase. However, I found that doing the allocations 2 or 3 days before the Building phase starts, led me to better-organised kickoffs and higher psychological safety of the people.
Bipolarities of who we are
To compose the teams effectively, we need to understand that we are all different and similar at the same time.
The way we work today as individuals is the effect of all events in our lives, starting from childhood and going through education, personal experiences, and corporate ones. When we’re on a project, at a specific moment, we have limited control over changing who the person is. What’s more, we shouldn’t be doing that. We can mainly influence the environment around people to enable them to do their best work, and we can allow them to keep growing at pace.
If we are really thinking about changing others, we may ask ourselves what our personal need or desire towards them makes us want it.
As we have limited possibilities for changing others, we may try to understand each other and enable them to shine through what they already have inside. This is also where coaching applies.
Below, I mention a few polar behaviours or skills you may consider when composing the team for a Shape Up project. It is not a complete list and not a guideline. What I want to achieve here is to show you different dimensions, that you can use to visualise properties for composing the teams on a scale, not as a binary game.
Backend vs Frontend
This is quite an obvious one. A project may require frontend and backend skills, and you may automatically apply this allocation strategy on top of everything else. From my experience, when we put this perspective on top of everything, the team members fall into the trap of splitting into two sub-teams, the backend team and frontend team, during the project's execution. They might create separate tasks prefixed with “BE” or “FE”. They might be stubbing API endpoints to proceed with the frontend’s implementation faster.
But… considering that Shape Up projects and teams are small. Should they be even doing that? Having a few full-stack engineers may help crash this wall. However, even when we choose to specialize, we should still focus on collaboration and getting something done together instead of working separately and then integrating. It starts with understanding the person of another specialization and seeing a shared success as a goal instead of aiming for “finishing my part faster”.
Planning vs Just-in-time
The article about project planning mentions how people experience the time dimension. While planning is the most crucial step in the project, I understand that some people have this strategic mindset of seeing the world through a series of events over time, but some live just-in-time.
If you plan to put too high pressure on project planning on just-in-time people, you may experience a strong pushback. Building planning skills and mindset in them is a long journey.
When composing the team, you may consider whether the project is well-defined and requires just the delivery of the known solution. Or maybe it is an R&D requiring much fast-spiking or prototyping.
In addition to understanding the project type, you may consider how many people in the team should have the planning mindset and how many may work more chaotically. There is no universal answer for that; it differs between the projects.
Tasks vs No-tasks
Writing scopes, tasks, stories, or jobs-to-be-done down is also connected with planning. Some people like it, other people don’t. In my personal opinion, writing things down always helps in delivering the projects - period. However, considering the preferences of many different people, we may think about the level of detail that such written tasks should contain. Sometimes, the level of details of what we write down might be on the project level, sometimes on the scope level, sometimes on a user story level, and sometimes on the sub-tasks level.
Speaking about team composition, when you combine two people, one who is a fan of writing everything down and the other one who hates it - they might be pissing each other off when it comes to scoping and issue tracking. In such a scenario, they may need a little more time to align. As Shape Up projects are short, sometimes there is no time, and this is why well-executed kickoffs help.
Talkers vs Writers
Continuing the writing topic, we may also experience that some people want to talk for ages, while others like to write too long documents. While I am a fan of saying that writing is thinking, I also believe real-time collaboration is much more effective at specific project moments.
Considering the team members' preferences for talking or writing is yet another factor that will influence the team’s dynamics.
Architects vs Coders
When mentioning the above talking or writing, some people prefer a very high level of spoken agreement about how something should work. On the other hand, other people will prefer RFC, Tech Design, or Working Backwards Documents to plan the technical design.
In my opinion, every engineering project that takes more than one week to complete should have some technical design prepared before implementation. This might be in the form of writing or diagramming. But how does it work for your organization?
Domain-Experts vs Domain-Newbies
And then, on top of every personal preference, behaviour and skill set, we may also put the current knowledge about some specific area of the business domain or the system. Most commonly, we may always allocate the people with the most considerable knowledge about some particular area or component.
However, this is not going to reduce our bus factor. Do we know if people prefer to deepen their understanding in some area or learn something new on a business domain level?
People-to-project allocation
In the end, someone must be picked to deliver a specific project. It might be done in a few different ways.
Top-down allocation
This is an approach in which leadership/management allocates people to specific projects that will be delivered in the upcoming Shape Up Cycle.
When doing such an exercise, they may realize that some projects will take the whole cycle while other ones will take half of it, which means some people or teams may work on two projects within the entire cycle.
After solving this puzzle, leadership may communicate the assignments to the people.
Bottom-up allocation
On the other hand, allocation might be the job of individual contributors, especially in environments where we want everyone to be a leader. We can communicate the list of betted projects, and we may let them self-organize around them, giving them 1 or 2 days for that. As managers, we may take the coaching approach of participation in this process, but not the leading one.
To set some boundaries, we may communicate, “Go through the project pitches and work on the allocation. In case of no plan by Monday 13:00; we will prepare the allocation and share it with you on Monday at 15:00.”. This message enables the team members to get higher ownership and feel more accountability for cycle’s success. They can express their personal needs more efficiently and they can let managers know how they want to work.
From my experience, this way of working with people-to-project allocation is much more effective because engineers and designers who receive coaching usually prepare much more effective cycle execution plans than most managers do.
Visualisation
Speaking about making it effective, visualisation works… the old good friend - the Gantt Chart may help the team with this very early stage of the Cycle’s execution planning, which is the project-to-people allocation. Especially, when there are a few smaller projects and someone needs to work on more than one during the Cycle.
Alternatively, if you want to feel more agile, you can use post-its on a virtual board.
What’s next?
Each project starts with a project kickoff. Let’s dig into it.