Process For Agile Contracting

Corporates are rapidly moving to agile for their internal software development, however, most of the outsourcing companies are still non-aglie or pretend to be agile. What's the reason? Who is responsible? When I talk to the suppliers (outsourcing companies), they express great interest in becoming agile but something holds them back. What is the obstacle? Interestingly, a very common answer is that they (the suppliers) are ready to change but their customers are not. There can be two reasons for this.

1. Contract buyers (customers) do not see value in agile OR
2. Contract buyers (customers) do not know how to make agile working in outsourcing


BTW, my meaning of agile contracting is very simple. Agile contract is a contract between a buyer and a supplier to deliver software as per agile development process.  It has nothing to do with the pricing terms and conditions.

1. Why should Contract Buyers  sign agile contracts?

There are lots of reasons why buyers should go for the agile contracting. Let me explain my top 4 reasons.

A) Ineffectiveness of the big requirements upfront

A well known survey shows that  64% requirements in traditionally managed projects are "never" or "rarely" used. Teams spend more time in documentation than coding. Traditional processes are more on the lines of change prevention rather than change management.  Focus is on writing software as per the specifications instead of meeting customer needs by enabling a continuous feedback loop. Agile helps you iterate the process every 2-4 weeks to enable a feedback loop.

B) Time To Market is shrinking rapidly

Gone were the days when companies had luxury to wait for a few years after introducing a new innovation to the market. Now-a-days it hardly takes a few months for the competition to catch up even for highly complex products; for e.g. how many iPad equivalents did you hear within a year of its launch? Task doesn't end after delivering a good product. Companies should be agile enough to turn around very quickly to compete. You need a process which is adaptive to keep you competitive in the super-dynamic market.


C) Cost of change

By reducing the feedback loop, the time between creating something and validating it, you will clearly reduce the cost of change. Agile allows to work closely with the stakeholders which enables you to quickly determine if you’ve built the right thing.  The cost of change is also reduced by an explicit focus on writing high-quality code using best engineering practices. By traveling light, in other words by retaining the minimum amount of project artifacts required to support the project, there is less to update when a change does occur. 

D) Project Value Distribution

I strongly believe that value delivered by an agile project with fix resources and time is much more than non-agile projects with the same resources and time. Let's assume that the value gained at the end is same for both for analysis purposes. As you can see in the following diagram, agile projects deliver almost constant value through out the project but non-agile projects have limited value addition in the early phases. In an agile project, software is deployed every sprint, hence, value is realized in every sprint; not just at the end of the project. Lets think about a scenario where an Executive needs to take a decision about project continuation in the middle. Obviously, he will see much more value in an agile project.


2. What do Contract Buyers need to do to become agile?

I hope you are convinced by now that signing an agile contact is less risky and more valuable. If not then please let me know your reasons. It will be good to learn from your experiences.

If you are already convinced and wondering what you should do to sign an agile contract then the following diagram can explain the process at a high level.

Agile is Not Simple


If this is your first time for the agile contacting then make sure that your team understands that agile is not easy. It is a complex and adaptive process. You can start by taking simple steps but keep investing in the process to continually improve. It is very important to inspect and adapt on a continuous basis.

Find an Agile Vendor

First thing you need to do is to find an agile supplier who is not scared of giving demo and deploying software for you to undertake user acceptance every 2-4 weeks. How can you trust a supplier who gives you meaningless reasons for not doing so? Just remember that there are many suppliers who are capable of exhibiting you the working product every 2-4 weeks to gather your feedback.

Don't you want to see real progress by looking at the working product on a regular basis instead of seeing the hypothetical progress on a project plan? Start it by adding agile in your supplier evaluation criteria. It's your money, hence, invest wisely.

Collaborate with Supplier More Often

As a Buyer, there is one main thing you need to change to make agile projects successful. You need to collaborate with the supplier more often unlike traditional approach where collaboration almost stops after a big set of requirements are locked in a document. On agile projects, your supplier needs you every day. It's a collaborative process where your team needs to take on responsibility of an agile product owner. Agile process brings urgency of getting work done effectively. If you don't have urgency as product owner then how can you expect your suppliers to show urgency?

With collaboration, trust will automatically build. Collaboration and trust is what you need for success after you choose an agile vendor. Please don't let your supplier make an excuse that their customers are not ready for agile. Change starts from you. If you don't take the initiative then your suppliers will not come out of their comfort zone.



I hope you found this blog helpful. Please give me your feedback to help you better in my future blogs. If you are new to Agile and Scrum then try this self-learning guide which has references to the good and free learning materials. Good Luck!

No comments:

Post a Comment