Archive | February, 2015

Be Like Salt

5 Feb

Be Like Salt (published on ThoughtWorks’ website).

Having worked on consulting engagements for a fair amount of time, I have realized that consulting is both a science and an art. The science lies in the domain knowledge or the ‘hard’ skills. In my case, it is currently Agile and Lean. The art aspect relates to the ‘soft’ skills, which in my view, are as critical as the hard skills for the success of any consulting engagement.

The art of consulting, like any other art form, gets better with practice. A successful consultant is often adept at both skill sets. It is therefore no surprise that experienced consultants are highly valued. This art, like innovation, is something which everyone talks about, but very few seem to have an intuitive grasp.

Be Like Salt

Here’s a simple metaphor that I have used over a number of years of practicing this arcane art. My point – think of consulting like salt.

You may be wondering what salt has got to do with consulting. Let me explain. I believe that characteristics of salt can be mapped to consulting skills directly.

  • By itself, salt is of hardly any use

The real value of salt lies in adding it to food to enhance its flavour. Similarly, a consultant cannot add much value by working in isolation. A consultant needs to work closely with the concerned stakeholders and win their trust quickly, in order to not only understand the context, but also to get a buy-in to the recommendations he/she would like to make.

  • Salt is not visible, but its presence is always felt

Similarly, a consultant, especially on Coaching and Enablement type of engagements, should let the teams own and drive the implementation of the recommendations as soon as possible. The consultant should be available at all times to the team, but he/she should resist the temptation of doing things himself/herself and ‘being in your face’ at all times.

  • No salt or very little salt will leave the food insipid or inedible

Not focusing adequately on the areas to be impacted and/or not getting under the skin of the core issues will result in consulting not being impactful at all, or not being impactful enough. On the other hand, if the consultant focuses on too many areas, he/she may risk spreading too thin, making only a diluted impact.

  • Too much salt will also leave the food inedible

A consultant should strike the right balance between advising and letting the team discover for themselves, between showing how to do it and letting the team do it themselves, and on occasions, even fail a bit. The goal of a consultant should be to make the team self-reliant, and thereby making himself/herself redundant as quickly as possible after the engagement objectives are achieved.

  • Salt cannot be added to everything, e.g. dessert

Similarly, a consultant should know which areas to stay away from. This could be due to lack of expertise in a given area and calling that out candidly, inadequate appetite for change at that moment, something not being high priority at that moment etc. A consultant also needs to keep in mind that not every battle is worth fighting for, at a given point in time.

The points I’ve mentioned above have worked well for me in most situations. However, by no means am I implying that one should operate in this way at all times. There are times when I’ve changed my consulting approach, based on my assessment of the situation. At the end of all this, if you ask me what the best approach is to your situation, I may just give you the most cliched consulting advice there is – “it depends…” 🙂

Distributed Development Enablers – Part 3

5 Feb

In the previous posts, we have examined People Enablers and Process Enablers, which can help in alleviating challenges of Distributed Development. In this post, the final one, let us look at Tools and Infrastructure related enablers.

 

  • Electronic Story Wall

A key challenge faced in a distributed working environment is ensuring that regardless of the location, everyone should have a common view of story wall, team metrics and so on. This can be best achieved through having an electronic story wall, which becomes the ‘single source of truth’ for all team members across various locations.

An electronic story wall can be a huge enabler in terms of bringing in shared understanding of iteration progress, blockers and dependencies. It can also help is ensuring that duplication or work is avoided.

The ‘real time’ nature of an electronic wall helps in avoiding communication overheads and constant transparency helps a great deal in building trust as well. This applies not only to the development team, but also to client and business, if the electronic wall is shared with them.

A criticism leveled against electronic walls is that these do not ‘throw information in the face’, like physical walls do. There is definitely some merit in this assertion, as the benefits of ‘information staring in the face’ at all times are immense. However, this limitation of the electronic wall can be overcome by either maintaining a physical wall, in addition to the electronic wall, or even better, by projecting the electronic wall in the area where the team is sitting. In case the team decides to maintain a physical wall as well, it is imperative that utmost discipline is required to ensure that the physical and electronic walls remain in sync at all times.

Regardless of whether a team is distributed or not, and electronic wall helps immensely in generating metrics accurately, with minimal effort.

 

  • Electronic Build Radiator

Similar to electronic story walls, the benefits of knowing the build status on a real time basis are immense. In fact, knowing whether build is broken prior to checking in code is almost a hygiene factor, which can save the team from a lot of rework.

Knowing when the build is broken not only can prevent check-ins in the broken state, but can galvanize the team to resolve the issue together, should someone be struggling with fixing the broken build.

A build monitor also helps in ensuring that teams do not ‘pass on the baton’ to another location when the build is in broken state.

 

  • Communication and Collaboration Tools

The most difficult and persisting challenge in distributed development is the barriers encountered in communication and collaboration between people across locations. While nothing can be more ideal than having face-to-face conversations, both individually and as a team, constraints in doing this is a major limitation of distributed working. Inability to communicate and collaborate face-to-face not only not only creates huge strain on team members, but also has potential for serious consequences like trust deficit.

Hence, it is imperative that distributed teams are provided with appropriate tools for communication and collaboration, with the aim of getting as close as possible to being face-to-face. These tools should facilitate both individual as well as group level communication and collaboration and should allow for as much online communication as possible. Moreover, to the extent possible, tools should aid video based communication, as seeing a person, even if it is via video, greatly enhances the quality of communication.

Examples of such tools include GTalk or Lync for point-to-point communication between individuals, Campfire for conversations at team level, Google Hangout for team meetings, IdeaBoardz for brainstorming and retrospectives, Trello for any activity requiring collaboration etc.

Organizations need to find tools which adhere to their security policies. This can be a challenge if the teams/people in charge of security are not sensitive to the challenges faced by distributed teams. It is important to work closely with the security team to identify tools which don’t compromise security and which meet the needs of distributed teams.

Another meaningful way in which communication and collaboration challenges can be eased is by permitting team members to use their own devices, when they are outside the office, viz. at home and while traveling. The organization will need to define and implement a policy for BYOD (Bring Your Own Device), which fits within the boundaries of the organization’s security policy.

 

  • Source Control System

Distributed teams should work with a source control system which encourages trunk based development, and minimizes the need for branching. Sometimes, there is need for team members to maintain source code on their respective machines and make local commits. If this is a valid requirement for the team, the source control system should have the flexibility to support this. Given that distributed teams put together may form a large unit, the source control system should support check-ins in large numbers, without having to grapple with conflicting pieces of code or juggling multiple versions. Team members should be able to view code changes across locations quickly and give feedback, as needed, before syncing with the repository.

A source control system which has a Wiki feature can help a great deal in effective context sharing among team members.

 

  • Network Connectivity

Network connectivity and bandwidth are actually more of hygiene factors than enablers for distributed teams. Teams working across locations, especially across countries, can pose network related challenges, which may not occur if the team is co-located. It is often seen that these challenges are not proactively anticipated, and are usually dealt in firefighting mode, once they become showstoppers or serious impediments to the functioning of distributed teams. Choice of network, access rights and bandwidth should be addressed ideally before the distributed team begins functioning.

Network related issues may get magnified when 2 different organizations need to access a single server, e.g. Client and Vendor. Complexities arising out of this scenario must be anticipated and dealt with in advance, to ensure smooth functioning of teams.

An important aspect which comes into play for distributed teams is security of the network. This aspect also should be dealt with proactively, as security lapses on the network can lead to devastating consequences.

To summarize, distributed development does create additional challenges, but with appropriate enablers, these can overcome quite effectively.

Please share enablers that have benefited your distributed teams.