The Agile Offshore Journal

Cloud Sourcing

2011-01-05T07:06:00.001Z

Check out this SlideShare Presentation:

Cloud Sourcing

View more presentations from Aviram Eisenberg.

Agile Tour 2010 (Haifa Israel)

2010-09-26T14:47:00.001+01:00

This is the first year in which the international Agile Tour conference is held in Israel. Agile Tour is a FREE event (limited capacity though so hurry up and register) and is all about establishing a vibrant local Agile community, promoting Agile methodologies and sharing Agile knowledge between software development professionals and colleagues.

For more information and registration:

http://www.igniteoutsourcing.com/agile-tour-2010

The Hidden Costs of a Software Product

2010-09-12T07:41:00.002+01:00

The following presentation was presented as part of my latest lecture in the SD FOrum - the Israeli Software Development Management Forum that was gathred in June 2010 to discuss the non-functional requirements of a software product.

In this lecture I ellaborated some of my lessons on non-functional requirements that eventually become part of the hidden costs of a software product, such as:
Tracability - the ability to trace each action performed by the software
Auditability - the ability to perform audit operation
Trainability - the ability to learn how to use the software and its level of self learning curve
Supportability - the easiness in which the software can be supported by help deks and field engineers
and much more...I tried to steer away from the obvious non-functional requirements such as performance as this was covered in another lecture.

Hidden costs of software product

View more presentations from Aviram Eisenberg.

Flex vs. Silverlight

2010-04-25T01:23:00.001+01:00

We had a SD Forum gathering few days ago. The subject was UI and Usability. I compared Flex and Silverlight pros and cons:

Flex vs. silverlight

View more presentations from Aviram Eisenberg.

Agile and TOC - Can oil and water mix?

2009-07-01T22:59:00.004+01:00

This is my lestest lecture on combining Agile and TOC together. Can oil and water mix?

The end result is not exactly Agile and not exaclty theory of constraints but when taking concepts of TOC in the macro-management and Agile concepts for the micro-management something very interesting happens.

http://www.slideshare.net/aviram37/agile-and-toc/edit?src=slideview

Ignite latest fixed-price projects are managed using this unique combination of Distributed Agile and critical chain management. A full blown case study will be presented within couple of months.

5 minutes on Offshore challenges for CIOs

2009-05-15T06:34:00.005+01:00

Here's a nice clip I found on Tech Republic summarizing the main offshore challenges. If one will implement the measures to avoid the challenges described in this 5 minutes clip - you're half way to success in your offshore software development project.

An Indian colleague of mine once told me: "There are no problems in India, the only problem in India is the "No Problem" problem".

Whoever had some experience working with India will be smiling now...

http://blogs.techrepublic.com.com/hiner/?p=871&tag=nl.e101

SaaS in the eyes of an offshore provider

2009-02-07T12:57:00.000Z

This lecture was given during Software 07 - the larget event for Hi-Tech/ISV companies in Israel. It describes the pros and cons of SaaS - Software As A Service from our perspective. This case study was done on Lighthouse - a SaaS-based PLM we, at Ignite, use to manage offshore software development projects.

SaaS in the eyes of an offshore provider

View more presentations from Aviram Eisenberg. (tags: distibuted agile global delivery model)

On Attrition and Turnover

2008-12-19T14:03:00.000Z

I recently had two separated discussions with two of my colleagues who employ an offshore outsourcing facility in India. Interestingly one of them told me that he had experienced 100% turnover in an 18 month period, while the other had not even a single developer leaving his team for the last two years (!).

This is indeed a remarkable achievement, especially in India with its well known high turnover. What is the secret that my second colleague knows?

Well, basically, he knows that it is really hard work to keep people happy and challenged , yet he is willing to invest (and this is indeed an investment with measurable ROI) this time even though these developers are not on his payroll.

Here are some of my insights on the subject:

"…We invest a lot of time in establishing long-lasting relationship with our developers. There's no other way, if you want to avoid the huge cost of high turnover. I have been practicing offshore software development for over than 8 years now and I believe this is definitely one of the largest enemies of this field.

We managed to achieve a constant average of 5% turnover per year in the last four years. I think this is a normal turnover that reflects the natural need people have for change. I'll try to summarize my insights on the subject:

We prefer working with an Easter European facility rather than an Indian one. We found that in general, the Eastern European are more loyal and are not in a constant search for the next opportunity. They value stability and technical challenge more than an insignificant salary raise gained by replacing an employer. Moreover, working mainly with EMEA region I find the Eastern European alternative much more effective, in terms of lesser mentality gaps, closer time zones and lower costs for travel logistics.

We employ an "Ambassador exchange program" – every 2-3 months we send our onsite project managers to work offshore face to face with the offshore team and vice versa – sending offshore R&D team leaders to work on customer site. This serves several purposes: in onsite visits R&D team leaders really start to grasp the customer's line of business. When they come back to their offshore location they can then provide an added value of understanding their customer's business objectives and not only the technical requirements, like they typically do – staying in their comfort zone. This helps a lot in the onsite-offshore communication. Also, it gives them a sense of the bigger picture and belonging to the customer's team which reduces retention.

When working offshore, the onsite project managers, finally understand the difficulty in working offshore – it's like working in a glass bubble – you hear only some of the voices and considerations yet you are expected to produce as effectively as someone onsite who is fully aware of all the considerations of all stakeholders. When they come back to their onsite location, they communicate the bigger picture to their offshore developers much more clearly, which makes the team much more cohesive.

During these ambassador exchanges we encourage social activity between our project managers and our developers. People who drank beer (or Vodka!) together somehow communicate better even when they are separated again – there's some "invisible glue" that was created during this social activity. Again, it also strengthen loyalty and create long-lasting teams – people prefer to work with their friends.

We provide training courses as well as professional certifications to our developers free of charge. In general Eastern European value dearly their professional development and achieving industry-standard certifications (in Java, .NET , Scrum etc.) is very important for them.

On top of the benefits that we provide to our developers as an employer, we also encourage our customers to strengthen the corporate brand and sense of belonging in various ways: it could be a small appreciation bonus on a successful delivery, a company event in the offshore location, a vacation sponsored by the customer or even just a simple shirt with the customer's logo – sometimes that makes all the difference in the world."

Aviram Eisenberg
Ignite
http://www.igniteoutsourcing.com/

Agile Fixed-Price

2008-12-06T13:32:00.000Z

From time to time I am beeing asked if it is always possible to utilize Agile software development in offshore outsourcing. Here's a response I posted to such question:

"What happens if the customer is not familiar ith Agile methods, can you still utlize Agile development methodology in such a project?"

From our experience at Ignite, it is not mandatory that the customer will be educated with regards to Agile practices.

For example, we hade an incident where the customer's own in-house team worked in a traditional waterfall model. The customer's outsourcing experience was based on fixed-price engagements only, where, from his point of view, the outsourcing risk is manageable, and still we managed to bring a distributed outsourced onsite-offshore team that practiced agile in a fixed-price model, working collaboratively with the customer's in-house waterfall R&D team.

The customer heard about Agile and was willing to give it a shot as long as it will not take too much overheard, and as long as this would still be a fixed-price engagement. Once we requested, and he agreed, to allocate a product manager to work with us, our onsite project manager assumed the role of product owner (this was a Scrum team), working face to face with the customer's product manager on one hand and managing the offshore R&D team using Scrum internally.

Typically, the customer's product manager should have taken the product owner role, but due to lack of familiarity with Agile practices he preferred to stick with traditional methods. Our project manager "interviewed" him at the beginning of the project, created a set of high-level user stories and defined the priorities based on the objectives set by the product manager. Although all the guidance was coming from the product manager, from the offshore R&D team perspective, the product owner was our own project manager, they did not communicate with the customer's product manager directly.

We assigned the stories/features to 3 weeks iterations and kicked off the project. Towards the end of each iteration our project manager would sit down with the product manager, present the upcoming deliverables and then the two used to reprioritize the features of the upcoming iteration.

As in any other software development project, the deliverables of each iteration triggered some insights and new understandings of the final product and often – some change requests. On one hand, this was a fixed-price project and therefore change requests are billable and might break the budget and due date objectives, on the other hand – we are practicing Agile methods which welcome change requests as natural part of a software development process.

To solve this dilemma we utilize a process of exchange requests rather than the plain change request procedure. In an exchange request procedure our team will examine the requested change and try to identify a lower priority feature, with similar effort estimate, which was not developed yet, and can be exchanged with the change request at hand. This way, we still meet the customer's due date and budget objectives while responding to change.

Of course, this is not an accurate science. Sometimes it's not so easy to find the perfect candidate feature for this feature exchange. On average a fixed-price Agile project will have between 10%-20% budget overruns due to change requests. Having said that, it is still much better then the grim statistics of standard waterfall fixed-price projects where 60% of them are 200% over the agreed upon budget!

When Offshore meet Agile - Take 3

2007-12-08T12:38:00.000Z

Agile development recognizes that in reality the development process is spiral and involves frequent "regressions" to earlier phases, and creates an iterative process that imitates reality. It breaks the project down into short development cycles, generally monthly or bi-monthly.

Each of these cycles covers detailed design, development and testing of the software segment - a working application with some of the desired functionality starting from the first milestone. Most important, immediate client feedback is required at the completion of each cycle. This feedback is feasible since milestone delivery includes a product, as opposed to fragmented pieces of compiled code, that provides a certain percentage of the desired functionality and can be checked against the requirements.

An iterative process is created that rapidly converges into the final requirements, the detailed design and the finished product. The client's involvement in the development process boosts his confidence in its quality already at the early stages. Also, the large number of development cycles and the corresponding large number of quality assurance cycles improve the software quality, despite the shorter development period.

Off course, everything has its price. The above iterative process demands high discipline by the development team members, skill sets that are easier discussed than effectively achieved (Test Automation, Continuous Integration) and significant overhead costs. In addition, a psychological gap exists that must be bridged. It is mentally difficult for R&D managers to adopt a process that recognizes that the requirements are likely to change.

How does Agile development methodology effects offshore projects in reality?

In a specific software project performed by us, it was required to set up a Provisioning system using a Business Process Management (BPM) platform. The project contained a high degree of uncertainty since the client did not fully recognize the capabilities of the BPM platform and did not properly define either the business processes or the system's functional requirements. At the start of the project, the offshore team was unfamiliar with the platform and the external systems with which the provisioning system had to interface. Instead of building a standard development process, according to which after six months we would proceed to integrate the systems and discover various problems, we built an Agile process based on monthly deliveries, as follows:

- The infrastructure of the provisioning system was defined and developed.
- A pilot provisioning process was defined and developed to give the client a feeling of the end-
user experience.
- A Web Service was developed for every external system with which the provisioning system
had to interface.
- The final provisioning process was defined and developed following the client's requirements.
- Additional capabilities were added such as Failover, Clustering, transaction management, error
handling, etc.

The client felt deeply involved in this development process. The monthly deliveries helped him to specify the final requirements as the development work progressed. The regular feedbacks enabled the offshore team to quickly grasp the client's business logic and part of the requirements were in fact proposed by the development team! The automatic testing process ensured that progressive changes made would not affect the product's quality and the subsequent integration phase was reasonably smooth.

For the sake of comparison, a previous Provisioning system developed by a different development team engaged by the client used twice as many resources and finished the project at a significantly lower level of quality .

When offshore meet Agile take-2

2007-10-13T08:11:00.000+01:00

The best way to demonstrate the simple concept of agile development is through an example:

A few months ago I traveled to India and Thailand for my honeymoon. When my wife and I arrived to Bangkok, I decided (like many other business men visiting Thailand) to seize the opportunity and get myself a real "Armani-like" suit, tailored just for me by a local elite tailor.

We visited a number of stores that specialize in sewing suits (it seems that in Thailand most tailors and garment workers are usually Indian, Chinese or Burmese - the local Thai garment workers are too expensive...), until we finally arrived to a store we both agreed on.
When we were about to close the deal, the tailor informed us that we would have to come in the store almost every day, during the 10 day process of making the suit, for measuring and fittings.
My newlywed who has planned to pet tigers at the Tiger Temple in Kanchanaburi cried out:
"Why can't you do all the measurements on the first day and we'll come back on the 10th day to pick up the suit?"

"Ahhh..." answered the tailor with a smile, "and if we where to make a mistake and sew a smaller suit, or if the Mister will eat well during this week, will you still buy the suit???"
We decide to listen to our tailor, and during the next 10 days, I visited on a daily basis at his store: to start with, I was given the jacket without the sleeves, for fitting and measuring. The tailor spun around me with pins in one hand and a white chalk in the other. Later came the pants, and the day after, the jacket sleeves and then the first real fitting. Again, the tailor made adjustments, second fitting, more adjustments, third fitting... and we were happily on our way home, with a sharp looking suit. The project ended on time, at the expected budget, at the preset capacity and at the expected quality.

These are in fact the principals on which the agile methodology is based on:
- Collaborating with the client during the development process
- Dividing the project into short iterations and a checkpoint at the end of each one
- Adaptive to change (my waist line...) during development stage

Why does agile development gain such a big momentum in the development world today?

The old methodologies in software development are based on the Waterfall approach. In the Waterfall approach, during a project's first stage, more time is dedicated to analyzing requests and requirements. From the business requirements you obtain the technical requirements and the product's architecture.

The next stage is the Design phase, development/coding, testing and production. It's the same way architects create a project for building a bridge for instance.

Waterfall

Agile

The reason Agile development is becoming more and more popular is because a Software Development project is more similar to sewing a tailored made suit then to a project of building a bridge:

- The requirements of a Software Development project are more likely to change frequently.

- Software development is handicraft work (ambivalently!) and not automatic or mechanized
at its most, that is why human errors (bugs) are so common.

- It is very expensive to change software that does not fit the requirements, just like it's
expensive to change a suit that is too small for its owner...

- Software that did not arrive in the market on time becomes a white elephant, just like a suit
that was done after the client had returned home.

On my next posts I will provide a case study of a provisioning system developed by Ignite to demostrate how Agile methodology and and offshore development go hand in hand.

When offshore meet Agile take-1

2007-10-13T08:06:00.000+01:00

Imagine a construction project in India implemented for an American client. The project has been estimated, priced and initiated although no building blue prints were produced. The client has never visited the construction site, nor has he met the project manager or any of the construction staff. The client has not yet firmly decided whether to build a residential tower or a shopping mall. In a regular weekly phone conversation, the Indian project manager generally reports that the project is progressing exactly on schedule. The workers' field of vision is restricted to the particular wall being built at the moment. After construction actually began, the floor structure was built using asbestos, but as work progressed it was switched to an innovative structural system based on the use of feather-weight cardboard panels. Would you want to buy an apartment (or shop) in this project?

Offshore outsourcing for software development is one of the most challenging fields handled by offshore outsourcing providers. Much has been written about the challenges involved in a software development process conducted by a third party contractor operating in another country. To be fair, the crux of the problem is largely in the software development process itself, which is essentially an art rather than a science.

Everything may look fine and complete on paper with most of the development process based on the Waterfall model. The project plan covers requirements analysis, software design, development, testing & quality assurance, integration, application and maintenance in a linear streamlined process. However, in reality much is lacking. The analysis of requirements is commonly inadequate. Furthermore, the market is very dynamic and requirements that were valid three months before are now irrelevant due to changing market conditions, constant technological change and new versions released by competitors. Moreover, the critical problem is that the client's feedback to the delivered products generally results in change requests and often also in regression to the requirements analysis phase. In the development phase, developers often return to the design phase and even to the requirements analysis phase. That is common experience.

These problems are accentuated when the work is done by a foreign outsourcing contractor operating in another country. In this context, a "broken telephone" syndrome is experienced due to geographic distance and mentality differences. Let's face it, people who see each other in the flesh communicate a lot better. As an example, in Hindi, "no problem" means that "there is a major problem but you are the customer and I cannot disagree". On the surface, the combined effects of the inherent problems in the development process subject to the offshore-related "broken telephone" syndrome seem to be insoluble.

Yet there are signs that there is a way to efficiently outsource software development projects to an offshore provider. When Offshore Outsourcing meets Agile development methodologies things look different.

In the followoing posts I will describe how we, at Ignite, utilize Agile development methodology to leverage offshore development.