VBA integration for scaled agile teams
Ok so here is the scenario:
- I am working on two teams. Team A and Team B
- The product that we are working on is a financial solution that utilizes Excel sheets for computations and data consolidation
- Team A is working on the data modelling (SQL), Stored Procedures and API endpoints (Rest)
- Team B on the other hand is working on Excel sheets using VBA.
- Yes the teams are (currently) not cross-functional, but we are trying to change that..
- Now, we receive additional budget from the sponsors and we are about to hire additional people so we are thinking of adding a Team C.
- For Team B, we are thinking of adding SQL/API experts so that the team could be cross functional and would have less dependencies from Team A.
- We plan to have Team C to have similar skill sets
Everything is looking good but we realized that it is really difficult to integrated VBA work/excel sheets during development. It is not similar to other languages wherein you can easily merge builds using Github or Azure. I won't mind if we will exceed the ideal number of members of a Scrum Team if that will make the work of our developers less complicated and confusing. But I still wonder if some of you has experienced a similar situation or maybe you know any technology or approach that could help?
Thanks!
Try looking at it another way. You have an opportunity not to use configuration management tools as a crutch. Instead, there is an opportunity to collaborate by focusing on a single document and its state. There are only two or three teams who would need to self-organize any editing protocols. If a document is shared between teams on the cloud, there may be a version history and revert capability should it ever be needed.
My preference is that if there are several Development Teams working on the same product, the stories and their associated dependencies be assigned to the same team. Scrum Master(s) will help me with collaboration between the teams so the combined work from the multiple teams results in a Done increment which is releasable.
Try looking at it another way. You have an opportunity not to use configuration management tools as a crutch. Instead, there is an opportunity to collaborate by focusing on a single document and its state. There are only two or three teams who would need to self-organize any editing protocols. If a document is shared between teams on the cloud, there may be a version history and revert capability should it ever be needed.
Thanks Ian this is promising but could you be more specific? Here is what the team is currently doing. Team B's developers are working on certain tabs and then one developer will announce to the team that he is done with his work and then the next developer will pick that sheet up. The sheets are in the Sharepoint repository but you won't be able to actually collaborate on that bec VBA doesn't work on Sharepoint.
My preference is that if there are several Development Teams working on the same product, the stories and their associated dependencies be assigned to the same team. Scrum Master(s) will help me with collaboration between the teams so the combined work from the multiple teams results in a Done increment which is releasable.
That's what we are doing right now, Mark. But how will you do this if management is willing to add you additional developers? Will you stick to the 3-9 ideal number of members despite it might cause confusion and integration issues?
As much as a I can, I push back on throwing bodies at Product development. Experienced high-rise construction companies are the same way. Fifty, skilled workers can do more work on a storey than two hundred workers running around trying to stay busy. I am candid with leadership that more people will result in chaos and will require the need to scale; something I am not fond of and do not advocate.
One approach I have seen was where a web-based application (which was the whole product for the company) was broken up into smaller products, each with their own Product Owner.
Logins/accounts/authentication = Team 1
Integrations with third-party vendors = Team 2
The most popular feature of this Product = Team 3
A new visualization feature of this Product = Team 4