Onsite-Offshore Agile model

The teams are distributed in geographically distinct locations.
The onsite & offshore model will help in faster development of the product & helps in taking the product to the market soon.

Agile implementation adopt multichannel communication network as shown above to address issues related to different geographical locations and different time zone.
Offshore team is divided in small groups based on technology for ease of operations. Everyone from offshore team is interacting with their onsite counterpart for technical transition and for “Definition of Done” . Offshore Project Manager is acting as offshore facilitator for team both at onsite as well as offshore, onsite Scrum Master is acting as overall coordinator.
Offshore code review process adopted to track progress of offshore team. These helps in identifying gaps and bridge those before being show stopper. Code demo also help to get onsite and offshore team in sync. During code review onsite team guides offshore team about current progress and helps them to identify suitable approach to achieve target deliverables.
While continuing with Agile principals there is additional modification implemented in daily activities of Scrum. The Agile implementation adopted few changes in standard Scrum Model.
• Offshore Scrum conducted at offshore start of the day
• Offshore participates in onsite scrum at onsite start of day
• Dashboard published after onsite scrum
The details of the sprint planning meeting:
When : 2nd half of the 2nd week of previous sprint
Duration : 4 hours
Attendees : Developers Team, Business Analyst, Product Owner, Managers
Conducted By : Scrum Master
Agenda Items :
Pending Activities: Discussion about any outstanding items from the previous sprint. Output – After discussion either the item is marked resolved/done or there is a takeaway / follow-up task assigned to somebody that will help close the pending item. Offshore shares Scrum update in the Agile tool (e,g. Xplanner)
Lessons Learnt : Lessons learnt from the previous sprint are captured (both +ve and -ve)
• Sprint Planning: For each of the stories in the product backlog for the upcoming sprint the following are discussed:
 Resource assignment
 Level Of Efforts (hours)
• Review of Product backlog for forth coming sprints.
• Bi-Weekly report is shared progress tracking process of project.
• Vacation List
Daily Timeline:-
• Timelines mentioned here are notional.
• Scrum meeting should be over in 15 minutes.
• Daylight timings considered.

As daily scrum is conducted at onsite and offshore separately, both onsite scrum master and offshore project master act as facilitator to onsite and offshore team respectively. Scrum of scrums is also conducted between onsite and offshore key team members. This helps to get teams on same page and also the teams work on showstoppers and high priority issues.

Sprint Timeline:-


Cloud – Benfits & Risks

Cloud computing is being touted as the “next generation of computing” and is seen as vital to many in the IT industry. The many benefits of migrating to a cloud computing model include: increased efficiencies through shared resources, greater flexibility, global accessibility, and reduced expenses compared to standard physical computing. These benefits are offset by a few shortcomings, including loss of control and increased security risk, to name a few.

Cloud computing is a style of computing in which IT-related capabilities are provided ‘as a service,’ allowing users to access technology-enabled services from the Internet (in the cloud) without knowledge of, expertise with, or control over the technology Infrastructure that supports them.

The commercial cloud marketplace offers a wide range of cloud services that vary in complexity and value. The figure below organizes this marketplace into a general set of service categories layered in a notional stack, with foundational offerings toward the bottom and more complex offerings toward the top.


Cloud Infrastructure (IaaS) — At the bottom of the cloud stack, Cloud Infrastructure provides the distributed multi-site physical (Hardware) components to support cloud computing, such as storage and processing resources. This layer allows the infrastructure provider to abstract away details such as which exact hardware an application is using and which data centre the application is running on. Virtual machine (remote access) concepts have also enabled a useful separation of underlying hardware implementation details from the view of developers, and the ability to more rapidly scale server resources in response to changing demand.
Cloud Storage — Storage as a service — Building upon the Cloud Infrastructure, this layer of the cloud stack is focused on the incremental renting of storage on the Internet. Network-based large-scale storage on demand is an example of this layer of cloud computing. Some offerings go further and offer platforms for service providers, including storage, security, identity management, and other functions. A good example of this type of offering is the Amazon Simple Storage Service (Amazon S3).

Cloud Platform (PaaS) — Platform as a service — Platform offerings provide an infrastructure for developing and operating web-based software applications. Virtual servers running in the cloud can include web servers, applications servers, and database engines. It facilities for application design, application development, testing, deployment, and hosting, as well as application services such as team collaboration, security, application versioning, and application instrumentation. Developer teams frequently work together through their browsers to leverage the virtual cloud platform.
An example of a platform offering is Force.com, is a software application provider supporting SalesForce.com. APIs and development tools to support the SalesForce application became more general platform tools for any customer offering Internet-based software.

Cloud Services (CaaS) — Components as a service — Run in a distributed fashion, across the commercial Internet. This definition is most like SOA with defined service interfaces as a basis for system-to-system integration.

Cloud Applications—Software as a service (SaaS) — This definition relies on the cloud for access to what would traditionally be local desktop software. For example, Google provides web applications, such as Gmail, Google Calendar, Talk, Docs, and Sites, with functionality similar to traditional office suites. One advantage of this approach is that the application can be continuously updated by the application provider without issuing and shipping new installation disks. Each time the user logs in to the site, the user will get the latest version of the application. The application provider is also offering a very scalable web application using multi-tiered web architecture, implemented on a considerable infrastructure. Disadvantages include the complete dependence on the underlying network to access the application. When the network is down, the user cannot do any work with the network-based application. In contrast, the desktop version of the software does not require network connectivity for productive work.

Software as a Service (SaaS) is a model of software deployment where an application is hosted as a service provided to customers across the Internet. By eliminating the need to install and run the application on the customer’s own computer, SaaS alleviates the customer’s burden of software maintenance, on-going operation, and support.
Conversely, customers relinquish control over software versions or changing requirements; moreover, costs to use the service become a continuous expense, rather than a single expense at time of purchase.—
Wikipedia (SaaS) .

Cloud Clients — The local desktop becomes primarily a presentation layer device in this scenario. By using many online software applications, the user is distributing processing on their behalf across CPUs scattered in the cloud by software service offerrors.
This distribution of data across the Internet rather than in local desktop or local area network repositories resonates with end users because it oft en equates directly to the use of presentation layer Cloud Applications in Cloud Clients such as a browser, the top of the cloud stack.

Considerations with cloud computing — Cloud computing brings with it a number of key benefits and risks:-
• Outsourcing to cloud providers: Commercial cloud computing effectively outsources portions of the IT stack, ranging from hardware through applications, to cloud providers. Cloud computing allows a consumer to benefit by incrementally leveraging a more significant capital investment made by a provider. The consumers also benefit significantly by being able to dynamically scale their demand of the cloud services.
The service provider pricing model of cloud computing is particularly valuable when economic uncertainty limits the capital and IT resources available to firms.
• Dependence on the network: Cloud computing is fundamentally dependent on the network to connect the offeror with the consumer. For those who have redundant network connections with robust bandwidth this will not be an issue, but for those who don’t, serious consideration should be given concerning singular dependence on network based
offerings, and how business continues when the network is unavailable or unreliable.
• Dependence on specific cloud providers (lockin): Vendor lock-in is a risk with the current maturity of cloud computing. Vendor neutrality is often best achieved by utilizing industry or open standards, but these standards are currently evolving for several layers of the stack. Developing applications to leverage one cloud provider’s offerings can lead to lock-in with one vendor’s solution and limited or no competition.
• Contracts and service-level agreements (SLAs): Cloud offerings are defined with a discrete interface and performance expectation. This agreement can be captured in an SLA between the provider and consumer, and this document can be made a part of the contractual relationship between the two.
• Security: Commercial cloud providers will have security solutions that meet the needs, risk profiles, and cost models of their commercial customers. These security solutions will not always be appropriate for Federal needs. Part of the benefit of cloud computing as a consumer is being able to abstract away the details of how a platform or service is provided. Federal consumers may often need a clear understanding of (and need to specify the characteristics of) what is occurring inside the “black box” of a cloud offering to ensure secure operations.

Biggest Risk:-The biggest risk which I see is that what the offerror goes bankrupt & has to close down the service he is providing. Just imagine the high cost of migration from one cloud provider to another.

Data Science

Just imagine if data had to be captured from the Stone Age, billion years ago; the data would have ran more than zeta bytes for all the information or data’s of the fore fathers & their friends. How would you have managed these data’s? Would these data be called BIG DATA?
Today the modern data that is available is called BIG DATA, tomorrow the same data will be called SMALLER DATA & day after tomorrow it will be called SMALL DATA and new term might come up called THE BIGGEST DATA for the data that is available in the universe. Tomorrow the budding engineers will have a subject called Data Science in school/college.
In the past 30+ years data has increased & data analysts are smart enough to turn the available data’s into product & use them as per the requirement. But merely using data isn’t really what isn’t meant by “data science.” A data application acquires its value from the data itself, and creates more data as a result. It’s not just an application with data; it’s a data product. Data science enables the creation of data products. Google is a master at creating data products – Search Engine, Spell check, Speech recognition etc.

The thread that ties most of these applications together is that data collected from users provides added value. Whether that data is search terms, voice samples, or product reviews, the users are in a feedback loop in which they contribute to the products they use. That’s the beginning of data science.
We’re increasingly finding data in the wild, and data scientists are involved with gathering data, massaging it into a tractable form, making it tell its story, and presenting that story to others. The web has people spending more time online, and leaving a trail of data wherever they go. Mobile applications leave an even richer data trail, since many of them are annotated with geo-location, or involve video or audio, all of which can be mined. The first step of any data analysis project is “data conditioning,” or getting data into a state where it’s usable.

Screen scraping referred to the practice of reading text data from a computer display terminal’s screen. This was generally done by reading the terminal’s memory through its auxiliary port, or by connecting the terminal output port of one computer system to an input port on another. The term screen scraping is also commonly used to refer to the bidirectional exchange of data.

To store huge datasets effectively, we’ve seen a new breed of databases appear. These are frequently called NoSQL databases, or Non-Relational databases, though neither term is very useful.

Using a variety of computational techniques for data mining:-

1. Classifying data by manually assigning labels (e.g. ‘valuable’) to a known subset of data, and using this to construct a classifier, i.e. a mathematical model, which can then be used to automatically assign the labels for remaining data, or for new records as they arrive.
2. Clustering data into groups that are more ‘similar’ to each other than to other clusters, for examples to determine which documents discuss the same set of topics, or which customers exhibit similar buying patterns.
3. Identifying anomalies, which are records very dissimilar from the vast majority of data, such as in fraud detection, or crime and intelligence investigations.
4. Analyzing patterns in subsets of data that have particularly strong connections to each other, especially in conjunction with other techniques, such as anomaly detection or clustering: For example, automatically characterizing anomalous behavior in terms of ‘explanations’ that yield deeper insight, or describing the actual behavior patterns of customers belonging to the same cluster.
5. Making predictions by choosing hypotheses that might explain data, by constructing probabilistic models, such as in tracking a moving target, modeling price movements or fault diagnosis

1) http://radar.oreilly.com/2010/06/what-is-data-science.html
2) Enterprise cloud computing

Agile model for products/projects executed in parallel

The teams can be collated in one location or in different geographical location, working on different modules of the same products/projects. I will cover in my next blog how a scrum team can work in different geographical location.

This model can be used to run different projects under a program. The item can be divided in modules/projects scrum team as show below in the diagram. On the other hand, even for complex products or product lines, there may be larger Scrum projects comprised of many more Scrum Teams

The Sprint can be of 2 or 4 weeks depending on the management consensus call. I have taken here a Sprint of 4 weeks timebox. The Sprint Team works on various activities while building the working increment of software for all of the items on the Sprint Backlog. At the end of each Sprint, a Sprint Review meeting provides the product stakeholders (typically the Product Owner, Scrum Team, Scrum Master, management, customers, and others with a short demo of the working software increment they deployed at the end of the Sprint.

During the Sprint a working increment of software is built, tested, and deployed. At the end of each Sprint work begins on a new Sprint with a new Sprint backlog to create the next working increment of software. Some of the stories have some dependencies on other stories that haven’t been completed or some stories need more clarifications; such stories are carried forward to the next Sprint cycle


Both the MAIN branch and the Development branch are used for developing and stabilizing the vNext release (v0.l) shown in blue. At the end of this first Sprint, vNext is deployed. vCurrent is now v0.1. During the second Sprint, MAIN and Development are used for developing and stabilizing vNext which is now v0.2 shown in red. At the end of the second Sprint v0.2 is released and work begins on v0.3. The process continues until all of the Product Backlog items have been delivered as working software. Development of the product is now complete and the full product is released.
The QA team will start their testing in Sprint n-1. The v0.1 will be released to the QA for Sprint n-1 and the development team will move ahead to the next Sprint. The defects found will be put as tasks/stories to the Development team in Sprint n+1.
When a customer wants to customize the product, the customization can be branched out from the main stream. A SILVER build release can be tag & released to the QA team for testing with a release note. Once its tested it can be tagged as GOLD build to be released to the customer with a release note.

Agile best practices

Agile best practices

#  Activity Benefits
1 Daily Scrum meeting Impediments are resolved immediately

Team in sync about progress and approach for further development

2 Sprint Backlog Team aware of deliverables

Team is able to finalize acceptance criteria

3 Product Backlog Management  and Team is aware of final deliverable

Release planning can be done on basis of business values in Product Backlog

4 Release Planning Team will be aware of code movement and will be able to plan for current sprints accordingly

Management will get periodic review of potentially marketable product

5 Sprint Planning Team will be able to focus on short term goals

Management will be able to get clear picture of efforts and progress

6 Sprint Estimation Standard Estimation techniques like planning poker lead to more accurate estimations

Contribution of team will lead to more clarifications and correctness

7 Coding Standards Uniformity in code will ultimately lead to higher code quality and lower defect count
8 Requirements review sessions All the requirements will be clear to team with brainstorming about implementation technique will help to achieve optimized code
9 Multiple code review sessions Code review will make sure about higher quality and consistency throughout application
10 Regression testing Helps to stabilize application and end to end functionality thoroughly testes
11 Intermittent Retrofitting Sprints Provides time to fix all aging defects

Team able to go through changes in requirements to accommodate missing changes

QA team able to focus on regression testing

Tools to manage Agile project

There are multiple Open source tools can be used to manage Agile projects.

  • XPlanner Plus – XPlanner+ is web based and has fancy design. XPlanner’s UI is straightforward and intuitive. Xplanner has built-in reports and charts.
  • Agilefant – Agilefant is a free, electronic web based backlog management tool. It aims to be as simple as possible but still scale from single team iteration management to large-scale multi-team development complete with long term product and portfolio management. Agilefant is conceptually the most advanced open source tool today, and serves both industry and research.
  • IceScrum – iceScrum is designed for Scrum, the most popular agile method. For the last 5 years it has grown around the Scrum pillars: Backlog, Sprint, ScrumMaster and Product Owner and helps teams with the ceremonies. iceScrum is a web application and perfectly suits the needs of geographically-distributed agile teams.

Agile Methodology

What is Agile

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

The base for Agile methodologies is agile manifesto:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan 

That is, while there is value in the items on the right, we value the items on the left more.

Types of Agile methodologies  

Well-known agile software development methods include:

  • Agile Modeling
  • Agile Unified Process (AUP)
  • Dynamic Systems Development Method (DSDM)
  • Essential Unified Process (EssUP)
  • Exia Process (ExP)
  • Extreme Programming (XP)
  • Feature Driven Development (FDD)
  • Open Unified Process (OpenUP)
  • Scrum
  • Crystal Clear
  • Velocity tracking
  • Kanban (development)

What is Scrum

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.

Scrum has not only reinforced the interest in project management, but also challenged the conventional ideas about such management. Scrum focuses on inexperienced project management institutions where it is difficult to plan ahead with mechanisms for process control, where feedback loops constitute the core element of traditional command-and-control oriented management.[citation needed] It represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.

Roles in Scrum

The core roles in Scrum groups are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project).

  • Product Owner

The Product Owner represents the voice of the customer and is accountable for ensuring that the Group delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.

  • Development Team

The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.).

  • Scrum Master

Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the group to deliver the sprint goal/deliverables. The Scrum Master is not the group leader, but acts as a buffer between the group and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the Development Team and keep it focused on the tasks at hand.

The Scrum Framework

  • A product owner creates a prioritized wish list called a product backlog.
  • During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
  • Along the way, the Scrum Master keeps the team focused on its goal.
  • At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
  • The sprint ends with a sprint review and retrospective.
  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.

Main activities in Scrum 



  • Sprint

The sprint itself is the main activity of a Scrum project. Scrum is an iterative and incremental process and so the project is split into a series of consecutive sprints. Each is time-boxed, usually to between one week and a calendar month. A recent survey found that the most common sprint length is two weeks. During this time the team does everything to take a small set of features from idea to coded and tested functionality.

  • Sprint planning meeting

The first activity of each sprint is a sprint planning meeting. During this meeting the product owner and team talk about the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to perform during the sprint.

The details of the sprint planning meeting :

When                :  2nd half of the 2nd week of previous sprint

Duration            :  4 hours

Attendees         : Developers Team, BA, PO, Managers

Conducted By   : PM/Scrum Master

Agenda Items    :

  • Pending Activities:  Discussion about any outstanding items from the previous sprint. Output – After discussion either the item is marked resolved/done or there is a takeaway / follow-up task assigned to somebody that will help close the pending item.
  • Lessons Learnt : Lessons learnt from the previous sprint are captured (both +ve and -ve)
  • Sprint Planning: For each of the stories in the product backlog for the upcoming sprint the following are discussed:
    • § Resource assignment
    • § LOE (hours)
  • Review of Product backlog for forth coming sprints.
  • Vacation List
  • Scrum

On each day of the sprint, a daily scrum meeting is attended by all team members, including the Scrum Master and the product owner. This meeting is time-boxed to no more than fifteen minutes. During that time, team members share what they worked on the prior day, will work on today, and identify any impediments to progress. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint.

  • Sprint review

At the end of a sprint, the teams conduct a sprint review. During the sprint review, the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner or any users or other stakeholders who have been invited to the review. This feedback may result in changes to the freshly delivered functionality. But it may just as likely result in revising or adding items to the product backlog.

  • Sprint retrospective

Another activity performed at the end of each sprint is the sprint retrospective. The whole team participates in this meeting, including the Scrum Master and product owner. The meeting is an opportunity to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.

  • Daily stand-up meeting (15 mins)

The Scrum Team has a daily stand-up meeting, lasting approximately fifteen minutes and facilitated by the Scrum Master. Each member of the team answers three questions in the Daily Scrum meeting:

1)      What did you do yesterday?

2)      What will you do today?

3)      Are there any impediments in your way? 

Main artifacts of a Scrum project

The primary artifact of a Scrum project is, of course, the product itself. The team is expected to bring the product or system to a potentially shippable state at the end of each sprint.

  • Product backlog

The product backlog is a complete list of the functionality that remains to be added to the product. The product backlog is prioritized by the product owner so that the team always works on the most valuable features first. Product backlog is a list of features to be built (often written in the form of user stories).

  • Sprint backlog

During the sprint planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team’s to-do list for the sprint. The sprint backlog is the list of stories and tasks the team needs to perform in order to deliver the functionality they committed to deliver during the sprint.

  • Burn down chart

Burn down chart is a run chart of outstanding work (or backlog). It is useful for predicting when all of the work will be completed. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. The release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations).

Department of Defense (DoD) Four-Layer Networking Model

DoD Model is the first layered protocol model having 4-layers. This model was originally designed for the Internet, and is important because all of the Internet’s core protocols adhere to it.


The 4-layers in the DoD model, from bottom to top, are:

  1. The Network Access Layer is responsible for delivering data over the particular hardware media in use. Different protocols are selected from this layer, depending on the type of physical network.
  2. The Internet Layer is responsible for delivering data across a series of different physical networks that interconnect a source and destination machine. Routing protocols are most closely associated with this layer, as is the IP Protocol, the Internet’s fundamental protocol.
  3. The Host-to-Host Layer handles connection rendezvous, flow control, retransmission of lost data, and other generic data flow management. The mutually exclusive TCP and UDP protocols are this layer’s most important members.
  4. The Process Layer contains protocols that implement user-level functions, such as mail delivery, file transfer and remote login.