This checklist is an ever growing checklist for successful outsourcing of product development work to India. This checklist is based on my experiences of working with agile teams in Kerala, Bangalore and Hyderabad. Some of them are really enthusiastic about agile, where as many use the term ‘Agile’ only for marketing purposes. Before outsourcing work to India check the following;
The agile checklist
- Availability of business case.
- Level of understanding and commitment towards agile product development by the sub-contractor.
- Product manager’s understanding / commitment towards agile product development and agile outsourcing.
- Alignment of the contractual clauses to agile product development.
- Level of understanding and commitment of the roles and responsibilities of the sub-contractor and the product manager towards the chosen contract type.
- Reliability of the requirements
- Availability of a product discovery plan
- In the case of time zone differences, a proxy product manager’s services are used very often. Check the product knowledge and the leadership potential of the would be proxy product managers.
- Irrespective of who owns the design, check for the modularity and the scalability of the design.
- Are the expectations from agile set right?. Set the expectations from agile frameworks realistic across all stakeholders.
- Provision for empirical data during the development process.
- Provision for transparency into the effectiveness of corrective and preventive actions.
- Formal training of the agile development process to all stakeholders
- Check for the effectiveness of agile training
- Proactively check for potential cultural conflicts across multi location teams.
- Absence of well articulated business case for the agile product development – The same product could have been developed using the the waterfall model as well. Why are you doing it the agile way?. Are there any specific benefits by following agile product development?. Are they documented?. If not, please document the reasons and the expected benefits from developing your product the agile way. Be very realistic and modest about the benefits. Present it to all key stakeholders. Get their buy in. Set the expectations right.
- Gauge the level of understanding and commitment towards agile product development by the sub-contractor – Many use the term ‘Agile’ as a hygiene factor for their sales and marketing. Do not take me lightly on this. This is reality. Do not partner with anyone who does not know the agile process inside out, else you are asking for trouble in the longer run.
- Assess the product manager’s understanding / commitment towards agile product development and agile outsourcing. This is a very common problem. Must be addressed upfront to avoid costly failures.
- Look for the alignment of the contractual clauses to agile product development. – True Agile product development delivers successful products because they encompass continuous product discovery, agile development and continuous deployment. In an outsourced product development scenario, if the contract type is not flexible enough to accommodate continuous discovery of the product, then the product suffers. Traditional fixed price contracts will not hold good for outsourced agile product development.
- Check the level of understanding and commitment to the roles and responsibilities of the sub-contractor and the product manager towards the chosen contract type. Many product owners lack role clarity. They act as traditional senior project managers and supervises the work of scrum master and the development team, craving for control, every day. Funeral of agile. This happens mainly because they are not trained on the roles and responsibilities of product managers and how it is different from other managerial roles, especially in agile contracting.
- Validate the reliability of the requirements – On many occasions, many of the requirements turn out to be irrelevant for the end user, as the source of the requirements are wrong.
- Check for the availability of a product discovery plan – What is the plan for product discovery?. Very often the minimum viable product will not be that appealing to the end user. The product must be discovered till it’s end of life, to make a good product a great one.
- In the case of time zone differences, a proxy product manager’s services are used. Check the product knowledge and the leadership potential of the would be proxy product managers. This we can see in outsourced environments or distributed development. Product managers are supposed to behave more like the CEO of the product. They must be empowered to do so. Proxy product managers generally lack decision making authority and the enthusiasm.
- Irrespective of who owns the design, check for the modularity and the scalability of the design. – Whatever said and done, only a good design can scale. Only a good design can include last minute changes easily. Many times, agile frameworks are adopted half way, as a quick fix measure to solve the problems of a project resting on bad architecture. That is not going to work, unless and until it is redesigned. That involves lot of rework which could have been avoided.
- Are the expectations from agile set right?. Set the expectations from agile frameworks realistic across all stakeholders. Agile is projected as the silver bullet for all problems. Unfortunately agile will highlight all the in-efficiencies ruthlessly very early in the development cycle. Initial sprints can fail because of this. It is up to the team to correct the deficiencies and make the sprints successful.
- Check the provision for empirical data during the development process. – Without empirical data, progress cannot be measured. Improvement cannot be measured. Unfortunately many agile product development happens without empirical decision making.
- Is there provision for transparency into the effectiveness of corrective and preventive actions. Lack of rigor of corrective and preventive actions make the same mistakes repeat. This will result in failed sprints. People are hesitant to get into the real root causes and solve them, instead they are fine with quick fixes.
- Are all associated with the agile development process are formally trained on agile. Partial training kills agile teaming. – If the full team is not formally trained, they will not have a common understanding of agile. ‘Just do it’ attitude will not work. Proper training and role clarity is required for the Product managers, scrum masters, development team and other stakeholders like sponsors, delivery heads, sub-contractors, partners etc. Ensure every stakeholder is formally trained on agile.
- Insufficient training – Assess the effectiveness of agile training The trainer might not have given proper emphasis on the value system required for agile to be successful, instead, would have focused on the framework. Understanding the agile frameworks is the easiest part. Know how all the parts of the framework work together and create the pull required to achieve improved productivity is the key.
- Proactively check for potential cultural conflicts across multi location teams. Very often it is about ‘self organizing teams’ within a command and control’ corporate culture, that makes it difficult.
This is an ever growing list. Will be updated as and when I encounter a new root cause for fragile agile. I am maintaining this list as a set of known risks of agile implementations, for the benefit of all those who are embarking into their agile journey.