Communication levels

Usually, communication levels are a mix of confusion and they tend to be mistreated inside a software development process. The majority of the companies are victims of an irrational phenomenon, on which different teams struggling to synchronize actions and dependencies for achieving common goals, but with no real effect. The problem appears so often that is almost impossible to fix, unless the communication hierarchies are redefined from scratch.

The delegation of responsibility to people with no real authority, while there is the expectation from them to define a common direction among teams is at best pointless. If everyone can submit a requests against Team B and anyone can receive a request from Team A at all levels, without any restrictions, then a chaotic model defines communication. Although chaotic models have there own amazing order, and that’s why actually companies sometimes succeed to deliver a product, that order is not optimal for software development. In these situations, there is no co-ordination, no accountability, changes are hard to track, architecture remains a virtual concept and dependencies across teams become a daily nightmare.

Therefore, by having as pre-requisite the MAD hierarchy, the MAD model suggests a system for communication that is based on formal ranking, similar to the military system. The roles that people have inside the company they now start having real power and meaning. They actually define to which people are able to talk directly from another team. The communication happens progressively in a bi-directional trend from lower to upper layers and vice versa. As long as there is no agreement at any level, the information is passed to the different rankings, until it reaches the highest ranking (e.g. Director), who decides the final actions. In combination with the proposed MAD hierarchy, the communication levels are now structured and clear (see figure above).

Building teams

MAD contradicts the perception that having a scrum team is always the equivalent of having an efficient or productive team. The reason is that scrum teams are usually lacking of the absolute authority for decision making and although their size supposed to be small, in practice that is only a virtual concept. When a team is not autonomous, shares responsibilities and complex dependencies with other teams and it does not have a dedicated Architect and Manager, then the team considers to be abstract. Accountability is lost in the process, synchronization becomes difficult to manage and cross-scrum communication introduces bottlenecks.

In an attempt to minimize the obvious overheads, the MAD model proposes the autonomous teams. The fundamental difference is that in order to form a new autonomous team, a number of basic requirements must be first satisfied. These requirements will help to improve accountability, control over dependencies and communication across teams.

Basic requirements

Each created team must have a very small size, no more than 7 people, including the Architect and the Manager. The deliverables of the team are distinct and as independent as possible from the ones of any other team. Even if that independence is not always possible, the overall architecture of the product must have as a goal to design self-contained and re-usable components, with minimum hard links. Only then, these components could be distributed across different teams for being implemented, without any strong bindings. Potentially, these teams could be seen as some kind of feature teams, but with complete ownership of the feature, exclusive authority over the feature and the absolute responsibility.

Recruiting process

The most important process for building a team is the recruiting process. The criteria on which you choose the members of a team is one of the hardest, but also the most crucial tasks. The selection must be done wisely.

In the MAD model the responsibility for recruiting is very clear (see figure above). The Architect is the one that will have to choose the right members for the team and build the team the way he desires. In this effort, he could probably get the advice of Senior Developers, but at the end he has always the final call. The Manager will get recruiting requests from the Architect. If it is a new hire, the Manager will have to approve the budget. Otherwise, if it is an internal moving the Manager will have to arrange to move the Developer into his new team, when that is possible.

The main difference against the usual process of recruiting compared to the one described here, is the fact that authorities and responsibilities now have a dedicated owner. The impact for an Architect if the team members are not sufficiently qualified for the position will be enormous. It becomes obvious that it is of the Architect’s main interest to find the right people for the new team, as he will be fully accountable for the end results. The same way that a coach is for any sports team. Therefore, by delegating the full control of the recruitment process into the Architect, it is strongly believed that the recruiting standards will be raised accordingly.

Conclusions

This article discussed the agile manifesto and how companies usually misinterpret the core ideas behind it. It argued that the agile practices should not be considered as the one and only way to develop software and it highlighted some of the reasons. It described how other systems that do not develop software function and it proposed a core-baseline around that concept, called the Manager Architect Developers (MAD) model.

Although the suggested MAD model does not constitute a new methodology, someone could easily follow, adopt and build on top of that minimal model. The simplistic structure of hierarchies and the delegation of responsibilities constitute a strong foundation for efficiency and productivity. In conclusion, the intention of this article was to initiate a different way of thinking around the software development process and present an alternative, inspired mainly from other environments.