Let’s assume you are outsourcing your software development and wondering if things could go any faster. Development teams quite obviously vary in their inherent ability to deliver fast. On the whole, you determine the potential when you select a specific vendor / team to deliver the service. Having made the decision, you, in principle, have a very limited influence on how fast your software might potentially be developed. However, it can be observed that the very same team delivers at various speeds depending on the client they serve. The differences can often be traced back to how the outsourcing entrepreneur / company structures the collaboration process. Some outsourcers organize and manage the process well and thus empower their teams to reach their top speed. Others are much less effective in this respect. Which practices hold the development team back from achieving their top speed? How can you optimize the outsourced development process for speed? I have asked some developers for their insights and would like to share the findings in this blog post.
Incomplete and/or ambiguous tech specs
Requirements / technical specifications delivered by outsourcers vary greatly in terms of how easy they are to execute on. We have been developing applications based on both high-level requirements and fairly detailed tech specs, i.e., complete sets of wireframes / mock-ups and user stories / use cases, which were converted into acceptance test scenarios and approved of by the Product Owner before milestone implementation. With complete and unambiguous tech specs at hand, the development team implements much faster.
An added advantage of providing your team with executable tech specs is that there is less need to provide them with ongoing feedback during development, which allows you to devote more time to customer-focused activities at the front-end of the product development process.
Provide your development team with executable specs!
Tech spec development on the critical path
Executable tech specs do take time to develop. Sometimes they are developed only after the team have finished the implementation of a specific milestone. In such a case, developers often cannot move on immediately to implement the next milestone and are forced to fill in the gap working on a different project – an unnecessary distraction and a loss of momentum. There is a much better alternative though; tech specs can be developed concurrently with development and thus be removed from the project critical path. The development team can progress speedily from milestone to milestone.
Get the tech specs ready for the team to progress smoothly from milestone to milestone. Eliminate gaps between iterations!
Multiple requirements changes during milestone implementation
Requests for change submitted during milestone implementation may slow things down. The more requests submitted and the more fundamental the changes requested, the slower the progress. Tech specs may need to be reviewed and updated, and so do the schedules and budgets (on fixed-price engagements). Rework may add onto the workload.
Mid-course corrections are unavoidable, especially on innovative projects. Still it is possible to reduce the impact by selecting the backlog items which are least likely to change as well as by reducing the iteration cycle time. With less scope on the plate, you are less likely to disrupt the implementation work to be done.
When requirements are volatile, work on items least likely to change and shorten the milestone cycle time!
Lack of / insufficient / delayed feedback
The less precise the tech specs provided, the greater the need for ongoing feedback. When the requirements / tech specs are not complete / unambiguous, teams often get stuck in their development efforts. In such cases, their performance vitally depends on clarifications provided by the Product Owner. Clients differ in their response times – some take days, others merely hours to answer their developers’ questions and remove roadblocks which pop up on the way. Some teams take risks and develop without the feedback needed; in practice, they very often have to rework the solution when the feedback finally arrives, which again consumes time and money (on Time and Material engagements).
Knowing that your specs may be vague and you may not be available to fill in the gaps for the developers on an ongoing basis, strive for a team with expertise in your domain and application / project type. Find a team who understand your business, the problem you are trying to solve as well as the product you want to build, so that they are well positioned to fill in the gaps themselves.
Be available to provide the team with sufficient, timely feedback. Respond fast!
Too much feedback
At the other extreme, there are the Product Owners who get involved despite the fact that the team have sufficiently informative tech specs against which to deliver. It does not concern cases where a scope change is needed during milestone implementation. It concerns situations where the Product Owner attempts to interact with their developers even though they do not need any feedback to progress efficiently. Specify what you need and let the team do their job.
I guess the main reason for it is that back-office activities are much less challenging than the front-end work to be done with target customers / users. If Product Owners get sufficiently involved at the front-end of the process, they hardly ever have time to waste with their development teams at the back-end.
Do not get in the way when the team is progressing smoothly. Your time is likely best spent working with your customers and/or users!
Delayed acceptance. Team overextended on too many projects
Some Product Owners take a long time to check and provide feedback on the deliverables submitted by their teams. If the Product Owner unduly delays acceptance and, additionally, asks the team to progress with the work on the subsequent milestone, the team that agrees to do so, may soon be left stranded with a few unfinished milestones, which negatively impacts the service provider’s cash flow – see more on the point below. When stuck in this way, i.e., without feedback or acceptance, teams are tempted to wait and fill in the slots with additional engagements to maintain utilization at a reasonable level. A perfect recipe for slowing things down. If – at a point further down the road – all of their clients being served eventually decide to speed things up, they are in for an unpleasant surprise – the team may have very little room to move faster.
A note for developers. Do not yield to the temptation until after
- you have informed your client of the problem you face,
- you have presented the measures you might be forced to apply to alleviate it,
- you have clearly explained why you need to do so,
- you have given the client time to adjust, and still …
- you have been ignored by the client despite doing all of the above.
Keep the above in mind, yet never accept deliverables which do not fulfill the agreed upon acceptance criteria. If deliverables are flawed or incomplete, demand that the team remove any deficiencies before you accept and pay for the work done. Deliver the straightforward message as soon as possible.
Do not delay the acceptance of deliverables which satisfy acceptance criteria. Provide fast feedback on corrections needed. Keep the team busy on your project!
Unduly delayed payment
From the client’s perspective, the iteration cycle technically finishes when the agreed upon deliverables have been submitted. From the vendor’s perspective, the cycle is over when the associated payments have been executed and the team have been remunerated for the work delivered. The client may have accepted deliverables and still delay the payment for them. The practice can have a very disruptive impact on the vendor’s cash flow as typical software development houses / design agencies – like any service providers without passive recurrent revenue streams – vitally depend on the steady cash flow streams coming from the clients they serve. In the most dismal scenario, the vendor may lose valuable resources by not being able to meet their financial commitments towards their employees. Such payment default(s) may seriously cripple the team to deliver the service, let alone deliver it fast.
Some vendors may have been stung by unfair clients who did not pay for good service in the past. Being painfully aware of the payment default risk (which increases in proportion to the amount of work delivered and not paid for), they may feel reluctant to enter a new relationship with high velocity and ramp-up fast. You can help them hedge the risk. You do not need to use upfront payment to remove the doubts besetting their minds – start off with a small job or a short iteration, let them implement it fast and clear their doubts with a prompt payment.
Pay fast for work well done!
Middlemen
Service providers sometimes develop applications for other software development houses operating in the client’s market rather than directly for the client who commissions a software development job. When it is so, the information flow is extended over 3-5 entities, i.e., the offshore / nearshore service provider, the local service provider, the client and even the client’s customer and/or user. Quite expectedly, the longer the chain, the more time it takes to develop the solution. Just think of the number of acceptance activities to be performed and the number of people to be involved before the deliverables eventually reach the end of the development cycle.
If speed is vital, you should eliminate middlemen from the process and be as close to the development team as possible. You should even consider if outsourcing is the right strategy to pursue. If you optimize the project implementation strategy for speed, you may actually be better off collaborating face-to-face with physically collocated local resources. They may seem more expensive on the surface, however, if you consider the cost of delay, they may not be as costly as they appear at first sight. Alternatively, outsource but collocate with the key team members – either at your premises or theirs – for the fuzzy front-end of the process, bring things up to speed and only then – when things are running smoothly – dislocate to reap the cost benefits of outsourced development without sacrificing the speed you need.
Eliminate middlemen!
Conclusion
If you want to optimize the outsourced development process for speed, it may well be a good idea to focus on the main obstacles which slow development down; ensure smooth progress by proactively removing the stumbling blocks which get in the way. Let’s reiterate the main points with a checklist:
- provide your development team with executable specs
- get the specs ready for the team to progress smoothly from iteration to iteration; eliminate gaps between milestones
- keep the team busy on your project
- when requirements are volatile, work on items least likely to change and shorten the iteration cycle time
- be available to provide your developers with sufficient and timely feedback
- do not get in the way when the team progresses smoothly with implementation
- when milestone deliverables are submitted for acceptance, provide fast feedback on corrections / modifications needed
- do not delay the acceptance of deliverables which satisfy the acceptance criteria
- pay promptly for work well done
- avoid middlemen
All in all, if you are truly after speed, release the brake and you may find out the accelerator will take care of itself.
PS
The article is based on the accounts and feedback gathered from my co-workers in Selleo as well as from developers I’ve met at technology-focused events I attended over the last few years. I would like to express my gratitude for all the insights these folks provided me with.
