What is and what is not Team as a Service (TaaS)?
For months, social distancing measures have forced us to telework. Luckily, we already teleworked assiduously before and, although Team as a Services is not directly related to teleworking, it does benefit from this work modality.
Team as a Service (hereinafter TaaS) is both a product and an organizational proposal. Opentrends has already offered this service for a couple of years now but, in the middle of the COVID19 tsunami, it acquires the denomination of "mandatory" in terms of software development.
I say that TaaS is a product because at Opentrends we have quantified the prices and the service conditions, in the absence of agreeing on the scope and duration of the project for each specific case. And I also say that it is an organizational proposal because it is not about putting together a group of people starting from scratch to listen to the client ... it is not bodyshopping. TaaS has a precise organization that, even though it can be adapted in particular details to the specific project, it must respect a well-defined basic structure.
But then, how is TaaS different from any other way of organizing a work team? The distinguishing element are the conductive values. These values are not exclusive to TaaS, as they are found in some well-known software development and project management methodologies. At TaaS, we have made our own little manifesto based on the knowledge achieved during decades of experience in IT projects.
- Shared responsibility: the whole team takes part in the decision-making, so that any member is empowered to suggest improvements in the methodology, identify risks, accept responsibilities (or delegate them). All team members are permanently informed of the project goals, its current status and what other members are doing.
- Fellowship: vital for a good collaboration. Above all, this is what is needed for the TaaS to work, an open collaboration among all team members and also with the client. Since fellowship works better in small teams, of no more than 10 people, we keep TaaS teams below that number. There is no reason why there should not be more than one TaaS team working on the same project if its scope requires it.
- Transparency: it must be the same as the one of a good Japanese restaurant that allows its customers to see the work in the kitchen from behind a glass. Given that the TaaS team works remotely, and not in person at the client's offices, transparency is materialized by the publication of the work carried out in an online tool accessed by both team members and the client.
- Daily update: it is essential. The discipline of daily updating the progress achieved allows the early detection of deviations and facilitates their mitigation. In fact, knowing that progress is reviewed every day psychologically predisposes to achieving small goals in pursuit of the overall project goals. The risks of the project are daily reviewed, and the locks or dependencies between tasks are also shared.
- Trust, among team members and with the client. In the TaaS model, the client can act as another member of the team. He is informed of everything and can access anything at any time, as all information is in the cloud.
It is also necessary to bear in mind the elements that avoid the TaaS to work. These are some of the fallacious points on which it is easy to fall and that, despite their apparent value, they are often more an impediment than an effective help:
- Tools: sometimes, it seems that more than tools, we use toys. We have seen so many times how the organization of a project has been entrusted to the used tool, as if everything were going to work well just because we are using a very expensive software. It is one of the most astonishingly widespread fallacies in our field. A good TaaS can work simply with a pencil and some paper, although it would be a bit absurd to do that. We can use Redmine, Jira, Trello, Miro ... the possibilities are infinite and, at the end, the tool does not matter; what really matters is how it is used.
- Methodological fanaticism: the line that separates rigor from fanaticism in project management methodologies is amazingly blurred. By coincidence in general guidelines, iterative methodologies suit better with TaaS than cascade methodologies. This does not mean that cascade methodologies cannot be applied, but their application may require a higher effort. That said, methodologies are like laws: they cannot foresee all cases in the universe and just as there is something called “the spirit of the law”, that applies when letters lead to confusion, there is also “the spirit of methodology”, which allows to assume degrees of freedom when we come to unexpected events.
- Centralization: one of the greatest fears of any traditional project manager is decentralization. The need to "get everything under control" can become really compulsive and should be avoided at all costs. Each member of a TaaS team has their responsibility and and accepts it, including the client.
In summary, TAAS is directly inspired by the Agile manifesto (be careful, by its manifesto, not its methodologies) and, above all, it pursues cooperation, sustainable progress and continuous improvement.