ENABLING BETTER TRAVEL
News & EventsOctober 14, 2015
Being Agile in an Outsourcing Environment
Collaboration is a key to succeed in Agile
Having been in outsourcing industry for years now, the most challenging area I have come across is to formalizing SLAs or KPIs as part of contractual agreement with adopting agile.
Agile has become a choice to address ever-changing business requirements in both product and service industries. And there’s a marked difference in product and service providers adoption of Agile. Product companies with in-house software development team find it easy to adopt agile principles and values, as the business prioritization is done in collaboration with internal customers, operations & development team. The key stakeholders here are on the same page and the main focus areas are feature rich product, improved product quality & reduced time to market.
However that’s usually not the case at the service provider side.
A customer-driven business like the outsourcing industry is a whole different ball game. Here the key stakeholder is the customer’s perspective, who decides the way of agile implementation in outsourcing industry. And it is imperative that customer has an agile mind-set before adopting agile as framework to achieve business value.
In an outsourcing environment SLA, KPIs and documentation are key to reduce risk at customer side. Importantly, performance needs to be measured and documented. Does it compromise on agile principles or values? Or is a hybrid agile model is fit in outsourcing environment?
Agile focuses on developing a feature-rich product rather than effort or schedule variance. From the investors’ point-of -view, this is critical as they often wonder if agile can be best fitted solution in such situations?
Judging by our implementation of Agile in outsourcing businesses, we developed certain practices that give us the best impact. Following are the recommended practices to get true value of agile in outsourcing industry:
Collaboration to enrol in agile philosophy: In traditional business models customer focus has been to provision more & more controls as part of contract to reduce risk and give clarity on key deliverables to service provider. However the broader vision may not be well known. It is cultural shift from the perspective of “customer is always right “to “Together we are rightly aligned” for delivering common vision. To make best use of agile, risk sharing and common business objectives are the key to success where service provider is enrolled in customer vision. Focus is not to report customer specific issues, rather work towards solution approach and take a leap jump from service provider to valued partner. Agile core values FORCC (Focus, Openness, Respect, Commitment, Courage) form a strong foundation if adopted collaboratively among customer & service provider.
Focus: Shared common vision needs to be known to entire team including customer and service provider. It enables a shift from ‘doing agile’ to ‘being agile.’
Openness: Feedback cycle should be driven both ways where not only customer but service provider also can provide feedback.
Respect: Degree of acceptance for suggestion, ideas, risks, issues to be set and welcomed by both customer & service provider need to be discussed together to arrive at consent based solution or approach.
Commitment: Timelines & business commitments should be owned by both service provider and customer; it should always be driven by product consumer priority.
Courage: Service provider should not get forced to deliver output in a particular sprint or iteration.
Measurement framework for improvement: Strong measurement systems have been part an integral part of outsourcing engagements for years now to assess service provider performance. While adopting agile, focus has moved from “Measurement for performance” to “Measurement for improvement.” While doing so, it is imperative to have common improvement goals having product vision in mind. The understanding here is that while measuring productivity, defect density is not wrong, customer also need to be aligned to agile philosophy of collaboration.
Contractual commitments should be designed around product features or releases instead of scrum team output or operational efficiency. Ideally having contracts that focus on service provider output will lead to two different focuses for same product, whereas service provider is focused to deliver the agreed output. And at the center of it all – the customer is focused to have aproduct live with minimum marketable features. This will have two parallel tracks running together which are never going to meet to common end.
Scalable estimation methodology: The story-point estimation technique as part of Scrum is relative in nature, depending on the team's knowledge and capability, which tends to evolve over time. Two main challenges faced in an outsourcing environment is (a) how do I measure the performance of multiple teams at one scale and (b) how does variation in estimations be reduced to consolidate the functional size developed by multiple teams in a sprint. Function point estimation model can be adopted to arrive at the functional size, as it works on predefined counting rules. Variation amongst scrum teams would also be less and provides a scalable measurement framework to assess the performance at team, program, or portfolio level.
For a more detailed and in-depth read on Scaling the Agile Governance Framework with MKII Function Points, click here.
Team composition to drive the expected output: Agile recommends having cross functional agile teams which can become difficult to manage in outsourcing industry, where resources are hired for specialized skills. Like how the five fingers of our hand are not the same, similarly not everyone in outsourcing is on the same standard to write articles as a business analyst. Therefore team composition should have developers, testers (manual & automation) and business analyst with a dedicated scrum master who can manage more than one scrum team depends on team size. It is also recommended for a scrum master to have prior experience in people management as the role demands more facilitation, coordination and stakeholder’s expectation management. The team needs to plan together in a way that ‘Ball is not dropped’ - for example - in case testers are not available due to unplanned or planned leaves, then developer can perform testing as peer tester to ensure product quality is not compromised. In other scenarios where developer is not available, the team has to actually demonstrate agile behaviour by utilizing the available sprint days to strengthen the testing area. In such situations customer must also be aligned and businesses mustn’t enforce penalties, in case, expected output is not delivered.
As per expected agile behaviour, team is committed to deliver business value but not a fixed business value. There can be several such scenarios teams come across in practical implementation which can only be addressed if service provider and customer works in collaboration.
Lean approach towards documentation: Documentation is the only way to reduce risk in outsourcing where development teams are working in remote location. Getting continued visibility at customer level is difficult thus such scenarios generally demand heavy documentation. As per the current trend stated in “State of Scrum” survey report 2015 Agile and Scrum are widely adopted frameworks in such environments. Maintaining documentation like traditional model may cause impediments in achieving sprint goal.
Three levels of documentation is to be defined in agile environment i.e. Governance, scrum work products & engineering. It is recommended to control them by tools and automation. Governance is something which helps in meeting the expectations of standards like CMMi, ISO, with program level plans with the right information, focusing on agile process flow adopted by teams, tools used and roles as per engagement. Estimations and schedule should be integrated with product backlog. To reduce the documentation effort for scrum teams, it is recommended to have more tools to address engineering process needs like code review, unit testing and automation testing framework. Status reporting documents can be merged with sprint ceremonies where customer representatives are also participating and getting regular visibility. Sprint exit report can be introduced to publish the status of deliverables to all stakeholders and this replaces the need of weekly status report. Metrics dashboard should be populated at the end of every sprint and published at released or stage level to all stakeholders.
Knowledge Management: In a dynamic environment of agile where resource movement is imperative, quick ramp up / induction plan or KAKT plan is must to have for ensuring smooth in flow of trained and equipped resources. Three level of induction plan is recommended which should ideally be compiled in 15 to 20 days at max. Stage 1 is domain or product training, stage 2 Agile process session focusing on customer driven processes for agile and stage 3 is on the job training for at least sprint duration to get more hands on applied processes. All the induction presentations, documents, product manual should be kept in the knowledge repository and accessible to all team members as well as new team member so that there is least dependency on individual in imparting induction sessions. Customer generally prefer to stick with critical resources due to application knowledge dependency, this dependency can only be removed by having strong Knowledge management framework.
Meetu Singh, IGT