ReOrg

This might be something that IT people don’t like to hear. Coming together with Reorg is normally layoff. Even with no layoff, changes will happen for sure. Who will stay and who will move to a new team.

Changes have to happen in order to have a real transformation. I remember the days when we had about 15 people for standup and very often standup last for more than an hour. Though this definitely can be improved a little bit by reminding people to keep the standup short. It is not that practical having so many people in a team. Splitting teams so each team can be more efficient. Before that, redefine the products.

We used to have all layered structures and teams. Back-end service team. Back-back end service team. Application team or even just a UI layer team. Sometimes it could be just one person. One person take care of an application. Another person take care of a service. Then they belong to different teams. Those days we call them functional teams. They are horizontally layered teams.

We want the teams to be for different products. The team will take care of all layers of a small slice of defined product, or a set of features, so that if there is any new feature or change needed, the changes will be taken care of by people within a team, instead of a lot of handover and coordinations between different teams.

Within the team, it is important that anyone will be able to work on any area of the product, instead of each person only works on a specific area. Otherwise there will be a lot of dependencies and handovers. But how to make anyone capable to work on any area? Pairing is the solution for that. We will talk more about pairing later.