Traditionally the data-team is used to sitting in their own area and working for many project teams by handling requests either via a ticketing system or vi email. The hand-over of work or throwing of work over the wall creates knowledge silos and inefficiencies.
How
There multiple ways teams can use shared resources from the data team, which also depends on the size of the development team and the size of the data team
Small team
In a small team of developers, when the tasks are data related we may have a single person focusing on database related tasks or we may have single dba doing all these tasks for the team. While doing these tasks its better for the data person to pair with the rest of the developers.
The data person should be involved while discussion about features are happening, get involved in white boarding solutions. After the discussions tasks such as designing new tables, indexes, views, stored procedures, triggers for the features under development should be done while pairing with the developers.
Operational tasks such as automating monitoring, writing scripts to take backups, performance tuning queries and optimizing index usage or utilities to put test data or take a subset of the production database. The data person should not be doing all these tasks by themselves as it will create silos of information and during times when they are not able to work, brings the team to a halt. The data person should also be pairing to spread knowledge to the team about doing specific tasks with the database and learn from the developers, how the database is used?
Large team
In a large team, if there is a single data person, many tasks may have to be automated such as Sandbox Creation or Publish Data Dictionary, pairing with developers to automate these tasks helps the developers self service much of their database needs. The data person should then be pairing with developers for database design, table design, index design and coding stored procedures, views etc along with the developers. This pairing helps the developers understand the data architecture and makes for a productive team instead of productive silos of knowledge.
Multiple teams
In situations where we have multiple teams and single data person, effective rotation of the data person becomes critical for the success of the teams. The data person should not be targeting to slice the time equally among the teams but look for effective use of the time on the teams. Since each team is going through different development phases they may not need the same attention from the data person.
When the data person is with a given team they should pair with the team members to accomplish the task at hand. They should also enable the team members to pull them into a quick conversation/discussion as and when needed, so that the team does not experience wait times
Multiple teams and data team
In many companies we have a shared database support teams comprizing of DBA, data modellers, data architects, data developers and others. In such a situation its difficult to allocate the data team members to development teams by role during a iteration.
The figure above shows a team of specialists in data, providing service to large number of project teams. When the teams need data related service they should ask for help from the shared data team and then pair with the data team member. This data team member after returning back to the shared team should share the knowledge of the work done on the project team so that anyone from the data team is able to help the project team the next time instead of being dependent on the same individual.
Data team members going from one project team to another also allows for them to share knowledge about what other project teams are doing and talk to them about best practices, design decisions being taken and data entities and attributes available from the other project teams.