The SICCAR team are working with CAST as part of Catalyst, to build a scalable and re-usable tech prototype to support referrals into and within the voluntary sector.
You can find a demo of the resulting Open Referral service directory here.
After successfully completing the 11-week project, we had the final retro meeting for the entire project. We identified that one of the contributing factors to the project’s success was the open working culture.
You may have heard of ‘open source’ in the context of software projects, but this is not what we mean when discussing open working. Open working fundamentally, is the SICCAR team and the CAST team coming together and working as one. It is an open culture based around collaboration and mutual trust. We were encouraged to communicate about the project not only together but also to our followers.
In practice, along with the software being open source, this allowed CAST to be a part of all of our project Sprint ceremonies. It also meant we would collaborate and chat together on a daily basis, for example via instant messaging, as if we were working with our own team.
Open working has its advantages whilst working in an agile methodology. As the client was available at the majority of the sprint meetings, we were able to resolve issues or improve on functionality in a more proactive way. This resulted in a well-refined product which not only matched what the customer required, but included enhanced functionality based on the regular collaboration.
Nevertheless, as with any new way of working there are caveats.
Open working can only work if both teams are completely transparent.
There may be some development teams out there that would be intimidated working in this open fashion. They may be concerned with what the client thinks of the quality of their code, or the tools/dependencies they have used to build the solution. This puts a barrier between the development team and the client. If you’re not willing to be transparent, then in our experience both teams can’t work to their full capability.
Open working is great because its informal in nature, and this results in not only a better product, but a better relationship with your client. However, sometimes formality is necessary. Occasionally, we have found that too much collaboration can compromise efficiency and productivity, and in fact formal procedures and processes can aid with efficiency in a team setting. On reflection, there may be a balance of formality to strike with open working, to encourage effective collaboration especially when working to tight deadlines.
This approach to working may not always be the best one.
It will be down to the preference and requirements of the teams. Sometimes, working so transparently may not be allowed, or indeed appropriate. This approach relies on a lot of honesty – a client who is trying to control every detail of the project would not make a good fit for this style of working. Likewise, the client is only going to get a product which meets the requirements if the development team are comfortable working in the open. Teams need to consider both the project requirements and the team cultures to decide whether it best to adopt an open working style.
Open Working fits well with the SICCAR way of working. It’s the approach we prefer to take with projects, as it allows us to establish genuine and transparent relationships with our clients.
Interested to know what project the SICCAR team work on next? Follow us on LinkedIn to keep updated.
Author: Chris Hunter, Developer, SICCAR