How Osmotic Communication Works For NearShore Team

#SridharPeddisetty #Agile #Scrum #Strategy #Osmotic #Communication #Strategy #AgileTraining #AgileBestPractices #NearShore 

To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others  -Tony Robbins

What is Osmotic Communication?

Osmotic Communication is a term coined by Alistair Cockburn and the definition is: "Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work"

What is a NearShore Team?

A NearShore team provides services to the client from a country, which is having proximity in terms of time zone and geographic location to client's country. Its a virtual team providing quality services to the client by overlapping for more time with the client by working in similar time zone, collaborating in realtime. 

How Osmotic Communication Works For NearShore Team?

In my earlier post Active Listening Is Key For A Successful Delivery, I had shared how in Agile, requirements and solutions evolve through communication and collaboration between self-organizing and cross-functional teams. Also in another post Everyone's Perspective Is Key In Retrospectives, I had shared how the best teamwork comes from the team members who are working independently but toward one goal in unison and working in an environment where everyone’s perspective is encouraged, heard and respected.

Looking at the above illustration, its understandable that NearShore team cannot have the benefits of a face-face white boarding or in person conversations, but now with robust communication mediums including tools available, the communication gaps are shortened. Below are examples of few collaboration tools, which bridges the communication gaps working with virtual teams. 

1. Skype
2. RealTimeBoard
3. Jira
4. Confluence
5. MindMeister

Using the advantages of NearShore time zone proximity, virtual team works realtime with onsite team and using collaboration tools like Skype for communication. For instance, group chats in Skype provides the perfect opportunity for the onsite teams and virtual teams to have a real time discussion and Osmotic communication is possible with the inputs shared by random team members instead of relying on 1:1 communication. It does not work in all situations but group chats go a long way in facilitating Osmotic communication in which a Scrum Master or a Product Owner operating from onsite could be seeking an answer from a remote developer but the remote QA member could chip in, if the person has same or better understanding. In another example, say a remote developer has a question on specific feature and posts the question to PO or stakeholder in group chat. Response of which could not only benefit the developer but also the remote QA, who in turn use the information in creating more specific test scenarios or automation scripts. Another major advantage of tool group chat is archiving of the communication for future reference, which is something that is not possible for a collocated team when having in person communication instead.  

Summary

Osmotic communication keeps the cost of communications low while keeping the feedback rate high. This in turn, helps keep the overall cost of quality low as while working with NearShore team, its evident for the client that the requirements are disseminated faster and errors are corrected quickly. With strong delivery management best practices, frequent face time with client, NearShore virtual teams can take the advantages of Osmotic communication. 

Previous posts you might be interested in

• Everyone's Perspective Is Key In Retrospectives
• Empower Your Team To Own Responsibilities
• Active Listening Is Key For A Successful Delivery

Case Study: Scrum Followed Properly Versus Not

Note: My following article Case Study: Scrum Followed Properly Versus Not is originally published in Scrum Alliance 

Case Study: Scrum Followed Properly Versus Not

It is not the methodology or the tool that fails to deliver quality software but it is the people involved. I strongly believe in the opening statement and here am sharing a case study of when Scrum was followed properly versus when it was not followed properly. Before that let me share the essence of Scrum as documented in the 'Do Better Scrum', which is

Majority of the teams have a common knowledge on Scrum including the basics such as

but more often than not the essence of Scrum is overlooked by the teams, which fail to follow Scrum properly.

This case study is about two Engineering teams,  ‘Team A’ and ‘Team B’, both following Scrum but one team missing practicing the very essence of Scrum while the other team practicing it to the core. 

‘Team A’ believed it was delivering software using Scrum by having The Team, Scrum Master and a Product Owner. Team was having Scrum Artifacts including Product Backlog, Sprint Backlog and Scrum Ceremonies including Sprint Planning, Daily Scrum and a Sprint Cycle of 4 weeks. But still the team was struggling to deliver software incrementally, which was shippable and could be rolled out to production. To its advantage, ‘Team A’ was also collocated including having an onsite Product Owner and most of its stakeholders. But still results were not there in the form of regular delivery of most valuable features in production and more importantly, not very happy stakeholders. 

Project was then handed out to a virtual team, ‘Team B’. ‘Team B’ not only practices core Scrum principles but also believes in the essence of Scrum. ‘Team B’ being virtual could not have Daily Scrums because of time constraints but using collaboration tools, was able to effectively and efficiently share what they worked on previous working day, what was their plan for next working day and if there are any impediments. Team was able to communicate robustly with the Product Owner through collaboration tools on user stories, acceptance criteria, design of the new features and agree upon definition of done. ‘Team B’ did have weekly calls with stakeholders to sync up on the status of the sprint. Team was disciplined in defining their Sprint Release Cycle including defining the milestones like Sprint Planning Meeting, Code Freeze, Functional Testing, Integration Testing, Sprint Reviews, Stakeholder Sign off and Sprint Retrospectives, associated with their respective dates.

By sharing a transparent sprint release plan with dates & milestones and following the same meticulously, ‘Team B’ demonstrated following the essence of Scrum. As a result, ‘Team B’ not only delivered the project on schedule and with quality but also was able to refactor the code written by ‘Team A’, getting rid of most of the technical debt. 

So lets analyze a little more on what was the difference between both the teams. ‘Team A’ was less disciplined in ensuring visibility into the team’s progress and honestly communicating about progress and risks. Team struggled to organize itself around the work and failed in delivering the most valuable features regularly. As a result, ‘Team A’ was not able to receive valuable feedback from stakeholders and with no way to retrospect on its work, the team set itself up for failure. It was not a case of team not working hard enough but more a case of failure on its part to properly plan, set expectations and delivery frequently. As the team was committing itself for a 4 weeks sprint cycle, development team allowed itself some short term code wins by providing the features without paying attention to long term goals of insuring scalability, reliability, availability and maintainability of the feature. The QA team was brought in late into the sprint cycles and thus losing the advantage of having second opinion on the requirements early to find any gaps. By the time QA team found any requirements gap, development team would have moved ahead into middle of next sprint cycle.  Team also missed setting expectations with stakeholders on the timelines of signing off on the sprint items, thus not allowing them to provide timely feedbacks and missing the opportunity to improve on the delivered features.

In contrast, ‘Team B’ though virtual, was disciplined in planning well, setting expectations by being transparent & robustly communicating using collaboration tools and finally able to deliver most business valued features frequently.

I look forward to read your feedback on how properly your team follows the essence of Scrum.

References:

•  Do Better Scrum

Scrum in a nut shell

Scrum is an Agile process or framework for managing Agile projects. It is a project management process, certainly not a methodology, as that would be too heavy. Scrum is an iterative, incremental framework. Scrum structures product development in cycles of work called Sprints, iterations of work which are typically 1-4 weeks in length, and which take place one after the other.
Scrum is one of several Agile methods for developing and deploying software, although it may be used for non-software initiatives whenever people need to work together to achieve a common goal. The primary objective of Agile development is to deliver value early in the Project Lifecycle based upon customer and market demands. The ability to deliver value early and often, yet readily adapting to change, is considered to be a major contributor in making Agile Development one of the more rapidly growing trends in technology.
Scrum is a method for project management that is becoming increasingly more common
in the software industry. Small teams consisting of a maximum 6-8 people divide their
work into “mini projects” that have a duration of about one month during which a limited
number of detailed tasks are solved. Where traditional methods focus on staying on
track, Scrum is aimed at – like other agile methods - delivering business value

Scrum Basics
Scrum is an iterative, incremental framework.

Scrum is not a process – rather, it’s a framework which provides a lot of visibility to the team, and a mechanism that allows them to “inspect and adapt” accordingly

Scrum structures product development in cycles of work called Sprints, iterations of work which are typically 1-4 weeks in length, and which take place one after the other.

The Sprints are of fixed duration –they end on a specific date whether the work has been completed or not, and are never extended.

At the beginning of each Sprint, a cross-functional team selects items from a prioritized list of requirements, and commits to complete them by the end of the Sprint; during the Sprint, the deliverable does not change.

Each work day, the team gathers briefly to report to each other on progress, and update simple charts that orient them to the work remaining.

At the end of the Sprint, the team demonstrates what they have built, and gets feedback which can then be incorporated in the next Sprint.

Scrum emphasizes producing working product at the end of the Sprint is really “done”; in the case of software, this means code that is fully tested and potentially shippable

Scrum Values

1. Openness
2. Focus
3. Commitment
4. Courage
5. Respect and
6. Visibility

Scrum forces teams to take ownership of the success or failure of their project. In traditional waterfall methodology, its more often than not, a project manager who is responsible for project's success or failure.