Agile teams are small. 9 to 12-member team is recommended for any Agile project. Usually, Agile teams are co-located and work very closely. The team is in a single room and sit together on a round table with no barriers. It is very easy to over hear each other’s conversation and peek into other’s screen. This enables Tacit knowledge and Osmotic communication.
Now, with the small team it is very difficult to accommodate resources having individual skill sets. In other words, an Agile team does not have liberty to have resources are specialized only in one skill.
During an iteration, there could be instances where bottlenecks are encountered. The team is self-organizing and self-sustaining. Additionally, the iteration is timeboxed and there is a committed deliverable. If there are any bottlenecks, then the team is expected to handle it themselves. Procuring any external support is difficult because in-depth
knowledge of the tasks is extensively known to the team.
We can simply say that we need Generalizing Specialists on the team. This means that each resource on the team is multi skilled. It is not jack of all and master of none. The letter “T” indicates a long vertical line and a short horizontal line. The vertical line indicates depth and horizontal line indicates the breadth.
The depth is primary skill of the resource and breadth is secondary skills. For example, a resource may have Primary skill as a Database Administrator and secondary skills to be documenting test plans and executing test plans. Thus, when there is a bottleneck for testing, this resource can pitch in and help to push out the tasks to next level.
As illustrated in the example above, a resource assigned on the team is dedicated to certain tasks by virtue of primary skill. Whenever tasks are accumulated due to any reason, this resource can be assigned on those tasks to streamline the flow since the resource owns secondary skills which can be utilized to handle the bottleneck.
Summarily, it is very important to acquire secondary skills which aid in scenarios where we have bottlenecks in the iterations.
A database administrator is a very critical resource. Most of the times this resource dons multiple hats. Sometimes acts as a Linux administrator, on other occasions as a QAD functional resource especially when it comes to managing QAD security, and some other times as a technical consultant for setting up interfaces between QAD and other external applications. Each of these roles needs the resource to possess somewhat different skills. The other roles are not primary for the DBA resource. Basic advantage for DBA is owning administrative access at server level which enhances the capability to play these other roles. Moreover, knowing what needs to be done is very helpful since the task is accelerated to completion.
A database needs assistance from OS level for smooth operations. Thus, knowledge of OS enhances the capability of a DBA resource to administer the database with a lot of ease. Considering all the factors mentioned a DBA with secondary skills of QAD knowledge, OS working knowledge, a few aspects of data exchange between PROGRESS database and other external applications, QAD Bolt on modules is always preferred to be part of the team. A pure PROGRESS DBA might be extremely well at managing the database but for other tasks there would be a need to rope in other resources.
In light of this usually a DBA resource with the T-Factor is picked quickly. We at Arista incorporate the horizontal skills during the DBA induction training. Secondary skills that we inject for a DBA include –
Our DBAs are pre-equipped with the T-Factor and integrates seamlessly into a lean team.
