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 adapt. 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.
- 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 use cases documented in storyboards, mockups, etc.
- Technical architecture
- Project schedule and estimates
- Acceptance criteria and non-functional requirements (performance, scale, availability, etc.)
- Risks
The critical 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 it 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. Vital 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 the 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.
Agile 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 essential 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, including checkpoints at the end of each increment with key stakeholders to review progress and plans for the next three months. Development is further planned and executed in 2-week sprints with progress and feature reviews with the team and customer representatives at the end of each sprint for timely feedback and issue resolution.
Critical planning and sprint deliverables (requirements, sprint plans, daily standard ups, the 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 yet 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 storyboards and mocks and regular (at least weekly) video or on-site grooming sessions with the team drive a shared 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 two sprints. In terms of 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 be effective, collaboration and communication needs to be built systematically into the process, tools and development practices — it rarely just happens. Critical practices to reinforce collaboration are:
- Scheduled on-site time with the product owner and development team in each crucial planning meeting and report-out event. The best practice is having the product owner with the team over 50% of the time and the development team coming to headquarters for scope planning and project kick off.
- Daily stand-ups attended by all team members, EVERY DAY, on-site or via video conferencing, with the team board updated daily during or before the stand-up meeting.
- Requirement grooming sessions with the entire team on-site or via video conferencing with heavy use of mock-ups and story boards to help communicate customer expectations.
- Customer / stakeholder reviews with the entire team, with reviews 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 displayed real-time on monitors to illustrate development progress and potential bottlenecks.
- Role and responsibilities for each development deliverable are clearly defined and reinforce team collaboration.
- Overall co-ownership for the project result, 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 quickly end up eating over half your development time; however, building in quality to avoid errors or find them earlier is neither expensive nor time-intensive — 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 the highest value first to the customer.
- Leveraging modern architectures that are effectively componentized for more rapid development at a higher quality.
- Defining acceptance tests before development starts to enable test-driven development.
- Ensuring continuous integration and testing of code to find potential defects and fix them early in the development cycle when it is least costly.
- Reviewing and providing 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.
- Striving 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 and details around the processes and tools necessary for success, as well as an understanding of the cultural influence to expect.
If you’d like to learn more about how Crosslake works and its processes for successful execution, contact us directly.
