Market pressures are pushing companies to innovate and release faster and more frequently to stay ahead of the competition and digitize internal operations to reduce operating costs. New technologies continue to emerge that enable reductions in time to market and development costs, however these technologies take time to effectively learn and adopt. While companies are faced with these market challenges and technical opportunities, they are typically resource constrained either by internal budget or availability of qualified resources.

Finding ways to work with a development partner can help you expedite your product roadmap and adoption of new technologies, however these projects take thoughtful planning and structure to execute successfully.

First, it is worth visiting the common challenges, that left to fester, will lead to project failure.work with a development partner

  • Scope and requirements are not commonly understood and will likely evolve over time, which leads to rework, project delays and design issues.
  • Ineffective communication and collaboration practices, for non-co-located resources and cultural differences, leads to rework, delays in decision making and reduced trust.
  • Project durations that are relatively long tend to get out of control leading to scope creep, changing priorities, or lost interest.
  • Project status and risks are not clearly or commonly understood across the team leading to communication and trust issues and project overhead.
  • Imbalance in Domain Knowledge can reinforce ineffective communication which leads to misunderstanding, ultimately leading to project re-work and delays in delivery.

This article summarizes some of the most critical areas to successfully work with a development partner. 

Scope and Goals

The intent is to do just enough to define a high-level understanding of the business and customer goals and break the goals/ epics into a delivery roadmap of 3 month increments with high level estimates of effort.  During this increment, you want to avoid spending immense amounts of time scoping the project, and instead, simply move forward.  This includes achieving a common and defined understanding of:

  • Project scope, goals and business case
  • Epics with target customer and measurable customer criteria
  • Key User Personas and Key Use Cases, documented in story boards, mock ups etc.
  • Technical Architecture
  • Project Schedule and Estimates
  • Acceptance Criteria and Non-Functional Requirements (performance, scale, availability etc.)
  • Risks

The key internal and outsourced team members should be co-located while working through the scope and goals and review these together with key stakeholders. Not only does this improve the quality of the plan, but also builds co-ownership, collaboration and domain knowledge.

Delivery Team

The development team is co-located with a mix of developers and testers with appropriate skills and experience to execute on the project goals. Team size is typically capped at seven people and if the project requires more resources is split into multiple teams. Key roles on the team are:

  • Technical Leader—whose ultimate responsibility is for technical advice and programming of the outsourced development team and partner with the client architect team to ensure architectural consistency.
  • Product Owner–whose responsibility is to partner with client Product Management team and is responsible for breaking down and refining user stories and acceptance criteria and coordinating with the development team.

The client team will typically consist of the following key roles:

  • Product Manager—This person is responsible for the overall project direction, customer requirements and priorities for the development team. He or she is also responsible for the customer validation plan and coordination with project stakeholders.
  • Architectural Representative—This is the architectural contact for the outsourced team and is responsible for delivering a consistent architecture across products and features.
  • Stakeholder Group–Leadership representatives are responsible for the overall project success.

This team works together to define the roles and responsibilities for the various deliverables for clear ownership with heavy doses of collaborative input. For the project to ultimately be successful, there must be a clear sense of co-ownership of results.

work with a development partnerAgile Project Management and Delivery

The benefits of agile thinking need to be brought into the process for successful software development partnerships.  Iterative development, continuous delivery and feedback cycles along with team (defined as both internal and external resources) collaboration are key to successful execution and project transparency.

Our process starts with the team planning and breaking down goals and high level requirements into no greater than 3 month increments, with checkpoints at the end of each increment with key stakeholders to review progress and plans for the next three month. Development is further planned and executed in 2 week sprints with progress and feature reviews with team and customer representatives at the end of each sprint for timely feedback and issue resolution.

Key planning and sprint deliverables (requirements, sprint plans, daily standard ups, definition of done, etc.)  as well engineering standards are agreed upon in advance.  The roles and responsibilities across the team are defined for clear ownership with heavy doses of collaborative input.

Standard development tools are also defined in advance for collaboration, project management dashboards, source control, bug management, test management and test automation. All team members and stakeholders have full access to the project management tool and dashboards.

Time must be allocated to effectively onboard the overall team and get them up to speed on the domain and engineering process and standards.

The point here is about discipline in the process—with a lightweight and disciplined approach to implementation you can take corrective action on a timely basis when it’s needed. This helps reinforce a high level of team collaboration and project transparency and predictability while minimizing project management overhead.

Detailed Requirements and Validation

A standard requirement breakdown structure (Epic> User Stories> Acceptance Criteria> Acceptance Tests) is used to drive alignment to the project goals through implementation and ensure consistent reporting on requirements. The team will work collaboratively and iteratively to define and refine requirements, in stack rank priority order. The product owner is typically responsible for Epics, User Stories and Acceptance Criteria and the development team is responsible for Acceptance Test definitions. Heavy use of story boards and mocks and regular (at least weekly) video or on-site grooming sessions with the Team drive a common understanding of customer expectations. Entry criteria for each sprint planning session includes full refined user stories, acceptance criteria and acceptance tests for the sprint with a stretch goal of having user stories and acceptance criteria defined for the next 2 sprints. Best practice the Product Owner or representative is on-site full time working with the development team on a day-to-day basis.

We are now at a point where detailed specifics allow us to bring in the remaining discipline to the process that delivers accountability.

Collaboration and Communication

To ensure effective collaboration and communication it needs to be built in systematically into the process, tools and development practices, it rarely just happens. Key practices to reinforce collaboration are:

  • Schedule on-site time with the Product Owner and development team at each key planning meeting and report out event. Best practice is the Product Owner is with the team over 50% of the time and the development team comes to headquarters for scope planning and project kick off.
  • Daily Stand Ups are attended by all Team Members, EVERY DAY, on-site or via video conferencing and the team board updated daily during or before the standup meeting.
  • Requirement grooming sessions are done on-site or via video conferencing with the entire team with heavy use of Mock-ups and Story Boards to help communicate customer expectations.
  • Customer/Stakeholder Reviews. Entire Team will be involved and reviews will be held at the end of each sprint for customer representatives and at least quarterly for stakeholders.
  • Joint code reviews of each commitment to ensure code meets standards and effective knowledge transfer and sharing.
  • Team email alias not separated by internal and external team members.
  • Key Dashboard metrics are displayed real time on monitors to illustrate development progress and potential bottlenecks.
  • Role and responsibilities for each development deliverable is clearly defined and reinforces team collaboration.
  • Overall co-ownership for the project result is reinforced by stakeholders and development partner leadership at EVERY stakeholder update.


End-to-End Quality

The traditional approach to testing, finding and fixing defects is very expensive and time intensive. It can easily end up eating over half your development time; however, building in quality to avoid defects or find them earlier is not and has the added benefit of improving time-to-market and project predictability.

How do we do it?

It starts with building quality into each step of the development cycle starting with requirements. Some key practices include:

  • Establishing measurable customer criteria that will be used to design the feature or architecture and validated by the development team through the project.
  • Stack ranking requirements and developing the highest priority requirement first to deliver highest value first to the customer.
  • Leverage modern architectures that are effectively componentized for more rapid development at a higher quality.
  • Acceptance tests defined before development starts to enable test driven development.
  • Continuous integration and testing of code to find potential defects and fix them early in the development cycle when it is least costly.
  • Review and feedback of work at the end of each sprint with customer representatives to ensure features are fit for purpose and potential issues are rapidly resolved.
  • Strive for a deployable product at the end of each sprint and clear definitions of done to reinforce high quality throughout the development cycle.

When Crosslake helps a client determine the best path to success with their business initiatives, we take all options into consideration to deliver the right solution and structure for the customer.  This process for successful execution is useful in beginning up-front communications to assess requirements, details around the processes and tools necessary for success, as well as an understanding of the cultural influence to expect.

To help clients prepare to work with a development partner, we created a checklist that details the principles for successful development projects along with scope and goals, agile management, requirements and validation, quality and much more. You can download it here.

If you’d like to learn more about how Crosslake works and its processes for successful execution contact us directly.