Shared Software Team
If you as a customer want software developed, supported & maintained - but the size of your project is such that it doesn't require a full time person, let alone a software team of multiple people - then shared software team is an option for you. Some examples of where it can be commonly seen.
- B2B product implementation / customisation projects
- CMS (like Wordpress) based website development
- Small custom application development projects
It is lot more common for smaller business customers and non-profits organisations. In my experience when in large business software projects - this was rarely seen.
What problem it solves and how
When the software needs to be developed over disjointed periods of time, it may need technical support in an unpredictable manner (at any point in time). A shared software team can solve this problem. As the name suggests there is a permanent software team that works on these multiple software projects and provides production support for them. While the projects start, stop, end, resume, etc - the team is always in place and busy working on some project or the other.
Such software teams are built around a theme. The theme could be a product (like Avni, Wordpress) or simple applications developed on common tech stack (like Ruby on Rails, Django, etc). This theme allows the team members to be able to switch across projects and still be quite productive.
Economically a shared team, helps the customers in not having to pay for software services when they have no work to be done while still having a team that they can depend on when they do have work. It is also a fit for the need of ongoing production support that can be provided by the team - on continuos basis.
The above is quite an intuitive idea and that is why shared teams are quite prevalent. But the downsides or tradeoffs are not quite obvious and well understood - at least it was not for me. Lack of awareness of these downsides can make the experience of the software teams as well as that of customers quite frustrating and unpleasant. Customers may even believe that their software team is not capable while the issues often are inherent to the model itself. The main goal of this article it to enumerate and explain these tradeoffs.
A shared software team technically works because of the familiarity with the codebases across projects. The familiarity come from uniformity due to - common approach, language, libraries, code pattern etc. The less uniform the code is, even on the same platform, lesser the number of projects the team will scale to. Standardisation is key. It could be enforced by the underlying platform (done quite well by Wordpress and web in general) or by the software team themselves.
Tradeoffs and constraints of Shared Team model
- Unless the team is created for a specific domain - the domain of the customers can be many. This means that the software team is really not an expert in any of the domain.
- Discontinuity has cost for software team. Even for the same person working on a project, coming back after 3-6 months may mean significant loss of context and understanding. This is especially severe for production support. The customers on the other hand, have no discontinuity on their side as they are using the software regularly. The loss of context causes basic errors that is difficult to accept / appreciate for the customers. Customers may end up explaining the same business / domain concepts and sharing same information with "each new person". This can be frustrating for them.
- I have found that switching across software projects is psychologically quite demanding for all members / roles of the software team. From their perspective as soon as they start becoming comfortable with a codebase/project/domain/customer they have to switch to another project.
- Attrition in team members has severe negative impact on shared teams than a dedicated team. One person leaving may take away significant percentage of context for any given customer, if not nearly 100% sometimes. This is a risk that customer carries.
What one customers and the software team do?
- It is better to work in larger batches as much as possible. It is better to batch smaller requirements, from a customer, over time into a small project and then execute in one go than work on them in smaller sizes. This reduces discontinuity in work and switching to some extent.
- It is better for customers to have more quality safe-guards on their end compared to dedicated team software projects. The defect rates, after first release, are likely to be high from shared teams.
- People with some technology skills on customer end can be quite a boon in these arrangements. Such people lend continuity, context, and specific technical skills that the shared software team lacks, by its design.
- Sustainable and useful documentation. Good documentation can help team members new to that project to learn quickly - but it has to be done well and then used too. Having said this - increasingly I find people have lesser appetite to learn from documentation and show preference for learning by working oneself as well as learning orally from other team members. The team should decide based on their own context on this item.
- Customers should ask the software team to explain their working model - so that they can also adapt their own processes based on this.
- Finally - I believe the most helpful thing is to reset expectations if one has worked in or with dedicated software team. These expectations are unlikely to be met and may cause only frustrations to all involved. And of course nothing like having a permanent team.
What one should avoid?
- Avoid non-standard type of work, even if it is technically possible for the team. Always ask the question will someone else in your team able to understand this after 6 months. It is very important to reflect and understand what is "standard" work. The scalibility of the software team depends on this. It is possible that both team and customers may want non-standard projects. The team may want it as it provides some diversity in work. This is where the "business" should come in and decide whether it is a good idea from long term perspective or not.
- Sometimes frustrated customers may want to the take path of creating their own in-house software team at reduced cost so that they have a permanent team. But in my view, it is quite difficult to pull this off for non-profits. We have written about this.
Other relevant articles
- Difference between software platform and bespoke solution. How to make the choice? - https://www.samanvayfoundation.org/resources/software-platform-and-bespoke-solution
- The challenge of building technology team in nonprofit organisations - https://www.samanvayfoundation.org/resources/the-challenge-of-building-technology-team-in-nonprofit-organisations
- Domain expertise doesn't travel from high-resource to a low-resource setup - https://www.samanvayfoundation.org/resources/domain-expertise-doesnt-travel-from-high-resource-to-a-low-resource-setup
Credits
Cover image - https://www.canva.com/p/kanchanachitkhamma/
Author: Vivek Singh
Published on: 10 April 2024