Outsourced Software Development Insights From Abe 2011

・7 min read
Outsourced Software Development Insights From Abe 2011

In September, I took part in Agile By Example in Warsaw – a conference that gathered developers, managers and consultants who apply Agile and Lean practices in their everyday work. In my brief account I will focus on three topics which – to me – seemed particularly relevant to those involved in outsourced software product development, i.e. a context where the SDLC is spread across organizational boundaries that separate the teams working on a development project. Such a selection of topics is highly subjective and by no means representative of the wide range of problem areas that were covered during the event.


The Product Owner acts as a catalyst on the interface between the customer/user and the product development team. They need to carefully balance their involvement in customer development and product development activities. In doing so, they play a crucial role in software development projects – for better or for worse. Inban Oren and Monika Konieczy provided us with a number of invaluable tips on how POs may manage their interactions with developers effectively.\ In his presentation: How to lose a team in 10 days, Inban reflected on the most common mistakes POs make which tend to alienate their development teams. If you do want to lose your product development team, here is Inban’s advice:

  1. Treat Agile as an internal, back-end product development approach, which does not have an impact on what you do.
  2. Provide the team with too many large-sized user stories and insist that sprints/milestones must be enlarged to accommodate all the user stories provided.
  3. Do not prioritize; insist all features have the highest priority.
  4. Neglect customer/user collaboration; stay in the office and get in the way of the product development team.
  5. Focus on technical aspects of the product developed and turn a blind eye to business value that might be delivered.
  6. Deliver half-baked requirements and half-developed stories so that the team do not know what “done” really means.
  7. Develop and focus attention on very detailed stories so that the overall goal and the big picture are lost.
  8. Take success for granted – do not provide positive feedback, and limit yourself to criticism.
  9. Keep disappearing for long periods of time. Be unavailable for feedback and collaboration; come back only for demos.
  10. Insist on adding ever more features without refactoring the system developed. Incur huge technical debt.

Monika Konieczny, on the contrary, focused on what the PO might do to engage the development team and make them contribute much more than usually expected. She advocated using powerful story telling and visualisation techniques to put the development team in the user’s shoes. Stories and pictures can be used to enable the team to grasp the user’s problem. Alternatively, the artifacts may present benefits that might appear if a solution was found. Refrain from suggesting a specific solution, engage the team in the analysis and design, and you may discover you have empowered them to generate ideas and insights you would not come up with yourself.

What can developers do if their PO fails to perform well? Don’t despair. Educate your PO – in a retrospective, show them the benefits they COULD HAVE ACHIEVED and the loss they COULD HAVE AVOIDED if only they had been ready to act more constructively. In short, show them the problem and explain how it affects the project. You are, after all, in the same boat.


The topic was raised in the first presentation by Jutta Eckstein and was discussed by a few more speakers as we moved further down the road, including Thomas Sundberg and Szczepan Faber. It seems that fuzzy requirements may not be the best place from where to proceed with implementation. What we need are acceptance tests which can be used as executable specifications. The speakers recommended converting requirements into acceptance tests and using the latter as a medium through which to communicate, execute and accept deliverables. Clarifying requirements with test descriptions makes them more complete, accurate and unambiguous, which brings specifications closer to what they should be. After all, we do not want specs to stand for speculations.

Such test scenarios may be provided by the customer. For a number of reasons, e.g. time pressure or the degree of formality involved, customers are unlikely to convert user stories / use cases into acceptance test scenarios. Hence, a more practical approach is to have them created by the development team and approved of by the customer.

Acceptance tests used as executable specifications are particularly beneficial in intercultural contexts, and even more so with non-collocated teams, when communication is challenged by time zone differences. Executable specs may be adopted as a common language thereby facilitating communications on the interface between the Product Owner / Customer Development Team and the technical Product Development Team.

On top of that, such specifications:


  • boost productivity, enabling the development team to execute efficiently, rather than wonder and clarify what their PO meant while developing requirements,\
  • be used as a QA measure with which to improve not only product, but also service quality, i.e., with more precise acceptance criteria, the development team is far more likely to meet the PO’s expectations,\
  • provide documentation which facilitates the introduction of new developers to work on the project

Taking the above into consideration, no wonder Marcin Czenko, took a somewhat extreme stance: A user story without a test scenario is a joke. Well, however extreme it may sound, he may just have hit the nail right on the head.


Another challenge agile development teams are often confronted with is collaboration with corporate clients who are unwilling to accept agile contracts. Enterprise clients very often insist on detailed, upfront scope definition, fixed budgets and rigid schedules. Their legal and financial departments may effectively enforce a waterfall approach through appropriate contractual clauses, leaving little room for the benefits of a flexible agile approach. Interestingly enough, it may even run counter to the preferences of corporate Product Owners who want to adopt agile methods for software development.\ Is there a way out?\ Piotr Burdyło from TouK recommended a workaround. In principle, accept the contract offered but ensure it contains a well-defined Change Request Procedure that empowers the PO and the development team to manage scope change efficiently. You may thus gain a degree of flexibility with which to deliver a solution which better meets the customer’s needs.\

Karolina Polak and Piotr Żołnierek from Anixe followed a riskier path. In their presentation, they told an engaging story about how their team managed to win over a German corporate client and – more importantly – made the client feel comfortable enough to abandon a waterfall contract / approach. Their client may have been impressed by a well-designed and diligently executed consultative sales process. However, they still asked their prospective vendor to develop complete technical specifications and sign a fixed-scope/price contract before implementation.\ Rather than sheepishly complying with the client’s requirement, the team asked for time and took the risk. Instead of spending the time building detailed specs, they went on to work on the application instead. Within a month they managed to develop a significant part of the core product functionality. The output produced must have been astonishing as it persuaded the client to change the character of the contract. Waterfall once again gave way to Agile.\ All in all, do not give up too easily when confronted with a not so agile client.


Collaboration in outsourced software product development is definitely a challenge. The Agile By Example Conference in Warsaw was surely a place to find and share insights on how to meet the challenge.

Related articles