Agile and TOC – Can oil and water mix?

Agile and TOC – Can oil and water mix?

When Offshore meet Agile – Take 3

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

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.



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.

Agile and TOC – Can oil and water mix?

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.

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.

Agile Fixed-Price

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!