Saturday, March 13, 2010

Agile based outsourcing/contracting: Tips for Customers & Suppliers

Scrum/Agile based outsourcing/contracting
Scrum/Agile is revolutionary. It is changing the world very rapidly. Very soon, customers will stop signing deals if a supplier is not "Scrum Ready". It is already a key part of many customer's evaluation criteria for supplier procurement. Being "Scrum Ready" provides a solid competitive advantage as ScrumSense is prevailing with each passing day. 

Customers are getting mature to handle Scrum. Personally, I see less issues from customer perspective but more issues from supplier perspective. Many supplier development teams claim that they are "Scrum Ready" but not really live up to the Scrum standards. This may cause some customers to loose interest in Scrum.

Tips for customers and suppliers

If you are a Supplier:
  • Remember, you will be out of the race soon if your company does not have strong experience of Scrum/Agile.
  • Don't fake that your team is agile as customers will figure it out and results will not be positive. Just doing monthly sprints and daily scrum calls do not make your team agile. Be agile in a true sense and be honest to your customers. If you team is learning agile then say it to them to set the right expectations. Customers will appreciate honestly.
  • Invest in your team development both from process and technical point of view. You will need cross-functional team members with a strong experience of test driven development (TDD) and continuous integration. Invest now to yield exceptional results in the near future.
  • Develop a few scrum coaches/trainers in your company to internally train people. These coaches/trainers can also help your customers to gauge their maturity and provide consultancy.
  • Best way to learn something is by practicing it more. Motivate your staff to contribute to the agile community.
If you are a Customer:
  • Give Scrum/Agile supplier a try. You have nothing to loose and you will get opportunity to see the working software every few weeks.
  • Invest in good engineering practices. If you want your supplier to cut costs at the expense of good engineering practices (e.g. TDD/CI),  then your end results are going to suffer immaterial of the methodology in use. 
  • Scrum is based on the trust, hence, be cooperative and trust your supplier.
  • Ideally, one or more of your representatives will be good candidates to play the role of product owners. In order to succeed, product owners need to interact heavily with the Supplier Scrum Teams. Be prepared to dedicate someone with the right attitude to play this role. Please send product owners for the Scrum training as it will make a huge difference. 
  • Scrum planning and reporting is different from the traditional waterfall or project management reporting, hence, it is important that your management team understand the basic concepts of  Scrum planning and reporting. I am sure that your vendor will be happy to train you for this.
  • Most importantly, only get into a Scrum/Agile project if your team has an open mind to learn. Don't be a control freak just because you are a customer as this attitude will not help in the long run.
Scrum contracts

First of all, let's review the advantage of applying scrum in the contracting business:

  • Customers can define product backlog as a starting point which will be further used to define release backlog and sprint backlog based on the priority of the user stories (requirements).  Product Owner (a customer representative) has full control over the backlog and priority of user story in it. 
  • Scrum planning process gives opportunity to the customers to adjust requirements as per their stakeholder feedback after each sprint. As product owners are part of the scrum teams, they get more visibility in the process and progress.  Burndown charts are great control points.
  • Quality is the key for Scrum process. A good scrum team manages to deliver product with nearly zero defects.
  • Most importantly, customers are entitled to see a working software after each sprint.
  • If you have read about the outsourcing maturity model, "trust" is considered to be a key factor for matured outsourcing contracts. Scrum framework is entirely based on trust, hence, it enforces outsourcing maturity from the beginning. In the end, scrum provides a win-win situation for customers and suppliers.
All contracts fall into one of the following two main categories. All other contract types are minor variation of these. 

Time & Material (T&M) Contracts:
  • Intent of this type of contracts for scrum projects is similar to the traditional T&M contracts - customer pays for the resources utilized based on the preset cost structure. Scrum makes these type of contracts more meaningful by adding a proven framework. 
Fixed Price Contracts:
  • Fixed price contracts are nothing but commitment from the vendor to deliver pre-defined project scope within the budget. This gives peace of mind to the customer after contract is signed but they need to do a lot of upfront work to ensure that requirements are documented properly with almost no ambiguity. Now think deeply about it - in the current dynamic business environment, how can someone be too sure that he understands business requirements very clearly few months in advance? 
  • Industry analysis shows that upfront requirements with no opportunity to get feedback/adjust, during the development process, result in a large number of useless features for the end users. In other words, project may meet the budget targets but it may not yield the required value from money because of wasted features. 
  • Do you still think that fixed price contracts are good for you? Fine, you can use Scrum in the fixed price projects but think out-of-the-box. Allow your contract to adjust requirements as per the market situation and customer feedback. Define your scope as prioritized backlog and ask your supplier to work on the highest priority items first without any exception. If you have any compulsive reason to adjust the requirements in the middle of the contract term then add new requirements but take out some pre-defined requirements from the bottom of the prioritized list. This concept is also called "exchange requests". This is just one of the idea - apply ScrumSense and you will figure out how to use powerful Scrum framework in your favor.

A Project Story

I am representing a customer's view. My team is fairly distributed in 6 counties with multiple suppliers and our own development resources. Like any good development group, our team was very keen in becoming agile (from waterfall) with very good support from the executives. We took some initiatives to expedite Scrum adoption but pace was very slow.

We needed another supplier for various reasons. It was a good opportunity for us to look for a supplier with solid agile experience. We searched all over the globe, requested many companies for information and picked few companies in various geographies for detailed evaluation. As you can understand, cost of living in all geographies are different, hence, comparing vendors based on cost was a senseless thing. Our focus was on evaluating vendors based on our core needs - agile experience and quality of engineers. We ended up selecting a small small supplier because of their agile strength. We clearly set the expectation during contract discussions for the partner that we look forward for them to make us agile. This supplier provided us agile coaches, evaluated our group's maturity, and developed plans for improvements. Moreover, they never compromised on agile values and never hesitated in having honest conversations. It was amazing to see how well our development resources working with this supplier's resources. Our agile adoption was very quick since then.

Learning from this project in a nutshell:
- In the present global economy cost is a relative term. You can't compare suppliers based on the cost. Important thing is to find value for money.
- Bigger is not always better - smaller companies think more seriously about agile.
- Relationship was based on trust and value. I have developed a partner maturity model. I will expand on that in future blogs.
- Agile works - having experienced people makes it easier to adopt.

  • Customers, give scrum a try for better results for you.
  • Suppliers, invest in your team development to become truly agile. Customers will like you more  and your revenue will hit the roof.


    1. Replied on a comment in another forum:

      “Exchange Requests” work like this: each time the customer needs to change the requirements, they make a Change Request in form of new User Stories. The Supplier resources provide estimate for these new requirements. Project should already have a prioritized list of release backlog of user stories with estimates. In order for the customer to add new requirements in the release backlog, they need to remove user stories requiring at least the same effort. The customer can only remove unimplemented features that the development team is not working in the current sprint. For example, the customer can add feature X (estimate 10 ideal hours) if they first remove features A (estimate 6 ideal hours) and B (estimate 4 ideal hours). Ideally, the customer should remove the user stories with the lowest priority in the backlog. This way the customer gets the most valuable features without any cost impact.

    2. Yogesh, few comments here. This blog would be just amazing if based on your specific experience. For instance, tried project A - took 10 years to develop. Tried scrum/agile - took 3 months to deliver to customer. It looks to me that with or without agile/scrum there are way too many projects that miss the target and thrown shortly after deployment. How come? That would be amazing blog to discuss. Also, adding/removing features is usually possible when foundation is ready. Adding/removing things from foundation is very costly and less straightforward than add 10, subtract 6 and 4 :) More likely keep 10, add 6 and 4 and work 24/7 to get it done yesterday :) I agree with the other guy that common sense does make sense (no pun intended)

    3. Dear Anonymous,
      I appreciate your feedback. I will add profile for a project in my blog, however, my intention is not to prove that Scrum is valuable. My objective in this blog is to talk about how Scrum can be adopted in the outsourcing projects. I am assuming that readers of this bog to have basic Scrum knowledge. Do you have any specific questions? It will make it easier for me to share more details.

      Regrading your other comments, I am not sure what you mean by adding/removing thing from foundation. Scrum teaches a really nice way to manage backlog in the form of prioritized user stories. Writing incremental user stories and doing incremental design is the key for Scrum success. Fundamental of scrum is to have flexibility of requirements and adjust to the customer's needs/feedback quickly. Even if someone worked 24x7 to deliver a requirement but customer does not need it then what's the value in having this requirement?

      I suggest you to review Ken Schwaber's video blog at: