Teams as a Service: What is it?
An introduction to success and challenges of Teams as a Service
Social distancing measures resulting from COVID have forced many into a prolonged state of telecommuting. Fortunately for Opentrends and many other tech companies remote working is not a challenge as we have been doing it for a long time. While our Teams As A Service (or TaaS) offering can be done physically in our client’s office, it was designed to be done remotely.
TaaS is a service product, but also an organizational model. It’s a product because it’s really plug and play - we have a quantification and pricing system that only requires knowing the scope of the project before it produces an estimate and a timeline. Although we launched this service 2 years prior to COVID as an ad-on system, it has grown to an organizational model due to the new working structures that have evolved out of the pandemic. Unlike most custom software or architecture development projects, TaaS does not require a consulting phase. TaaS is a modular adaptable team with a high degree of flexibility, only requiring an established backlog.
The main organizational difference between TaaS and all other organizational models lies in its core values:
- Shared responsibility: The team partakes in decision-making, each member is empowered to share new ideas, identify risks, accept or delegate tasks. All team members are aware of project goals in real-time and task distribution. This stewards teamwork.
- Companionship: A vital element for a successful project is open collaboration between members of the team, including our client. Companionship promotes this collaborative environment. Companionship works best with teams under 10 members, so multiple teams can be assembled to work on the same project and maintain the ideal team size.
- Transparency: Given that a TaaS team works remotely, visibility into their work is paramount. Transparency is accomplished by publishing completed work in an online tool that can be accessed by all members of the team as well as our client.
- Daily updates: It’s a fundamental piece of the puzzle. The daily discipline to update provides for early detection of anomalies and mitigation. Each day project risks are evaluated, while challenges and dependencies are discussed. It also predisposes the team to focus on small milestones that contribute to the overall completion of the project as opposed to longer goals which may cause lagging.
- Trust: In the TaaS model our client becomes an additional member of the team. The client is kept informed of everything and has access to every detail. Every part of the project is in the cloud and can be viewed at any time, anywhere.
It’s important to be aware of the elements that work against TaaS. Fallacies that may appear as valuable elements but end up slowing things down:
- Tool-centric: We have been witness too many times of over-relying on the tools used to plan, organize and manage a project, where the tool itself is the main focus and a barometer for success. It’s a lot more common than we’d like to see. The tool used should never be as important as how it’s used, because a good TaaS will work well with any tool.
- Methodology obsession: The line that separates stringency from fanaticism in project management methodologies is astonishingly fuzzy. Iterative methodologies tend to work better in TaaS. Waterfall methodologies almost always require a much larger effort to mitigate their increased risk, resulting in a lower on-time goal completion rate. Methodologies can’t account for every possibility and a capacity to improvise is required to successfully overcome the unexpected bumps on the road. This is why our TaaS is committed to the iterative Agile principles as opposed to being tied to a particular methodology.
- Centralizing authority: Traditional project managers fear decentralized teams. The need to have every detail under control can lead to negative consequences and must be avoided. Each member of the TaaS assumes a specific set of clearly defined responsibilities, including our client who must be able to identify the small milestones that will complete the project.
In conclusion, our TaaS was directly inspired by the Agile Manifesto (the principles, not its methodologies) and above all seeks cooperation, sustainable progress and continuous improvement.
With the many TaaS projects we’ve completed, we have achieved a consistent on-time delivery completion rate of 98%, which compared to the typical industry average of 85% (based on waterfall methodologies) solidifies the success of our TaaS offering.
We invite you to meet our TaaS leaders and learn how we can speed up custom software or architecture development for big and medium-sized companies.
Author: German Garcia, International Delivery Director