Dialogue and successful Teams

How does one turn a small group of individuals into a team, one that is focused on a singular goal? The answer seems to lie with communication. Communication not in the sense of a mere exchange of information, but one that leads to dialogue. And dialogue creates the shared knowledge space for the problem, and leads to the emergence of a collaborative group of individuals, a team in essence.

In the context of outsourced offshore development (specifically, when it comes to software product development), this need for creating a dialogue takes on a much greater importance. Teams rarely have an equal level of experience, in most cases the team composition spans very little experience to a high level experience. The actual composition is very much dependent on the clients purse size.

The typical team is composed of one or two resources with the relevant experience and capability for “Deep-Work,” the rest of the team will be mid-experienced to low-experienced resources. One would think that the client, having understood the composition of the team, will also adjust his expectations accordingly, the answer is no. The knowledge be it domain or technology that is being absorbed by the team members is considered as an intangible benefit that the client is passing on. This argument ignores that the team members are individuals each with a very different ability to assimilate and learn new domains or technologies. This problem is compounded by the application of agile techniques via scrum (or something similar) in principle but not in the true spirit of it.

Agile/Scrum is not seen as techniques whose primary aim is create a dialogue amongst the development team and between the stakeholders and the development team. But, more often than not it is seen as a tool to monitor and control the work of the team. In this mind set the stake holders focus on the burn down and velocity, having replaced cooperation and communication with stories and tickets. Stories lend themselves to dialogue through a deliberate effort, left to themselves they are nothing more then a highly formalized minimalistic form of communication. If you want a dialogue with your team then make it happen, Agile/Scrum won’t magically bring it about particular if the aim is to pay only lip service to these techniques.

This is perhaps one of the most compelling reason for advocating team colocation for product development. Such a setup would ensure the cooperation of take holders and collaboration amongst the developers. And, this is should guarantee a continuous dialogue during all stages of the product development, and more importantly a dialogue during the critical early stages of the product. There will be rare cases when this may not happen, but there will be enough opportunities to stop a complete break down of dialogue.

It is very easy for distributed teams to gravitate away from dialogue into a soup of stories, tickets, burn downs, and metrics. A committed leadership is required to steer the team to dialogue not tickets, and narrative not stories to ensure a successful emergence of a team and not just a collection of individuals.

This is not an attempt to suggest that distributed teams are not the vehicle for product development, and neither is it an attempt to negate the outsourced offshore model for such distributed teams. It is to emphasize that real leadership is needed here, not one that sprinkles the words Agile, Scrum, and devOps at the appropriate time, to only walk away from it later on.


The CoE as the clients “Pit Stop”

There was a time when a CoE (Centre of Excellence) was a one stop resource pit. Not unlike a formula one pit stop, although, here time is of the essence, any delay could lead to winning or losing at the checkered flag by as little as 0.001 of a second. A CoE should be emulating a pit stop, it should be the point of first and last call for all things at a centre of excellence. The claim to excellence by a CoE could be any subject of relevance to the organisation, from something as mundane as Java programming language, to something a little more involved as Business Process Management. But, sometimes organisations, particularly in the outsourcing offshore service business tend to create open ended CoE departments as a catch all. Thus making the whole purpose of the CoE irrelevant.

For example, what should one expect from a CoE of Business Process Management? Some of the knowledge we would expect from this CoE is:

  • Knowledge of core business process standards at the least in one or two of them, for example, BPMN, Workflow management.
  • Knowledge of some of the tools and the pros and cons regarding their use. Of course, you may just have a thorough expertise in only tool, CoE does not mandate multiple tool expertise.
  • Knowledge of business rule engine, and how it would integrate with the process engine. The same reasoning applies here as for the tools mentioned in the previous point.
  • Knowledge of cloud implementation and their pros and cons. Knowledge of international, national regulations that may impede cloud selection.
  • Knowledge of matters which influence the selection or implementation of business processes in an organisation, such as integration to other internal or external systems.
  • Etc.

If you have expertise in only one or two of these, to then claim to be a CoE for business process management is highly questionable, since your CoE is not a pit stop anymore. CoE is about knowledge and experience offering, and not about certification. If you are a outsourcing offshore service provider, it is very important to spell out the offering of your CoE expertise. If the only purpose is to emphasize the superiority of your hiring process, why would you want to tag it as CoE at all. The CoE tag also fails, if the only reason is to highlight your product management, team building, and similar development activities. Since the criteria for a CoE that would satisfy these claims would requires much formalized and detailed service offerings not unlike those specified for the business process management.

The idea of a pit stop is to be able to get all the services you need at one place, and by highly competent individuals. It should not be such that you have to run from one pillar to another post to obtain the services required. Just as in the formula one race, the vehicle makes one stop and then gets back back into the race, so it should be for the client who is shown the CoE as his service point of call.


Get every new post delivered to your Inbox.

%d bloggers like this: